Crystal 0.24.1 released(github.com)
github.com
Crystal 0.24.1 released
https://github.com/crystal-lang/crystal/releases/tag/v0.24.1
24 comments
Can you add an entry for pony to https://learnxinyminutes.com/ ?
Make a PR here: https://github.com/adambard/learnxinyminutes-docs
Make a PR here: https://github.com/adambard/learnxinyminutes-docs
To be fair, the Nim community agrees with your assessment. Quite a lot of development is going into the nimx library for that reason!
>However, "Faster Ruby" or "Faster Python" is, in practice, solved by faster hardware as well.
That ship has sailed years ago.
That ship has sailed years ago.
Disclaimer: I'm a core Nim dev.
To be honest I am unsure what Pony provides that Nim doesn't. Perhaps I just haven't looked closely enough at it.
One thing I do know is that from my years of using Nim I never had any trouble with parallelism. There are no green threads, but there is a solid thread pool implementation[1] and a mechanism that ensures memory isn't shared between threads without a lock or a channel (GC safety)[2].
Maybe you could give me a TL;DR of what Pony does better? :)
1 - https://nim-lang.org/docs/threadpool.html
2 - https://nim-lang.org/docs/manual.html#threads-gc-safety
To be honest I am unsure what Pony provides that Nim doesn't. Perhaps I just haven't looked closely enough at it.
One thing I do know is that from my years of using Nim I never had any trouble with parallelism. There are no green threads, but there is a solid thread pool implementation[1] and a mechanism that ensures memory isn't shared between threads without a lock or a channel (GC safety)[2].
Maybe you could give me a TL;DR of what Pony does better? :)
1 - https://nim-lang.org/docs/threadpool.html
2 - https://nim-lang.org/docs/manual.html#threads-gc-safety
Pony has an Actor as a language-level concept, which significantly reduces the amount of “thinking about mechanism” that a programmer needs to do to build safe, highly-concurrent programs.
Quick read: https://tutorial.ponylang.org/types/actors.html
I think one could implement a similar system in Nim using the primitives that you posted, plus some kind of channel, but:
1. Such a system is not included in the standard library (?)
2. Even if a package containing such a system outside the stdlib were available, it would not receive the same application and usage by the Nim community, as Pony actors will in the Pony community
3. So, Pony is better suited to foster a community for highly concurrent programming
Quick read: https://tutorial.ponylang.org/types/actors.html
I think one could implement a similar system in Nim using the primitives that you posted, plus some kind of channel, but:
1. Such a system is not included in the standard library (?)
2. Even if a package containing such a system outside the stdlib were available, it would not receive the same application and usage by the Nim community, as Pony actors will in the Pony community
3. So, Pony is better suited to foster a community for highly concurrent programming
Does an actor system need to be part of the language? In the Scala world, there's the akka library to provide actors (but of course you could use a totally different actor system instead). Alternatively in Elixir, actors (Processes) with their send/receive functionality is built into the language and each module can essentially be an actor.
I guess the trade off is that if it's a part of the language, you get it standard and built in as a language construct. But if it's in an external library, you can use different actor systems and benchmark them accordingly.
I guess the trade off is that if it's a part of the language, you get it standard and built in as a language construct. But if it's in an external library, you can use different actor systems and benchmark them accordingly.
one benefit is that you can effectively embed the concept directly into the type system, allowing for ergonomic expression of actor model code. i'm not sure to what extent pony does this, though i believe it's capability typing was designed with actors in mind.
maybe the green thread thing doesn't bother you because you are a seasoned system dev?
Parallelism and a UI framework are such a big undertakings that it simply takes a lot of time to get them working.
Hell we are stuck with Electron because there simply is not a proper alternative.
For parallelism Crystal plans to do it the Go way.
> For desktop/mobile apps, they need a UI framework
I don't know about the mobile story, but there are Qt bindings for crystal.
As for parallelism, it is not done but it is in the works, so it is not ignored, it just is hard enough that it isn't possible to just wish for it and it appears. The concurrency story is already pretty strong though.
I don't know about the mobile story, but there are Qt bindings for crystal.
As for parallelism, it is not done but it is in the works, so it is not ignored, it just is hard enough that it isn't possible to just wish for it and it appears. The concurrency story is already pretty strong though.
Yes, I believe it is folly to try to build a "general purpose" language these days. It's just too much work to clear the bar for adoption (i.e. what do you offer that C/C++/Java/C#/Python/Ruby/JS don't). A language could be great in many ways, but as you say, you have to be able to solve problems you can't solve otherwise with it.
It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.
A friendly reminder I posted over on reddit :)
http://colinm.org/language_checklist.html
It seems like most newer languages that see some adoption have a solid niche, like Erlang/Elixir, Julia, or Elm.
A friendly reminder I posted over on reddit :)
http://colinm.org/language_checklist.html
That is hilarious
I've played around with pony - ergonomic is not the way I would describe it. The heavy use of actors in the core lib is a powerful abstraction for concurrent systems, but it's a pain, structurally, compared to non-actor systems.
>>For desktop/mobile apps, they need a UI framework
Then use FreePascal/Lazarus for your client. Don't know about the state of the mobile libs, but Delphi/FP perfected desktop UI development a long time ago. Decouple backend into whatever you want so you have an asset that is UI agnostic.
Then use FreePascal/Lazarus for your client. Don't know about the state of the mobile libs, but Delphi/FP perfected desktop UI development a long time ago. Decouple backend into whatever you want so you have an asset that is UI agnostic.
I think Crystal follows the Ruby path too tightly. Ruby also never found its place in the UI framework world. The popularity of web apps during the rise of current rich interfaces and the boom of SaaS consumer products didn't give Ruby and reason for its contributor base to expand successfully. Times have changed again and we are back to being interested in standalone apps.
I really like Crystal and hope some of the UI focused community from Rust will bleed over.
Crystal is a programming language. https://crystal-lang.org/ Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs.
Crystal stacks up pretty nicely in our crowd-sourced feature table, for statically compiled languages:
https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
... providing light-weight threads, and possibly going to support M:N coroutine:thread multiplexing(?). Let's hope.
https://docs.google.com/spreadsheets/d/1BAiJR026ih1U8HoRw__n...
... providing light-weight threads, and possibly going to support M:N coroutine:thread multiplexing(?). Let's hope.
I feel like Crystal has been alpha for 4 years.
It takes a long time to build a language. Rust was in development for many years, and it has had the benefit of backing by Mozilla.
That may be, but it's really quite stable for pre-1.0. I have Crystal apps running in production without problems and great success. I'd say, in some scenarios, Crystal is more stable in alpha than some post-alpha language releases I've worked with in the past.
Great to see progress, and exciting news on the possibility of swapping the GC. Thank you to all maintainers and contributors, here's to a big multi-threaded 2018! :)
But I fear that the problem they solve isn't big enough. For desktop/mobile apps, they need a UI framework so I suppose they're targeted at web or network/system programming mostly. However, "Faster Ruby" or "Faster Python" is, in practice, solved by faster hardware as well. At the same time, for web apps to truly scale you need more than just a constant factor increase in speed - you need to handle parallelism better. This is what Go and Erlang/Elixir do with green threads, or Rust with its borrow checker.
This is why I've been surprised that a well thought out and polished initiative like Crystal doesn't do anything in this area, and makes me fear that its popularity might not last. Nim was all over HN a few years ago and now not seen that much anymore - Crystal is obviously different from Nim but they tackle many of the same problems in similar enough ways.
I fear/hope that, because of this, languages like Pony[0] will stick around longer - it seems to combine the best ideas from Crystal, Erlang and Rust in an ergonomic way.
[0] https://playground.ponylang.org/