Elm Compiler Written in Elm
github.com
github.com
Their mind will be blown, probably.
Not calling you out or anything, but could you give a reference on that? I'm curious about what they're doing with a "DRM" in the compiler.
Check tester89 link - it’s the description about the state of Elm right now. Author’s experience matches my personal one.
Essentially, the compiler only allows packages published by two official Elm Github organizations to include native code. I'm not sure what the process is if a key "native" feature is missing, as this limitation also drove me away from the language.
[0] https://discourse.elm-lang.org/t/native-code-in-0-19/826
What does that mean?
I know they have a strict vision of what features are better left out, and in a way I wish more langs'd be vocal about that. Go does the same and they seem to get a lot of praise for it.
Just like in Go, the Elm team only allows some features to be used by their own (std-) libraries. This, again, is a design choice.
No group was hurt enough to "fork" Elm. PureScript can be seen as a close relative that is less restrictive.
The Elm developers have a history of ostracizing people who even mention the possibility of forks from the community; tester89 posted a link with a lot of good context.
They take a very heavy handed and adversarial stance to development. I had just started getting into Elm when the news of .19 basically breaking everything and the core team just brushing off peoples cries and it soured me on the entire language.
When pre-v1 Go broke things, `go fix` was there to at least try and help.
We weren't bit by the removal of native/kernel code, but it definitely turned a lot of people away that may have been committed to Elm before.
We also ported our Elm codebase from 0.18 to 0.19. It took us almost a week working almost 24/7 across two timezones to make the damn thing compile again. Did not see the UI for the entire week, but once it compiled it (mostly) just worked like nothing had changed (that's after 429 files changed, 16422 insertions(+), 12116 deletions(-)).
My colleague took notes of the progress at https://gist.github.com/mordrax/efcd34739ed56bb64d2b12d2401b...
> We have until Friday 7th September to upgrade to Elm 0.19.
I'm completely ignorant about the transition, but I'm curious what the source of this deadline was. Would you mind expanding?
At our company it was much less drastic. At the time we had about 35kloc of Elm and it took me one evening of Vim macro frenzy. The trickiest things we encountered were an elm/http API change and temporarily vendoring packages that didn't yet upgrade themselves.
I'm not defending Elm team members being rude. But when I look at Elm I see a much better designed language than Go, run by a much smaller team. Elm changes quite minor things in pre-1.0. Go forgot that polymorphism is cool, nulls are bad, etc. Now Go wants to fix some of that, but that would create a new notion of idiomatic Go that it's std lib is not in sync with.
To some extend this is a fate all popular languages befall. Look at Java for some sci-fi, or even better C++.
This is unnecessarily dramatic, and far from the truth.
You're more than welcome to create a fork, as long as you name it something else. This is so people are not confused as to what they are getting into! :)
Feel free to ask me anything about the project, although bear with me - I'm learning compilers/... on the go, didn't study them or anything.
> eieio (Enforce In-Order Execution of I/O) instruction
> Ensures that cache-inhibited storage accesses are performed in main memory in the order specified by the program.
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.
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
Ability to compile code in browser allows to do sandboxes, or tools that otherwise would require a server.
Other than that my best bet for native binaries is most likely compiling to C or GraalVM (which already exists as an experimental backend in elm-in-elm via Truffle!)
QBE: Compiler Backend - https://c9x.me/compile/
QBE vs LLVM - https://c9x.me/compile/doc/llvm.html
That said, I suspect that given how fun the language is to write, supply probably outpaces demand a bit. Which is actually good, in the sense that for many companies adopting a somewhat less mainstream language one of the main concerns is "will I be able to hire for this?", which generally the answer is "yes, especially for more senior positions".
- PureScript has a small but passionate community, one of the biggest players in that community laid off their whole ps team so that doesn't bode well.
- ReasonML fractured into ReScript but left half the Reason community behind, it's a confusing space to navigate now.
- GHCJS...
Most (perhaps even all) of the job postings end up on the elm slack (rather than, say, reddit or other more visible places).
There was some controversy with the release of 0.19 a couple of years ago, and general contempt (in the wider community, not inside Elm) for the way the language is developed and run which means there isn't a great deal of buzz about it outside of those already using it.
I was also wondering, does Blazor work with F#? That could also be an option. Not a front-end focused language but a front-end focused framework, so, there's that.
Now what we really need is a functional dialect which compiles to TypeScript...
Why would it be beneficial to have TS as an intermediate representation? It turns into JS anyway, and there are already statically typed functional languages that compile to JS.
Only stage 2, so whether it'll get through to next stage is up in the air, will depend on interest (compare to Temporal which started fairly slow but has gained huge momentum recently and is now at stage 3 and engine testing level) but it's encouraging.
Typescript encourages and is generally more conducive to a different style of programming. That's OK (in fact, clearly it's more than OK given its popularity) but it's not really the sort of thing I want to be writing. I think it's worse if you commit to something like fp-ts or the fantasyland stuff, personally.
I wouldn’t let that dissuade anyone. Even if support diminishes, the language is feature complete, and FFI is so stupidly easy you can freely co-opt JS libs as needed.
With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much easier refactoring.
TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code.
I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).
Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.
Using job postings isn't really that useful. If they where any indication then the two only language in existence would be Java and C#. That depends on where you live of cause. E.g. there are plenty of Python jobs around where I live, but they aren't frequently posted on the regular job sites. I'd suspect that Elm jobs are posted where Elm developers are to be found.
Can't speak for the community as whole, but there is at least some demand: the company I'm working for is actively hiring Elm devs for at least two teams at this moment :)
I find it slightly funny because I also write Svelte at work and that app is public facing so it gets public attention but the Elm app is internal facing so the public will never see it. Also helps that Svelte uses its own name in the code it generates. Which is why I try to promote Elm myself. To semi-quote @SvelteSociety "@Square, a >$100 billon company, uses @elmlang."
Of course if you'll be running elm-in-elm in the browser, you won't be able to do that. But there are more interesting things to do with a compiler in the browser :)
I mean, being able to bootstrap is nice and nerdy and so on, but I believe exposing the parser, optimizer, type inference etc. as standalone functions will be the most impactful aspect of the repo, in terms of enabling better tooling in the Elm ecosystem.