485 karma · joined December 7, 2021
If you've known anyone addicted to the list of things you mention, you should know that at some point, they are no longer "free to destroy themselves". They are continuing to destroy themselves out of a chemical or phycological necessity. The people who deal drugs or own casinos are running predatory businesses and it should be illegal, just like other predatory business practices are.
I'm also not sure why you are offering Web Components as an alternative because it's exactly what you are criticizing, stuffing HTML into JS. It's basically just a more limited and less ergonomic version of React class components, that comes with it's own host of unique headaches.
[1] https://deskthority.net/wiki/Mitsumi_standard_mechanical
That being said, I've been working with NixOS recently and it's made me reconsider what is useful for a configuration language. In many reasonably large software projects, where configs become very complex, config reuse (in other words templating or meta-configuration) becomes an increasingly helpful feature. Nix configs are great because it's not just a config, but a full blown purely functional language for manipulating the config. It's intuitive and powerful once you get the hang of it, and I sometimes find myself wishing I could use it when I have to work with yaml, json, etc.
https://www.axios.com/2023/03/20/bezalel-smotrich-jordan-gre...
The system can't be "just changed" because it's a very complex issue with a lot of entrenched interests. There has to be sufficient political will at the top levels of government that simply doesn't currently exist (in either the Democrats or Republicans).
The language's "declarative style lambda syntax" makes code overly-complex. Every library is basically it's own DSL and every lambda context has it's own set of specialized keywords. If I write `test { somthing(value) }`, depending on the context, `somthing` could be invoking a higher-order function, calling a method on an object that the lambda is extending, or calling a static method. The muddling of data/declarations and procedures, makes jumping into new codebases confusing and time-consuming. Rich Hickey has pointed out in numerous talks that syntax itself is complex because rules and order are complex, but in languages we generally trade a little complexity for terseness. Kotlin encourages this trade-off far too much in the direction of complexity, and the language would be almost unusable if not for it's IDE support.
Getting to the root of the previous problem is that method extensions in general feel like an anti-pattern. Without introspecting a method call, it's not possible to tell where that functionality is coming from. It's a huge amount of added cognitive strain to have a classes functionality split into various files, possibly across various code bases.
Another problem is coroutines (oh joy, another new DSL to learn). By now, it should be known, from languages like Go and Erlang, that preemptive lightweight threading is almost always going to be better than cooperative. It avoids function coloring, keeps throughput of applications more consistent, and is generally easier to reason about. Java also now has preemptive lightweight threading via virtual threads, but because much of the Kotlin ecosystem is reliant on the coroutine API, it don't get any of the ergonomic benefits.
If you are debating the statement I made: "It's clear just from using the language that it was designed as a more 'serious' Javascript replacement", it's simply a fact that the Dart language was originally designed to be a Javascript alternative in Chrome, and the language clearly takes a lot of inspiration for Java and C++ which are widely used at Google.
> Maybe I am confused. We are comparing Dart to what again?
I'm comparing it to other garbage collected languages. I don't think Dart really even has a backend story, but in that case I would compare it to Go, any JVM language, and Javascript/Typescript. For frontend applications I'm comparing it to Javascript/Typescript.
Maybe you could tell me what about my comment is confusing, but I'll rephase it and add some more context. From everything I've read, the Dart team at Google is small an insular. Google has a nasty reputation of cutting niche products and has been doing lots of layoffs in recent years. Even though Dart has an good UI library, there are numerous attractive alternatives that are more familiar and popular. Putting all that information together, I would not choose to use Dart for basically any new project.