As a long-time Rubyist, I took a serious look at Crystal for the first time and discovered a lot of the best batteries of Ruby included in Crystal. So pleased to find an RSpec-like DSL for testing, for example, and Crystal's Rails-like framework, Amber, generates scaffolds with Bootstrap built in. It's almost cheating how much learning and takeaways the Crystal core team can borrow from Ruby! I'm really liking it so far.
While Ruby allows you to choose and provide way too many choices, many guns for you to shoot your foot into. Crystal decided some are not good and actually enforce those best practices.
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:
Crystal will eventually have go-style parallelism as well as go-style concurrency. It's a hard thing to implement, and we don't have the resources of google (in fact we have very little resources at all) so it's taking time. Until 3 weeks ago, nobody at all was working full-time on crystal, it was entirely a spare-time project, so progress is slow, i'm incredibly proud of what we've managed to achieve so far and looking forward to more in the future.
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.
Which, I'd like to say, is extremely easy to use in production, and actually quite easy to marry with the built-in kqueue/inotify/etc. event loop async/await!
This shouldn’t be downvoted. I love Erlang, but it’s the latency that’s really fast (that is, low), not the throughput[0].
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.
And that's why he's being downvoted... Generically claiming that a language is "slow af" will mean different things to different people. Hence the interpretations. Hence the downvotes.
Erlang absolutely does have this 'in common', and it makes this faculty known every time you start up the Erlang REPL.
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).
Well you’re either confused or being purposefully ingenuous. The original poster, samuell, said nothing about languages which compile to native executables, he said he’s looking for “languages with light-weight threads automatically mapped (multiplexed) to physical threads, like in Go”. Hence the suggestion of Erlang, which is valid. Further, making a generic statement that Erlang is “slow af” adds nothing to the discussion.
The benchmark game's "results" peg some toy programs in Erlang an order of magnitude faster than Python 3.
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.
Faster than Python 3 means little and the discussion is mainly about languages which compile to native code and have certain features.
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++.
I get where you are coming from (although, in the case mentioned above at least, an order of magnitude faster places it within 150% of the speed of Java). I think you're only scratching the surface of Erlang here though. I believe "networked services", "millions of connections" and "hot-code reloading" are a meme that hides the Erlang's real utility.
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).
"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).
I've been using (and contributing to) Crystal for some small projects over the last few months. Writing C bindings within it is amazingly stress-free[1].
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.
I really like Crystal, and while it hasn't reached a 1.0 yet, it is still great and used in production. I think the main selling point of Crystal is performance + nice syntax. The docs are great and will help anyone curious to learn Crystal along the way. Crystal's biggest problem is that it doesn't have the support of a company or a large base of users so the core team isn't funded as much as they'd like. All in all, I think it is a great language!
Manas is a tiny company without the resources to spare a single developer. The money to pay for the single developer who is working full-time on crystal comes entirely from bountysource and other donations: https://salt.bountysource.com/teams/crystal-lang
Great to see some steps made towards supporting Windows! (i.e. "non-POSIX systems")
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.
Crystal is still fairly early in it's development. We have plenty of time available to make the breaking changes required to make windows a true first class citizen. I'm putting a lot of thought into how to do this.
I really, really like Crystal — the Ruby syntax is great, and better type safety is always a plus.
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?
I am on openSUSE, and I just realized I can install Crystal from the RPM repository (well, duh! I should have thought of that a lot sooner...), so I now have no excuse left to play around with it a little. I also happen to be on vacation right now, so I have plenty of time on my hands. =D
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.
Take a peek at Amber and its native ORM Granite. Amber is a bit more rails-like than Sinatra-like, but it’s super lightweight and has been a pleasure to build with so far. I’m using it for several projects.
only thing I don't like about Ruby is the "symbols". if there was a new language that copied everything about Ruby minus the symbols, I'd be all over it.
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?)
In Lua, symbols are just strings, all strings are immutable via internment, and the symbol rules constrain the parser, not the runtime. So obj.field is shorthand for obj["field"], you can have obj["="] if you want, it means obj.= but that is of course a syntax error.
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.
It's one of several decisions that make Lua's type system easy to reason about. Another one is that environments themselves are simply tables, the global is _G, and environments can be set and retrieved on functions.
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?
Because Ruby is a really nice language to write code in (minus some quirks) and everyone would love a language with similar programmer experience, but much faster.
> why do all these comments read like advertisements
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.
Because advertising Crystal means a chance for Ruby enthusiasts and some beginners to try a statically-typed language without having too much learning curve.
