Crystal 0.24.1 released(github.com) |
Crystal 0.24.1 released(github.com) |
But I fear that the problem they solve isn't big enough. For desktop/mobile apps, they need a UI framework so I suppose they're targeted at web or network/system programming mostly. However, "Faster Ruby" or "Faster Python" is, in practice, solved by faster hardware as well. At the same time, for web apps to truly scale you need more than just a constant factor increase in speed - you need to handle parallelism better. This is what Go and Erlang/Elixir do with green threads, or Rust with its borrow checker.
This is why I've been surprised that a well thought out and polished initiative like Crystal doesn't do anything in this area, and makes me fear that its popularity might not last. Nim was all over HN a few years ago and now not seen that much anymore - Crystal is obviously different from Nim but they tackle many of the same problems in similar enough ways.
I fear/hope that, because of this, languages like Pony[0] will stick around longer - it seems to combine the best ideas from Crystal, Erlang and Rust in an ergonomic way.
It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.
A friendly reminder I posted over on reddit :)
To be honest I am unsure what Pony provides that Nim doesn't. Perhaps I just haven't looked closely enough at it.
One thing I do know is that from my years of using Nim I never had any trouble with parallelism. There are no green threads, but there is a solid thread pool implementation[1] and a mechanism that ensures memory isn't shared between threads without a lock or a channel (GC safety)[2].
Maybe you could give me a TL;DR of what Pony does better? :)
Quick read: https://tutorial.ponylang.org/types/actors.html
I think one could implement a similar system in Nim using the primitives that you posted, plus some kind of channel, but:
1. Such a system is not included in the standard library (?)
2. Even if a package containing such a system outside the stdlib were available, it would not receive the same application and usage by the Nim community, as Pony actors will in the Pony community
3. So, Pony is better suited to foster a community for highly concurrent programming
That ship has sailed years ago.
I don't know about the mobile story, but there are Qt bindings for crystal.
As for parallelism, it is not done but it is in the works, so it is not ignored, it just is hard enough that it isn't possible to just wish for it and it appears. The concurrency story is already pretty strong though.
Then use FreePascal/Lazarus for your client. Don't know about the state of the mobile libs, but Delphi/FP perfected desktop UI development a long time ago. Decouple backend into whatever you want so you have an asset that is UI agnostic.
Make a PR here: https://github.com/adambard/learnxinyminutes-docs
https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
... providing light-weight threads, and possibly going to support M:N coroutine:thread multiplexing(?). Let's hope.
I guess the trade off is that if it's a part of the language, you get it standard and built in as a language construct. But if it's in an external library, you can use different actor systems and benchmark them accordingly.