Edit: Ok, looks like there is a "why" section on github!
The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.
- tooling is abyssmal ( IDE etc ... )
- no mutli threading
- no real support, I'm not even sure if there is one paid guy anymnore on the project
- it's still immature
- they break the API all the time
As others have mentioned this is a side effect of how young it is.
> - no real support, I'm not even sure if there is one paid guy anymnore on the project
If paid support is all that counts then most languages would fall into that.
> - it's still immature
Tautological. Nothing can become mature without first being immature.
> - they break the API all the time
Isn't that what a 1.x is for? A stable major version?
Can you name another recent programming language that wasn't developed in-house at a major company. Go , Dart , and Rust all started out with paid teams of programmers working on them.
Not sure if Crystal will be able to progress at a rate fast enough to keep people interested. Likewise, you'd have to be insane to try and pitch this to your project manager. I consider myself to be a risk taker, but even for my own side projects I stick to older better known programming languages.
it feels like we keep trying to solve the same problems over and over again instead of utilizing solutions which already exist
Modern python has grown significantly from its first release in the 90s though. I don't think that can happen today, we all want too much out of our programming languages.
Unfortunately that’s not true at all - Python is far from simple. Sure, it’s no C++, but it’s very complex compared to languages like C, Go, Lua, even JavaScript.
The compile times are largely a side effect of the underlying language design, and it isn't likely to get significantly better, which is why I mentioned it.
- no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts.
- no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions.
- still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube).
- API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)
So what is the performance like?
With the caveat of course being that benchmarks don't always reflect real world performance.
I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .
I believe you can speed up your compile times a bit by being explicit with annotations (which I often prefer anyway), but there's still a lot of overhead for the global type inference.
Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.
Scala has both, F# too (though function overloading is possible, I think it's not idiomatic), OCaml has named arguments, Haskell has overloading.
This is a sweet spot for anything web-server related (which is quite a lot, these days, considering mobile API's and such...)
I would actually hesitate to use a framework for many use cases, although Amber and Lucky are competing for a "soup-to-nuts" total platform, Kemal fills the Sinatra/Express niche nicely, and you really find yourself wondering what you want.
The "shards" module system is very nice, and no external tool is needed, it comes with Crystal.
No need for a C FFI, you can directly wrap the C ABI or C libraries and call both ways (from C to Crystal, from Crystal to C)
It's not Rust nor C nor C++ but more like a better Go, in terms of being a statically typed compiled language that, nonetheless, is garbage-collected (everything is an object, check the API docs I linked above) but it's syntax is like Ruby, and so it' basically eats Elixer and all that's lunch... (Lucky takes on Phoenix, Amber takes on Rails? lol)
It's also extremely fast, and the memory footprint is tiny... (anecdotal, but a 40kloc that was around 500mb ram on node is currently using 12mb)
The compiler catches many errors and long-running applications don't apparently leak memory (cough cough anything dynamic) and one has the feeling that the static typing is allowing stack-frames scoping and Boehm to play nicely together, but this is just anecdotal.
I guess you have one way to find out "Why Crystal"
Let's not HackerNews Bikeshed this to death... go try it... you'll probably like it.
Tooling? I use gedit, so I'm the wrong guy to ask. It works fine on most "ruby" presets for text coloration/highlighting whatever you call that stuff...
It's right here:
The importance of asking why is that you validate whether a project is some ego trip or a legitimate finding worth pursuing.