Kotlin Native's choice to go with a GC over native memory management is my biggest issue with it and really limits its use for memory and performance sensitive use cases.
I had a bunch of very tenured teammates that didn’t really know how to use git, so there were only a few of us comfortable enough integrating and interacting with an open source dependency repo.
I actually dislike that Ruby reads like natural language. The complex logic in large systems would take many paragraphs to describe in english but is often much clearer and more succinct in code.
I have yet to find a portable windows machine that doesn’t throttle performance on battery. Weird that no reviewers ever mention it but Macs have nearly no performance difference and they plugged in vs on battery and that’s a huge reason I don’t trust using any Windows laptops on the move.
That is a Mac user thing anyway. For some reason Mac users seems to have a boner for a computer that can work everywhere, especially in place where it makes everything more complicated and painful no matter the battery life. Well at least that is what they tell you; in large part thanks to the marketing.
In practice I have rarely seen this sort of "advantage" really taken care of. For the most part people use their laptops for watching videos and doing simple office like task when they are on-the-go without a desk and power source.
It's quite funny because it was already one of the major arguments of Mac laptops back in the 2000s when I bought my first one.
I have done tech support for full Mac companies and countless of people with various jobs position and it simply doesn't reflect how the vast majority of people use their laptop.
It's a lot like the capability of SUV/luxury 4x4 to go in accidented terrain. That's nice marketing feature but barely 1% of the buyers actually use it.
You do keep your compensation if you don't move your address, otherwise you get paid a market rate adjustment for that area, which from what I've seen is quite fair.
That's a poor assumption that appears to be based on your personal preferences and what you're comfortable with. I personally find both require some learning, but prefer the svelte version.
And JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.
JSX is easy to summarize as: HTML where everything in curly brackets is a JS expression that gets evaluated. There are some additions (prop spreading) and restrictions (curly brackets apply to whole attribute values and element bodies only), but they're very simple.
And custom event handling attributes, camel casing, special cases like htmlFor and className, non-standard attributes being ignored except for custom elements, the style attribute, the special case of checked/selected properties vs attrs for form elements, key and ref properties. Plus all the semantics of component updates, memoizing and so on.
This is already far more to learn than the handful of simple control structures Svelte introduces.
JSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties.
This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches).
JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with.
One could add this syntactical sugar natively to the language spec, in fact E4x (ECMAScript for XML) share some properties w/ JSX and was once proposed to the spec.
edit: instead of downvoting, please voice how you disagree with my assessment
By the same logic we could call any structured format “is js”, because it is homomorphic to some js expressions. Are xml, pug, plist, dbf, all js? Nope, it’s all python.
I agree 100%... Adding JSX to the language spec would be interesting. It might be too heavy to include within the language spec as many JS applications do not involve the DOM at all, so then you have to essentially bundle DOM functions into every application... or common.js would omit this subset of the language.
One nice thing about JSX is that it is pretty straightforward to write the function (React.createElement replacement) that it transforms to, so you can use it to construct any complex tree-like structure. No DOM stuff is needed. For example writing a JSX factory to output a static html string is maybe 20 lines of code.
Mozilla Xulrunner and Rhino (a JavaScript interpreter implemented in Java) used to support E4X: ECMAScript for XML, the ISO/IEC standard 22537:2006, and it was removed in 2014.
>ECMAScript for XML (E4X) is the standard ISO/IEC 22537:2006 programming language extension that adds native XML support to ECMAScript (which includes ActionScript, JavaScript, and JScript). The goal is to provide an alternative to DOM interfaces that uses a simpler syntax for accessing XML documents. It also offers a new way of making XML visible. Before the release of E4X, XML was always accessed at an object level. E4X instead treats XML as a primitive (like characters, integers, and booleans). This implies faster access, better support, and acceptance as a building block (data structure) of a program.
>E4X is standardized by Ecma International in the ECMA-357 standard. The first edition was published in June 2004, the second edition in December 2005.
>The E4X standard was deprecated by the Mozilla Foundation in 2014.
>"use strict" is currently our one real opt-in boundary for simplifying the language and reducing threats by dropping legacy complexity that is generally no longer needed. As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. Until we encountered this issues, it looked like SES could bring ocap security to ES5.1 without doing an accurate lex or parse. With this restriction, we could regain this economy.
>Besides, no one wants to upgrade the E4X semantics to be compatible with ES5 or ES.next, so this seems a good time to impose this opt-in restriction.
>Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute!
>So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
>It was deprecated and removed from the only browser that ever supported it because it was a poorly implemented language feature that was causing all sorts of problems.
>As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. — Mark S. Miller
>The only way for it to come back would be via a new edition of ECMA-357, which Adobe and Mozilla were going to work on. Until then, it's out. — Brendan Eich
>The idea behind it wasn't bad, but the way it was integrated into the language was. SpiderMonkey was the only JS engine that ever implemented it, and there were endless problems caused by that and severe complications of the engine's implementation required for this support. — Till Schneidereit
I don't use Signal to message strangers, only contacts who I have phone numbers of. Seems like that's the use case for most messaging apps like Whatsapp and iMessage that Signal was designed to "compete" with. Signal is a private messaging app, not an anonymous messaging app. A worthwhile distinction with very different (though overlapping) target audiences.
