Really loving Crystal, although not using it for any commercial applications (yet). It's really nice for building small command line apps. It has stolen my heart from Go TBH.
I was really into golang too to the point I started doing some production work on it, but after I tried crystal, it became a little dull. Crystal is a great language and surely has a bright future for those who love ruby syntax.
Isn't crystal single threaded only? How do you make that runs fast when you're bound on a single thread or the underlying OS doesn't have async operations. And in the benchmark you linked Go is as fast as crystal and it was go 1.5 which is quiet old.
I struggle to estimate any dev work beyond a few weeks, so I wonder if some of these estimates may be wishful thinking too - maybe the Manas.Tech folks have a good sense of the theory behind the work that’s left though, in which case it’s only (“only”) a matter of implementing it. In any case, I wish them the best and hope that they can release 1.0 next year!
At least for the concurrency work, there's been a lot of groundwork done for it already, and even a working prototype - albeit with a much larger scheduling overhead than we would like.
I suspect that it's a mix of both, these hours numbers are somewhat pulled out of a hat but the concrete of what we actually want to do and how to go about it is known so they won't be wildly off. The manas guys will know the details though.
I think Crystal is a brilliant language [non-intentional pun]. When I teach programming, I have found that dynamic languages are a little harder to explain. Been watching this for a number of years and I hope to see it explode!
I notice they ask financial donations but not help with development. Since we are developers and not investors, we are much more capable of donating our time. What makes code contribution not useful (or irrelevant) in comparison to money in Crystal? It would increase “hours invested above donations”, but it's not a problem as their graph is trying to show.
We gladly welcome contributions, please feel free to donate your time! However there are some tasks that are much easier to deliver and design as a small team, instead of being able to be broken up into small parts where work can be done by the community. We simply doubt someone is going to come along with the time and drive to complete rewriting the whole fiber scheduler and concurrency part of the stdlib as an external contribution.
That being said, Windows support is likely to be largely done by the community and core team in tandem, as individual modules can be ported one-by-one. There's also the overhead of managing all these open-source contributions which takes time.
Probably for "mythical man-month" related reasons. It's far from trivial to manage a large number of relatively small contributions from a large group of diverse developers.
Could modern programming languages adopt isolated heaps with message passing like Erlang does? This is the easiest solution to GC pauses and allows other nice features like hot code reloading.
The majority of programming languages invented in the last 10 years don't seem that different from each other. I'd love to see a programming language that combines the strength of C++ and Erlang for soft realtime workloads.
If you are looking for a modern language with a pragmatic syntax and uses lightweight processes and message passing why not Elixir? It's an expressive, productive language that can leverage The power and scope of the Erlang/OTP ecosystem.
Elixir is great but it most definitely doesn't fit the "C++ strengths" part of the requirements. Contrary to popular belief, Elixir is a slow language. Think Python/Ruby slow for compute-intensive tasks.
It's slow compared to C++, but for most tasks its ~5x faster than python or Ruby. If the task is parallelizable, it will be quite a bit faster. But yeah, you aren't going to be doing math with Elixir. One of the things you'll get with Elixir/BEAM languages is really low and stable latency. You'll never get that with long running Python or Ruby processes.
Well, it's mainly slow in one thing: math. Why? The BEAM uses arbitrary precision representation for most numeric values(Bignum).
From _The Beam Book_:
> There are two types of integers in ERTS, small integers and bignums. Small integers fits in one machine word minus four tag bits, i.e. in 28 or 60 bits for 32 and 64 bits system respectively. Bignums on the other hand can be as large as needed (only limited by the heap space) and are stored on the heap, as boxed objects.
Outside of that, I have found Elixir/Erlang to be very resource efficient. And if you need blazing fast math, you can always implement such computations in C and expose it in your Elixir/Erlang application using NIFs. There are a few golden rules to pay attention to in order to avoid danger, but if you do, you can get great speed. I'm currently implementing a Protocol Buffer library in Elixir and expect to make use of this for increased performance once my library is feature complete(if I find performance to be an issue at scale).
That's because Python has a nice Monty Python vibe. Honestly if people in my CS dorm were watching Monty Python in the common areas 24/7 it would be pretty nice
A simple way to get isolated heaps and message passing is multiple os processes and local sockets; this can be more heavy weight than threads/green threads though.
I've done some experimentation with hot reloading in c lately, and I'm not sure how isolated heaps is a precondition for code reloading.
I suspect the requirement for erlang style code reloading is a willingness to take an indirection penalty for fully qualified module calls and tail call optimization so that the old module doesn't stay in process stacks. In an OOP language, if you wanted to tie objects to specific versions of modules, you'd have to do some intrusive accounting as well.
I also attempted hot code reloading in perl many years ago; it's a lot easier to do when you've seen it done properly, and there are language facilities for it (fdlopen is a lot nicer to use than exec on a pm). In my use cases (which were single threaded), I was able to write an outside loop that's simple enough that it's not a big deal that it can't be reloaded.
If you are wondering why people seem a bit offended by your comment, it's because calling something vapourware has an implication almost of dishonesty or a con.
Crystal is real software that you can use today and build yourself and modify. It's doesn't make sense to accuse it of being vapourware.
This makes sense if you mean abandoned before release.
> "In the computer industry, vaporware (Brit. vapourware) is a product, typically computer hardware or software, that is announced to the general public but is never actually manufactured nor officially cancelled."
I'd hardly call a language with a fully-functioning compiler, a fairly complete standard library, which is being used in production in multiple (albeit small) companies as vaporware.
You should swing by https://elixirforum.com/ and see what's going on in the community. There are a lot of ELixir users who come from Java, OCaml, Haskell, Ruby, C#/F#, and further afield. It's a great language with a really sold niche in building systems with low latency, high availability, and good parallel data processing.
I'd be curious to see actual usage numbers as they've changed over time.