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.
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.
If you want to divide into two camps how 0.19 was received I'd say it's people who were maintaining a substantial Elm project on the one side and people who weren't on the other. Maybe if you're carrying a torch don't drop it on the ecosystem.
Back then if I wanted to search a list of strings for entries that match a regex supplied at run-time, I'd have to pass the whole list through a port, filter it outside, then pass it back in. Rather than just using the filter function. Ports are asynchronous messaging which means I have to restructure the whole code and wait for a state change when the filtered list is returned.
Let me cite the Elm docs on ports[1]: "Definitely do not try to make a port for every JS function you need."
So! Where does that leave me? Unsupported, that's where. Because I need a JS function. In 0.18 unsupported was fine. They broke it for 0.19 and the project died. Maybe it was dying of other causes anyway, but that one action sure drove people away.
There are a bunch of other options/workarounds/hacks depending on the need. E.g. using getters or creating proxy objects https://github.com/anmolitor/intl-proxy, or event listeners, or postprocessing of the generated JS code, but those shouldn't be the first idea to reach for.
The last commit to the regex package was in May 2018, and Elm 0.19 was released later in August. https://github.com/elm/regex/commits/1.0.0/
So it seems like by the time of the official release you could have replaced your five lines with `Regex.fromString`.
But the missing Intl API is definitely a huge pain, and I understand that you were switching away if you needed it extensively. Or expected to want other sync APIs wrapped.
A common way to solve something like this is with proxy objects like in https://github.com/anmolitor/intl-proxy but it does not give access to every feature in a nice way.
I went the route of least resistance and built the Elm compiler without the Kernel code check. But in the past few years I hardly needed that anymore.
I think this is very, very different. First because Go didn’t have a cultish purist aversion to generics, banning people, going after them even outside of community spaces. But on a technical side, maps (and slices and channels) were not gated to be used by std, they were publically available to anyone. Not having generalized a feature is not the same as banning it. There was not even Go syntax to express it. Same as arrays in C, no?
That said, I’m not challenging the recommendation to stay away or not - generics was (and still is, may I add!) quite a pain point with the language. I’m personally quite invested for other reasons (concurrency, networking, std lib), but people come to different conclusions naturally.
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.
I just don’t understand the reasoning for this choice.
https://github.com/Zokka-Dev/zokka-compiler
edit: there's also Roc, https://www.roc-lang.org/, a language started by Richard Feldman who I believe was a former elm core team member. I think Roc aims to accomplish different things than elm, but definitely feels like a spiritual successor
Here's a good (neutral!) write-up: https://ersin-akinci.medium.com/confused-about-rescript-resc...
Just FUD. I've been on a big team writing a webapp used by hundreds of thousands each day. While it's not necessarily my own first choice, it was great and the least error prone piece of software I've written in my career.
Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.
Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for.
If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
If that's the level of discussion you want, I'll pass. And perhaps you should reflect on if you yourself is a great team member, if this is how you conduct technical discussions with your colleagues..
You'll note that I didn't get immediately riled up on you calling my original post "FUD" instead of asking why I said what I said. And then when I tried to clarify to you how I consider usage of Elm in production impossible, you again attack me directly instead of trying to discuss anything.
So, perhaps you should reflect if you're a great team member if you consider your opening statement to me to be a "technical discussion" at all? I was just trying to respond reasonably for third parties who are reading this, because I consider you a troll.
If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D
Anyways, just building the compiler without that check was also not that hard.
To me it looks more like the elm-haters are out in force and the Elm users don't participate anymore on this site.
Many hateful comments here below a historic post prompted me to create a new account after a detox phase of >10 years.
So far I try to correct a false statement in the (as of writing this) top comment [1] or add a more neutral view [2]. And maybe I will add more of my personal opinion in the future - or participate in other interesting topics depending on my mood.
[1]: https://news.ycombinator.com/item?id=39555542 [2]: https://news.ycombinator.com/item?id=39556395
Absolutely false.
> 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...
Essentially, the go developers saw a need for generics and then decided that only they get to create them, where most modern language developers either make them available for everyone to implement or don't add them at all.
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 trusted to use them correctly -- because if you find yourself in a situation where you need that to solve your problem, you're trapped. I included Go in the set of languages I would recommend steering clear of for years, due to their decision to allow their own `map` type be a generic[2] type but no user-defined types could be[3], leading to ridiculously over-verbose codebases, but they have finally corrected course there.
If you're looking for something kinda like Elm but not likely to break your own work in the future, I'd recommend checking out ReasonML[4] instead.
[1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ [2]: https://go.dev/blog/maps [3]: https://go.dev/doc/faq#beginning_generics [4]: https://reasonml.github.io/