3 ms·

One's attitude towards Elm directly correlates with the degree to which one likes to dig into and tinker with the internals of their tools and frameworks and re

One's attitude towards Elm directly correlates with the degree to which one likes to dig into and tinker with the internals of their tools and frameworks and rearrange things. Unfortunately that means it's a hard sell around HN-- in a way it's antithetical to "hackers". But I don't think it's antithetical to John Carmack's proverbial "engineer"-- someone who wants to do what they can do with what they've actually got. Elm lets me do what I want to do, exceedingly efficiently and makes it fun, and that should make it a good choice for plenty of projects.

andrewzah 5y ago
I don't buy this argument. I am also someone who just wants to get shit done. I've never had an issue with php, c#, ruby, crystal, go, rust, haskell, erlang etc's compilers/interpreters in terms of letting me get what I want done. Yeah, I haven't actually forked or patched those compilers but neither have they been hostile to their users. The reason I would use literally any of those except Elm is that the maintainer(s) of Elm act like they're Steve Jobs. How can I "get things done" if I'm being told "oh no, you're not allowed to do <standard-thing-X>, we've decided that only us on the Elm team can do that". With other languages, I'm not worried about a version bump pulling the rug out under me, effectively trapping me in the ecosystem unless I want to rewrite everything in a different language. That is also directly the opposite of being productive and getting things done. There is nothing about an autocratic "you're holding the compiler wrong" governance model that makes any part of a language itself more efficient or fun. Plenty of other languages are as (or more) efficient and fun as Elm, but without the patronizing and condescending attitude of "you're not as smart as us, so do as you're told, and no you can't discuss this with us". There is no way I could justify the risk of adopting elm professionally given the entire rest of the programming language world... doesn't do this. Let me be the one who decides to shoot my own foot off; even Rust (a language pitched on memory safety) allows this with unsafe, etc. If one wants to control everything exactly and go against almost every other language and most F/OSS projects, then just... make proprietary/source-available software. F/OSS is a give-and-take, and nearly all of us have taken far more than we've given. And I don't know what John Carmack's "proverbial engineer" is, but I think just about any engineer would prefer to be in control of their tooling and not at the whims of maintainers.
- johnkelly 5y ago
  > How can I "get things done" if I'm being told "oh no, you're not allowed to do <standard-thing-X>, we've decided that only us on the Elm team can do that". I think this is common in almost any language. For example, in JavaScript there isn’t a way to turn off the garbage collector. Why are browser authors limiting us? I’m sure they have good reasons - reasons that I may not fully understand but that’s fine! Maybe this isn’t the best example but I’m sure you or someone else could think of one for me. Anecdotally, even when lower level/advanced features are exposed, I personally haven’t had the need to reach. For example, say python allowed for custom memory management features - I’ve never had the need for them! And I’m just fine working on a large django application with thousands of concurrent users. This isn’t to say I will never need some advanced lower level feature of python, however, I haven’t needed for >5 years. The point is, if elms feature set works well for most of its applications - what’s the problem? The creators have a vision for the constraints of the language! Which is directly related to the intended goals and benefits of the language

andrewzah 5y ago

I don't buy this argument. I am also someone who just wants to get shit done. I've never had an issue with php, c#, ruby, crystal, go, rust, haskell, erlang etc's compilers/interpreters in terms of letting me get what I want done. Yeah, I haven't actually forked or patched those compilers but neither have they been hostile to their users. The reason I would use literally any of those except Elm is that the maintainer(s) of Elm act like they're Steve Jobs. How can I "get things done" if I'm being told "oh no, you're not allowed to do <standard-thing-X>, we've decided that only us on the Elm team can do that". With other languages, I'm not worried about a version bump pulling the rug out under me, effectively trapping me in the ecosystem unless I want to rewrite everything in a different language. That is also directly the opposite of being productive and getting things done. There is nothing about an autocratic "you're holding the compiler wrong" governance model that makes any part of a language itself more efficient or fun. Plenty of other languages are as (or more) efficient and fun as Elm, but without the patronizing and condescending attitude of "you're not as smart as us, so do as you're told, and no you can't discuss this with us". There is no way I could justify the risk of adopting elm professionally given the entire rest of the programming language world... doesn't do this. Let me be the one who decides to shoot my own foot off; even Rust (a language pitched on memory safety) allows this with unsafe, etc. If one wants to control everything exactly and go against almost every other language and most F/OSS projects, then just... make proprietary/source-available software. F/OSS is a give-and-take, and nearly all of us have taken far more than we've given. And I don't know what John Carmack's "proverbial engineer" is, but I think just about any engineer would prefer to be in control of their tooling and not at the whims of maintainers.

johnkelly 5y ago
> How can I "get things done" if I'm being told "oh no, you're not allowed to do <standard-thing-X>, we've decided that only us on the Elm team can do that". I think this is common in almost any language. For example, in JavaScript there isn’t a way to turn off the garbage collector. Why are browser authors limiting us? I’m sure they have good reasons - reasons that I may not fully understand but that’s fine! Maybe this isn’t the best example but I’m sure you or someone else could think of one for me. Anecdotally, even when lower level/advanced features are exposed, I personally haven’t had the need to reach. For example, say python allowed for custom memory management features - I’ve never had the need for them! And I’m just fine working on a large django application with thousands of concurrent users. This isn’t to say I will never need some advanced lower level feature of python, however, I haven’t needed for >5 years. The point is, if elms feature set works well for most of its applications - what’s the problem? The creators have a vision for the constraints of the language! Which is directly related to the intended goals and benefits of the language