61–70 of 95 posts
Earlier quoted context omitted.
Gren took the worst thing about Elm and made it even worse: https://news.ycombinator.com/item?id=36275171
Oof, why do this? What is the reasoning?
Gren is very open to contributions. This can radically change how this enforcement impacts users in practice. It's too early to say really.
The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be tr…
Absolutely false.
The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be tr…
“making it impossible to actually use the language in production” Absolutely false.
Earlier quoted context omitted.
It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They do…
Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?
Elm was the most fun I ever had developing a browser app. Then they decided I shouldn't be allowed to develop a ShootMyFoot module, and it stopped being fun overnight.
The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be tr…
If you want to try TEA, but not Elm I reccomend Scala.js with Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian gives you the elm architecture in a very pragmatic way. [1]: https://tyrian.indigoengine.io/
The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming.
But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. This was primarily one of the reasons I avoided Kotlin+Gradle JS target because among other issues the feedback loop was 2-3x slower.
Earlier quoted context omitted.
Out of curiosity, what did you try to do that you hit that issue right away? I've been writing Elm apps as side projects for years, and never even come close to the kernel thing being a problem. My apps are mostly graphically undemanding games and helper tools. What are the types of applications where this becomes an issue right away?
In my case, it was a regex supplied by the user. Elm 0.18 had no support for constructing a regex at run-time. So I made a package that wraps native RegExp. When 0.19 was released, I couldn't upgrade because of those 5 lines. The regex package eventually got regex.fromstring(). So I could've upgraded. But at the time I was bumping against limits accessing Intl and I really hated the prospect of begging some maintaine…
Earlier quoted context omitted.
If you want to try TEA, but not Elm I reccomend Scala.js with Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian gives you the elm architecture in a very pragmatic way. [1]: https://tyrian.indigoengine.io/
Are you actually using this in a non-trivial application? The recurring complain I hear about scala are the bad compile times. I haven't used the language much, so not sure if this only applies to libraries that heavily use compile time metaprogramming. But I really love that with modern tooling we can get a sub-second editor->browser feedback loop even for a three year old medium-large project on modern hardware. Th…
Earlier quoted context omitted.
It's incredible that on just about every piece I've ever read about Elm since they made that decision, this has been the first, second, and third comment. Wanting to try Elm for myself, I disregarded this advice, and.... immediately ran into the exact same problem! I've never seen such a promising project so conclusively killed by pure developer pigheadedness. And, amazingly, they've never backed down at all. They do…
A purity pledge is very typical of cults. It's both a filter and an enforcement mechanism. This may not apply to Elm. But I imagine it can feel easier and more rewarding to manage a community that's more like a cult than a typical free-for-all open source project.
The website tells the full story: https://elm-lang.org/ © 2012-2021 Evan Czaplicki
What story does that tell? React's would say 2022 - https://github.com/facebook/react/releases There's engineering effort happening behind the scenes on both projects, the releases have slowed, and big changes are coming to both Elm and React.
The year in this link is very important. In the following year, the Elm team decided to not pay attention to the maxim "perfect is the enemy of good" and crippled their FFI story, making it impossible to actually use the language in production[1]. I would recommend to steer clear of a language that makes these sorts of decisions -- that certain features are off-limits to the regular developer because they can't be tr…
> The year in this link is very important. In the following year, the Elm team decided to [...]
The blog post was released a year after the official release of Elm 0.19 where the access to native code was further restricted in the official compiler.
It was not something that happened without ample prior notice, see for instance a post [1] by the Elm language creator in March 2018 in which he explains his reasoning for the upcoming change. Or another in March 2017 where he announced that intended change [2]. Even in 2015 he actively discouraged people to rely on these undocumented features and other hacks [3].
I also was not happy with that choice and felt the pain of something being taken away that was possible before, but that didn't stop me from using Elm at work nor from using it for fun.
So far I haven't found an alternative that I liked better, so I will stick to it.
[1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826 [2]: https://groups.google.com/g/elm-dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]: https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...