Earlier quoted context omitted.
The compiler has hard coded domains that control who can use certain features. For example, custom operators aren’t allowed, but Evan is able to use them.
Why.... ?
Because.
Road to Elm 1.0
171–180 of 192 posts
Re: Road to Elm 1.0
#172Earlier quoted context omitted.
Does it though? They are many longstanding bugs reported in their compiler repository, and this release doesn't seem to address any of them.
Longstanding issues that prevent usage? Not for me and the projects I’ve been apart of. No doubt there are plenty of reported issues, and no doubt they truly negatively impact some users, but I would still much rather choose the usability and stability of Elm 0.19.1-2 than anything in the typescript ecosystem today
You don't have to choose between Elm and TypeScript though, there are so many other options now - Haskell, F#, Rust, OCaml, just to name a few.
Re: Road to Elm 1.0
#173Earlier quoted context omitted.
Elm was better without custom kernel modules and sync JS-interop. It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries. It has enable me to port the small kernel now to C++ for an Elm to native compiler. Also, if you really wanted to bypass it and have your own kernel, that was always possible and not har…
> Elm was better without custom kernel modules and sync JS-interop. That may be true, but what would have been even better is never having the feature, as opposed to adding it, allowing many people to become dependent on it, and then taking it away. (Like everyone else, I'm not claiming Evan should not be able to make such changes -- just that making such changes will breed predictable resentment.) > It kept the Elm…
Custom kernel never was a feature the language had. It was an implementation detail that people discovered they could hack, but it was never meant as a feature.
Re: Road to Elm 1.0
#174Earlier quoted context omitted.
On top of the already-mentioned JS interop breakage, Elm 0.19 also dropped native Websocket support[0]. The API had issues (fair), so it was dropped rather than improving it due to wanting to do it perfectly (okay, I guess), buuut due to the JS interop restrictions this meant that 3rd-party experiments or alternatives were impossible (??), which meant that any use of Websockets was in practice now completely impossib…
Elm was better without custom kernel modules and sync JS-interop. It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries. It has enable me to port the small kernel now to C++ for an Elm to native compiler. Also, if you really wanted to bypass it and have your own kernel, that was always possible and not har…
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries.
Writing everything yourself is not innovation. It's busy work.
Sure it's a good way to learn a language, but when you just want to build an app why would you build yet another searchable select when there are more than enough JS options already available....
Re: Road to Elm 1.0
#175Re: Road to Elm 1.0
#176Earlier quoted context omitted.
FFI is still mostly done through ports (or web components, for the view part). This is an intentional choice and likely to stay until 1.0 and beyond
You can also do lunatic things like overload the `Object` prototype and get synchronous FFI by encoding then decoding an object. I do this at work to get locale-aware sorting. I know you know this, but it'll be news to others in the thread.
Haha, yeah I didn't realize there would be a monkey patch route to FFI in Elm. Can't control the runtime. Is there a good read up on this technique?
Re: Road to Elm 1.0
#177Wish them all the best, I really respected the efforts made to normify some of ideas with unapologetic mathematic names like monads and such But then you see stuff like this https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ The author is very charitable in their description of the Elm Core teams actions in these interactions, but you read it and they come off entirely unaccountable and dismissive. If they want t…
I see all these people complaining about Elm limiting privileges to certain Github projects. A sensible complaint. But why hasn't anyone simply forked Elm, made the small tweak to make the check function return true or whatever, and offer that as a download/patch to the community?
I understand that defaults matter and that can have a large impact on the flow of libraries and code and stuff... my point is more, if you've got production code bases on this language, or at least, did 6 years ago, why so helpless? Nothing makes the point that an open source project can't dictate to its customers like the customers taking the "open source" part seriously.
I don't actually expect that to "work". What I expect to happen is that in the second-order effects that it would resolve this matter one way or the other once and for all. Either the core language realizes they need to accept the change, or the community works around the blocker, or the core language goes closed source and removes all doubt and people can move on, including their production services.
Re: Road to Elm 1.0
#178Earlier quoted context omitted.
Yeah Elm has had a very strange arc, but I think calling it a research language is right. There was a period where it was heavily evangelized. Many blog posts were written and talks given, and there was a lot of enthusiasm and adoption. Then the author just kind of disappeared and the project stalled. Which of course he had a right to do since it’s his project, but I think he should have set expectations better from…
> Then the author just kind of disappeared and the project stalled. There was more to the story than that. They made some major breaking changes in v0.19 that broke a lot of apps and left no path for them to continue with Elm, then dug their heels in when the community protested. If you had an app at your company that used the features they decided not to allow any more, you either had to start deciding which fork to…
For a non-fork that has appeared recently, Sky: https://news.ycombinator.com/item?id=47662116
It's vibe-coded (hmmm), Elm syntax, server-side, SSE, compiles to Go, Go FFI, TEA, web/cli/TUI/desktop targets, consistent Db, Ui - a lot of things to like if it all comes together.
Re: Road to Elm 1.0
#179Earlier quoted context omitted.
Elm was better without custom kernel modules and sync JS-interop. It kept the Elm kernel small and portable. It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries. It has enable me to port the small kernel now to C++ for an Elm to native compiler. Also, if you really wanted to bypass it and have your own kernel, that was always possible and not har…
> It forced the 3rd party package eco system to innovate and create things rather than just wrap existing Javscript libraries. Writing everything yourself is not innovation. It's busy work. Sure it's a good way to learn a language, but when you just want to build an app why would you build yet another searchable select when there are more than enough JS options already available....
IMHO this busywork is (mostly) preferrable, because it meant that any package was truly pure Elm, and you could blindly trust it not to be some wrapper that crashed at runtime.
It's a tradeoff, sure. But this way, Elm didn't become just another "JavaScript with better syntax".
Re: Road to Elm 1.0
#180Earlier quoted context omitted.
On that note, because of AI I've been more into music, bought a midi keyboard, got real DAW software setup. I've also finally built more and more with Rust, and have been reading more Rust docs. LLMs should never be an excuse not to learn the things you're using it for, those are the bad engineers. An LLM affords me the time to research and learn what it gave me so I can maintain it. It's easier to prompt about the p…
If you have a blog or something anywhere, I'm very interested in your journey.
I do though I havent been blogging as much, its a blessing and a curse to have a SSG based blog. I would love to have an SSG engine that I can use remotely from anywhere, currently using Publii.