Hacker News Reader

Comment by yxhuvud | Hacker News Reader

Try Crystal and you get the joy of Ruby enumerables together with a static type system.

Crystal is nice, but my love affair with Swift is going strong. Not exactly Ruby syntax but pretty similar in terms of simplicity. I am a Rubyist who feels right at home with Swift. But for the new year, I definitely want to give Crystal a fair shot!

Kotlin is my new love. Best collections library of any language I've used, great type system, coroutines are amazing, and all of it integrates perfectly with 25 years of rock-solid Java libraries.

While the collections library may be better than others, it has a great many warts, many of which aren't discoverable until you've used it a long time. Some of these warts are a result of JVM interop requirements. It's not just the collections library, while the language is great and better than others, there are mounds of bugs and poor design decisions.

What do you use Coroutines in a static language like Java, for ?

Everywhere I used to use CompleteableFutures, except without ending up with completely unmaintainable code.

https://github.com/Kotlin/kotlinx.coroutines/blob/master/cor...

Very interesting, thanks!

Interesting. What’s your opinions on Crystal right now as a substitute for Ruby? Is there a good stack like Rails for Crystal?

Take a look at Lucky framework!

https://luckyframework.org

Quite immature, especially when it comes to community and library support.

But dang it's nice to do stuff in it.

Crystal is definitely not production ready, I mean a language without thread support...

Yeah, it’s only now MT schedulers is work in progress to bring multithread fibers to Crystal

https://github.com/crystal-lang/crystal/pull/7214

Thread support in interpreted languages isn’t that parallel to begin with.

JRuby threads are fully parallel and in production use today. CRuby's GIL is an implementation choice rather a property of dynamic/interpreted languages.

I’m wondering.. what is the effect of letting the JVM handle synchronization then ? Wouldn’t they still need to synchronize within JvM ?

Is it really a "choice" if the alternative is really hard to achieve in practice? It's like calling python's GIL a choice... with numerous projects trying to get rid of it in various ways and never really succeeding to do it while keeping the single threaded performance and the extensions API.

It is a choice to keep backwards compatibility with the C extensions API.

The GIL would be quite easy to replace otherwise.

> It is a choice to keep backwards compatibility with the C extensions API.

IIUC for CRuby it's mostly about how to keep the VM simple. Koichi Sasada is working on an ownership based model like Erlang has, which sidesteps a bunch of theses issues.

Reply on news.ycombinator.com