Crystal 0.25
crystal-lang.org
crystal-lang.org
I think Lucky [1] is actually a more Rails Like framework. ( Or more like both are NOT like Rails. As features rich or heavyweight, Rails provides more then you will ever need. )
I'm hoping to see more languages with light-weight threads automatically mapped (multiplexed) to physical threads, like in Go. So far, based on the crowd-sourced table I started working on, it is otherwise only Ada, Haskell and Pony (in addition to Go) that seems to meet these criteria:
https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
On Java's case it is up to the JVM implementors to decide, the spec does not impose OS threads. Hence why you can find the terms green and red threads on old Java related docs.
Then both support tasks which get multiplexed into the underlying runtime threads.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Saying Erlang is slow is like saying Ruby is slow. But both are built for problems other than crunching numbers. Not a knock on either language.
Crystal is built in the same vein as Nim - meant to be as quick as C++ but easier to write. Erlang was built for a different use case altogether.
"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic." (quoted from the Erlang FAQ).
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
iow the performance of apps which use Erlang a lot, is not necessarily limited by the performance of the Erlang implementation.
Of course, you probably foresaw another classic interpreter-speed justification coming from a mile away, but.... There are very well-developed methods of interfacing with fast native code, ranging from C nodes to nifs. The documentation is circumspect about using C code, but nevertheless provides you with the good, bad and the ugly on these various different methods.
If anything, I think Crystal could crib a page from Erlang and elevate what it calls "Fibers" and "Channels". Erlang made these first-class in both design & syntax, which allowed Pids and messages to be not just building blocks of concurrent interaction patterns, but also architectural utility-knifes in consecutive Erlang code. The more Erlang you read, the more you see this really powerful method of dividing concerns "physically" rather than "structurally", in which you can be doing everything from implementing Objects (for some definition of OOP) to representing recursive data structures with lightweight threads as the "backing primitive". This may be obvious to some old-head Lisp programmers, but I about choked on my latte when I saw this demonstrated at the first Erlang shop I worked in. It's a cool and extremely powerful idea that can be implemented in any language, but is best if the spawn/message syntax is concise.
Erlang is a super cool language and were I doing an app which needs millions of concurrent connections over many cores and/or machines, I'd choose it in a second. But Crystal is more of a (potential) replacement for Java or C++.
Along these lines, the most popular open-source subdivision 3d modeling software package is, outside of the shaders, written top-to-bottom in Erlang (including the engine).
It just so happens that Erlang is frequently used as a network server and can probably saturate the network interface, so its throughput is usually judged to be Good Enough, while the latency is generating the positive headlines.
[0] There are exceptions to everything. If your problem allows you to write code in such a way that the critical path stays mostly inside the VM’s C code, rather than having to keep fetching your instructions, the throughput can impress.
All of those share one thing in common, something which Erlang doesn't have in common with them.
In fact, I think there's a case to be made that it may have the most refined implementation for scheduling M:N processes (along with more advanced thread affinity, alternative RQ dispatching, SMP awareness, etc).
Really, the best way to help the language is to donate: https://salt.bountysource.com/teams/crystal-lang
It's still an unstable language (there are plenty of breaking changes in this release), but I highly recommend it -- especially if you like both static typing and Ruby.
[1]: https://github.com/woodruffw/x_do.cr/blob/master/src/x_do/li...
Crystal always fascinates me when it gets brought up, and I'd really like to dive in sometime.
I thought it was supported by Manas (https://manas.tech/).
A large organization adopting it and supporting it would make a considerable difference regarding adoption.
Now a pressing issue (though not for everyone) is that the compiler needs to escale from the current state because it takes too much memory and too much time to compile, but last time I checked it still wasn't crystal clear how to improve it.
Give up on type inference, or at least type inference across modules and classes.
But I haven't found a reliable way for building a binary on a Mac OS without requiring dyld already be present on the target user's system. Seems none of the following issues are resolved, or that the project has indicated a recommended way to do this?
https://github.com/crystal-lang/crystal/issues?utf8=%E2%9C%9...
https://github.com/crystal-lang/crystal/issues/3067#issuecom...
Now the only thing that bothers me is the lack of a REPL. It comes with a web-based playground which is pretty nice, but still not quite the same. Is there any chance Crystal does have a true REPL which I just managed to miss? (If not, it's not a dealbreaker - Go doesn't have a REPL, either[0]. But it still would be nice.)
[0] I know, I know, there are third-party REPLs like gore, but by the time I found out about them, my need for one had diminished a lot.
No idea about ORMs though.
Well, a couple of breaking changes, but...
still amazing!
what is the reasoning for a language like Crystal to support symbols? i am under the impression that is just a relic of the past due to performance reasons but it is not the case anymore.
I don't know enough about the reasons why they are implemented to argue this strongly, but I know that they are immutable and that they are one step closer to the language in the sense that, constructions which you may not use in an unquoted symbol, are also not allowed to be used in a Ruby method name.
That seems like a handy data structure to have around next to a string (and nobody's stopping you from using a string if you wanted a string and not a symbol, ...or are they?)
I find this approach more comfortable and easy to reason about than a separate Symbol class.
Pretty sure you can get progressive versions of this type of behavior (where obj["field"] is equivalent to obj[:field] or obj.field) by using Ruby's HashWithIndifferentAccess and/or OpenStruct classes, but those are both obviously more obscure than something which is a built-in default language feature.
Kinda like mutable Mars ^_^
it was ok with hash rocket styles though
1) Because HN is a social news website, so when someone reads a post about a subject, others are reminded of it, and can post in return. This happens with all popular topics, they come in batches.
2) Because Crystal is getting more popular (e.g. it jumped TIOBE rank for what it's worth), and more people like to read and hence vote such articles.
3) There's a huge conspiracy, with marketing shills and aliens, for an OSS language.
4) More than Go or Rust or React or Ruby back in the day?
Take your pick
Enthusiastic users of new programming languages with small communities, generally want more people to use it as well, so that the community will grow and 1. produce more libraries; 2. produce more tutorials and other resources; 3. have more people for them to talk to about the language.