Our great sponsors
-
-
apprun
AppRun is a JavaScript library for developing high-performance and reliable web applications using the elm inspired architecture, events and components.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
I don't think Rescript[0] in fact they are pushing active updates. I think they are trying to make a push into supporting the ocaml ecosystem as well, and not just be a compile to JS language
[0]: https://rescript-lang.org/
Also the fact that their package manager is strongly coupled against https://package.elm-lang.org/. There is no way to override it. This means that if that package site ever goes down, you will be left with an unbuildable project. Seems pretty risky to me.
> That said, they are still under active development
I don't know who would consider Elm to be under active development, given that the last release was in 2019 and most of the repo hasn't been touched for 2 years or more: https://github.com/elm/compiler
Check out Roc[0][1] by Richard Feldman; it's early-stages (perhaps earlier stages than Elm?) but from everything I've seen it looks a bit like a spiritual successor to Elm, though focused more on native applications (but still seems to have its sights set on webassembly support too)
[0] https://www.roc-lang.org
[1] https://github.com/roc-lang/roc
https://discourse.purescript.org/t/recommended-tooling-for-p...
What I found particularly fresh for a Haskell-like language was the cookbook (https://github.com/jordanmartinez/purescript-cookbook) which contains lots of small-to-medium-size realistic examples. They are a great starting point and do wonders to improve the learning experience.
AssemblyScript produces the smallest binary and then Zig. Rust produces bloat binary by default but can be small by https://github.com/johnthagen/min-sized-rust for hello word type of app. I have no idea if the gc proposal could make those langs produce smaller binary size. That said, .wasm is generally smaller on wire and faster-to-execute on host.
> It sounds like you read my statement as "run the exact same code in node or OCaml" which I agree would have been very hard.
Hello! Indeed, I did misunderstand you. I agree that it was possible to share some parts of the code between Reason's JS target with BuckleScript, and native target with the stock OCaml compiler. I think a pretty reasonable number of people did that. Actually, it's still possible to this day even with ReScript e.g. https://github.com/aantron/dream/tree/master/example/w-fulls...
> Between the breaking changes and the general change in development philosophy...switching to the ReScript compiler for my project would have required nearly a complete rewrite.
There were perhaps a couple of minor breaking changes but can you explain why it would have required a near complete rewrite? I wasn't aware of anything major like that. ReScript even supported and as far as I know, to this day continues to support the old Reason syntax.
system76 is using it to develop their new cosmic desktop environment for linux. The code is here https://github.com/pop-os/cosmic-epoch
We'll see how it starts panning out this year or next.
You don't need native code to be productive in Elm. Elm is perfectly useable without it. Use of native code was not widespread before 0.19 anyway.
I would know. I was working on a large native code project that was killed by 0.19. It sucked for me that my project could not continue, but, I can't say that it has made much of a practical difference when it comes to making software applications. My project was called "elm-canvas" and it was about providing canvas support. Since 0.19, other people have found implementations of the HTML canvas element that do not rely on native code (Like Joakin's great 'elm-canvas' https://github.com/joakin/elm-canvas). For my own HTML canvas based software projects, I have been able to find my own non-native code implementations that work pretty well.
So, I think I faced a disproportionate amount of this problem, and I can't even say it has made much of a difference to my own productivity in Elm (and I have written a lot of Elm).
Personally, I wouldn't trust anything that Richard Feldman was involved in. He was instrumental in making the Elm community a hostile and unwelcoming place[0]. To my recollection he has never come out and admitted that the Elm core team was wrong in how they handled any of those things, so why should anyone assume any better from Roc or anything else he's involved in?
0 - https://github.com/gdotdesign/elm-github-install/issues/62#i... (see edit history for full impact)