This is not a new year’s resolution(crystal-lang.org)
crystal-lang.org
This is not a new year’s resolution
https://crystal-lang.org/2017/12/19/this-is-not-a-new-years-resolution.html
42 comments
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.
as someone who loves Go, you've piqued my interest. tell us more?
Nicer syntax (Subjective).
Suuuuper fast! (Not that it matters but likely faster than Go[0]).
Single binary builds/deployments (Just like Go).
[0] http://blog.seraum.com/crystal-lang-vs-nodejs-vs-golang-vs-h...
Suuuuper fast! (Not that it matters but likely faster than Go[0]).
Single binary builds/deployments (Just like Go).
[0] http://blog.seraum.com/crystal-lang-vs-nodejs-vs-golang-vs-h...
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.
It’s single threaded (for now), but all IO is async under the hood and will implicitly yield and allow a different fiber/green thread to run.
I might be one of the few people who would prefer Crystal remain single threaded and that effort go elsewhere in the language.
I might be one of the few people who would prefer Crystal remain single threaded and that effort go elsewhere in the language.
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 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.
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.
Crystal production users: https://github.com/crystal-lang/crystal/wiki/Used-in-product...
Please somebody write me a Ruby to Go transpiler :P
Wishful thinking:
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.
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.
https://www.elixir-lang.com
https://www.elixir-lang.com
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).
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).
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.
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.
You might find Pony interesting:
https://www.ponylang.org/
At the same time you have to deal with waking up in the morning and telling yourself you're going to go do some pony today, which seems a tad off.
Im going to do some C++
Im going to do some Java
Im going to do some Pony
Im going to do some C++
Im going to do some Java
Im going to do some Pony
You are making this comment on an article about a language called Crystal.
Worked out for Python.
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
I don't talk like that. I would say write some.
There are many languages that do this. In addition to those already mentioned, there is also Nim. https://nim-lang.org
What support does Nim have for message passing? It looks to me like it has async/await and a thread pool-based version of something like pmap.
Is there such a thing as vapor languages? I feel like crystal and elixir are vapor languages.
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.
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.
I've always taken "vaporware" to refer to abandoned software.
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."
https://en.wikipedia.org/wiki/Vaporware
Ha! It's even made it into Merriam-Webster's!
https://www.merriam-webster.com/dictionary/vaporware
> "a computer-related product that has been widely advertised but has not and may never become available"
> "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."
https://en.wikipedia.org/wiki/Vaporware
Ha! It's even made it into Merriam-Webster's!
https://www.merriam-webster.com/dictionary/vaporware
> "a computer-related product that has been widely advertised but has not and may never become available"
Crystal, I don't know, but how is Elixir vapor?
I honestly don't know a ton about it, but I see it mentioned in the same cool kid crowd of "rubyists" a lot.
Then I guess you just have a weird concept of what 'vapor' is in this context.
I believe you were thinking about so-called "hipster languages".
I believe you were thinking about so-called "hipster languages".
The language works. It has a full toolchain. It has Erlang interoperability.
If the entire Elixir project and team disappeared tomorrow, I could still write the same software and deploy it to the same (decades-old) BEAM VM.
If the entire Elixir project and team disappeared tomorrow, I could still write the same software and deploy it to the same (decades-old) BEAM VM.
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 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.
I'd be curious to see actual usage numbers as they've changed over time.