Are the elm overlords still hell bent on "thou shalt program our way or not at all"
Because that kind of dogmatism is a complete show stopper for languages that want to be deployed on even medium term projects.
Because that kind of dogmatism is a complete show stopper for languages that want to be deployed on even medium term projects.
I maintain long lived applications. Sooner or later we __always__ have a need to call out to the host environment to work around limitations of the compiler/runtime.
Not being able to do so, and the attitudes of the core elm team that prohibit such actions, make elm a non starter for me.
In the end, it may be a showstopper for you, but go is the prodigal child of "my way or the highway", and it's doing just fine in many production environments.
I'm not even close to being an overlord or contributing anything to the language (just a consumer who has been very happy with how everything's been working so far) so the fact someone like me is even aware this is going on is mildly troubling. Other libraries I'm fairly familiar with (Pandas in Python, React etc) seem to tend towards quietly releasing without all the public drama among contributors.
Not sure whether it's because it's a smaller community or more of the help/documentation is on places like reddit or discourse (where the overlords argue - vs something like stack overflow), or whether everyone involved just needs thicker skin.
Either way, it's only a mild annoyance to me for now and I really like Elm overall. Would encourage anyone interested to check it out.
Problem is, 0.19 has been underway for a looong time, and is still unclear when it'll be done. They also have this weird thing were they are heavily pushing and promoting the language, and when you complain about these kinds of things, you'll often get back a "this is to be expected of such a 'young' language", which seems contradictory to their narrative of "look at all these companies using them in production".
Personally, I quite like a lot of the parts of Elm. A bit too simplistic for my taste type system-wise, but that is also it's great strength when having to onboard/convince new developers or colleagues. That said, I'm waiting on 0.19 before seriously considering Elm any time again.
This is not to say that Elm is bad. O think it's great as a path into FP, and in fact _was_ my path in. But it does limit you in what you can do and learn.
Also, Purescript has this interesting property of being hard to learn (because it is powerful), but dead simple to use (because it compiles to JS). So you only really get stuck on figuring out how to do things in PS, as opposed to how to get PS working, and therefore every time you get unstuck, you have leveled up. So it's hard, but rewarding.
I'm probably off topic by now, but I do think that Purescript in the frontend is a better option for solid application development.
a) Type classes/interfaces.
b) "Native JS for me, not for thee". Much like Go gatekeeps generics to the language authors only, Elm restricts native JS access only to the language runtime because devs "might get it wrong"; forcing them to use the ports system, where they have to type the use of even perfectly pure JS code as a side effect.
c) The official package manager forbids the upload of any package that interacts with JS without the blessing of the BDFL.
I'm aware on the tradeoffs of each case, I understand Evan's intentions; but I heavily disagree with them, which is why I don't entertain Elm as an option for production use anymore and would rather go with something like Reason despite being less knowledgeable about it.
It would be more accurate simply to say that Go lacks generics. I don't know of many statically typed languages that have arrays but which don't allow you to type an array of integers differently from an array of strings. Go basically has that feature, plus built-in hashtables that are also type parametrizable. Characterizing that as some kind of huffy refusal to allow people other than the language authors to use generics is arguably inaccurate. Adding generics to Go would require fundamental changes to the type system, and would have some nasty interactions with interfaces. It's not a matter of flipping a switch.
What it would take to add generics to Go now is a separate matter. Feel free to link my Go commentary to my point on lack of type classes on Elm if you want to see it from the perspective of changing an existing language.
My point is that essentially all statically typed languages allow parameterization of built-in datatypes. C does this, for example, since it distinguishes arrays of ints from arrays of pointers to ints. No-one usually says that C has generics, special-cased or otherwise. The idea that adding generics is "just" a matter of extending parameterization of arrays to user-defined data types seems to be largely limited to anti-Go rhetoric. The implicit suggestion is that the Go designers could have chosen to allow users to parameterize their own types, but didn't do so because of [insert bad intentions]. In fact, adding a true generic type system to a language is a vastly more complex undertaking than merely allowing parameterization of built-in types. It totally makes sense that a language designer might decide to do the latter but not the former. It's not an arbitrary restriction tacked on because Rob Pike doesn't trust you to use generics correctly.