6 ms·

All of those points are already met and in a better way by mature languages like e.g Kotlin. Really the only argument would be the "Ruby elegance" (or familiari

All of those points are already met and in a better way by mature languages like e.g Kotlin. Really the only argument would be the "Ruby elegance" (or familiarity?) which I don't know. What make ruby/crystal more "elegant" (I would prefer the term readable) than the competition?

nine_k 6y ago
Kotlin mostly requires JVM, Crystal does not. Kotlin is heavily oriented towards Java familiarity and interoperability, Crystal is heavily oriented towards Ruby familiarity, and C interoperability. Also, Crystal was first released in 2014, when Kotlin was like 3 years old, and 100% JVM-bound.
- The_rationalist 6y ago
  Kotlin mostly requires JVM, Crystal does not. With Kotlin native, Kotlin js and most importantly Graal native this is plain wrong.
  - nine_k 6y ago
    This is correct today. This was not the case when Crystal development started.
    - The_rationalist 6y ago
      Translation: Crystal had a value proposition but now it's gone, before the product launch.
      - iomcr 6y ago
        Reality: Kotlin's value proposition is android development.
        The_rationalist 6y ago
        It's a misconception, Kotlin is suitable everywhere that Java is suitable, and even more.
  - socialdemocrat 6y ago
    That is like a hack. You are basically dumping a JIT image to file. That means all sorts of caveats apply such as be real careful about how you use reflection. Also there is no ABI so you cannot use anything like a native DLL. Native compilation while possible is clearly second class on the JVM platform. For Crystal it is first class.
    - yxhuvud 6y ago
      Crystal is also not great for dlls or .so files as the event loop and gc probably wouldn't work well in that scenario.
      - filleduchaos 6y ago
        I have used Crystal to make DLLs and it worked plenty fine.
      - iomcr 6y ago
        Sounds like a fair compromise when the alternatives includes at least one of the following tradeoffs: harder, less safe, and/or slower.
    - heavyset_go 6y ago
      > Also there is no ABI so you cannot use anything like a native DLL. Pretty sure this isn't the case with Kotlin Native[1]. [1] https://kotlinlang.org/docs/native-dynamic-libraries.html https://kotlinlang.org/docs/native-dynamic-libraries.html
  - abhijat 6y ago
    Is kotlin/native a first class option today for server side programming? Last I looked at it, which was fairly recently, that did not seem to be the case.
    - The_rationalist 6y ago
      While Kotlin native is likely more mature than crystal I would say that graal native is much better as it allow you to reuse Java libraries and therefore spring native.
  - iomcr 6y ago
    That doesn't stop 99% of the mind share and language design from being "Java with lipstick".
bovermyer 6y ago
Well, speaking purely from personal experience, Crystal is much more enjoyable to write and read than Java derivatives. Take that with a grain of salt, though, since I have a deep-seated hatred of Java stemming from experiences in the early 00s.
- The_rationalist 6y ago
  Interesting, could you characterize some of what make it more enjoyable?
  - bovermyer 6y ago
    Sure. The simplicity and predictability are key with Crystal; everything is an object, and the control structures are limited in number. Crystal code is very concise and legible. You might say it's crystal clear.
  - ezrast 6y ago
    Kotlin is indeed very Crystal-like, and I enjoy both languages, but I really miss union types in Kotlin, as well as deeper type inference. For example, in Crystal you can write def foo_then_bar(a, b) a.foo b.bar end and it will just work for any two types that implement `foo` and `bar`, respectively. This isn't something I do often - I like the clarity that type-annotated parameters give - but it's a really nice feature to have available in the 2% of cases where I want it. Then there's all the ecosystem stuff - Kotlin makes me do extra work to target native, and has little bits of weirdness inherited from Java all around the edges. None of it's deal-breaking, but it is friction.
    - The_rationalist 6y ago
      Thanks for the example, that's interesting. Note that Kotlin has union types through this compiler plugin: https://github.com/arrow-kt/arrow-meta/issues/570 https://github.com/arrow-kt/arrow-meta/issues/570 However it is experimental and shouldn't yet be used in production. Btw sealed classes take care of many uses of union types. What kind of extra work is needed? I'd say that graal native is transparant for any library that doesn't do weird use of reflection but it's true that many libraries do abuse of reflection.
socialdemocrat 6y ago
Why Kotlin when you got Swift is an equally valid point. People like choice and for a lot of us, running on the JVM is a non starter. Try creating a small command line tool for a JVM language. You need to distribute a virtual machine with it. You got the overhead of firing up a VM or JIT just for a short lived session. Also JVM gobbles memory. You would not want a system made up of lots of tiny command line tools all running on a JVM. That would be a lot of overhead.
- himujjal 6y ago
  kotlin/native doesnt require jvm swift support for windows is non-existent
  - eyelidlessness 6y ago
    > swift support for windows is non-existent I was prepared to suggest WSL, but apparently Swift support for Windows is existent[1]. 1: https://swift.org/blog/swift-on-windows/ https://swift.org/blog/swift-on-windows/
- dm3 6y ago
  This information was true a few years ago. Now, with modular JVM you do not ship a VM with the program. JVM by itself is lean and starts up pretty fast. You can also compile to native with GraalVM - this is a viable option if you want to write lots of tiny command line tools. See Babashka[0] for an example scripting toolkit written in Clojure. [0]: https://github.com/babashka/babashka https://github.com/babashka/babashka
- pjmlp 6y ago
  Since 2000 AOT compiling into native code has been available to Java developers, no different from using something like Go. That many didn't want to buy those compilers and settled with the free beer that could get hold of is another matter.
  - cb321 6y ago
    Just to corroborate - with gcc's gcj Java folk could get compilation to an ELF binary for free as well. I was profiling such in 2004. This was unpopular/unmaintained enough that eventually gcc discontinued it. Sadly, people often confuse "prevailing mindset of the noisiest authorities of some programming language" with "the programming language itself" { not that this is the only confusion or maybe even the worst... :-) }
ibraheemdev 6y ago
> What make ruby/crystal more "elegant" (I would prefer the term readable) than the competition? In the words of David Heinemeier Hansson: > In fact, Ruby, to me, so much of the enjoyment in Ruby is these incredible subtleties, of how many different ways you can structure a conditional. Like, Ruby has, I don't know even the count, there's gotta be 60 different ways you can say `if something`, right? And it is in those 60 different ways that I find half the enjoyment of writing Ruby. Like, it was one of those things where I knew, very early on, that Python was not a language for me because it said, right in the manifesto, there should be preferably one and only one way to do things. Ruby has the exact opposite approach, there should be preferably ten thousand subtle different ways of doing things, that will allow you to write that particular conditional, with just the right emphasis, do you write it in the front, do you put it at the back, is it multi-line, is it single line? Like, there's so much variety and it's in that variety that I find poetry. And it is the poetry of writing Ruby code, of making those subtle distinctions where, at the end, you can like, "Ehh, should we move it around" like, where I just go like, giggles, right? Like, this where like we talked about that big smile, right? So much of that big smile comes from, not just like solving the problem, but solving it in a poetic way.
- pansa2 6y ago
  > there should be preferably ten thousand subtle different ways of doing things This doesn’t sound elegant (meaning “pleasingly ingenious and simple”) at all. It also only seems readable in the most shallow sense - certainly not understandable.

nine_k 6y ago

Kotlin mostly requires JVM, Crystal does not. Kotlin is heavily oriented towards Java familiarity and interoperability, Crystal is heavily oriented towards Ruby familiarity, and C interoperability. Also, Crystal was first released in 2014, when Kotlin was like 3 years old, and 100% JVM-bound.

The_rationalist 6y ago
Kotlin mostly requires JVM, Crystal does not. With Kotlin native, Kotlin js and most importantly Graal native this is plain wrong.
- nine_k 6y ago
  This is correct today. This was not the case when Crystal development started.
  - The_rationalist 6y ago
    Translation: Crystal had a value proposition but now it's gone, before the product launch.
    - iomcr 6y ago
      Reality: Kotlin's value proposition is android development.
      - The_rationalist 6y ago
        It's a misconception, Kotlin is suitable everywhere that Java is suitable, and even more.
- socialdemocrat 6y ago
  That is like a hack. You are basically dumping a JIT image to file. That means all sorts of caveats apply such as be real careful about how you use reflection. Also there is no ABI so you cannot use anything like a native DLL. Native compilation while possible is clearly second class on the JVM platform. For Crystal it is first class.
  - yxhuvud 6y ago
    Crystal is also not great for dlls or .so files as the event loop and gc probably wouldn't work well in that scenario.
    - filleduchaos 6y ago
      I have used Crystal to make DLLs and it worked plenty fine.
    - iomcr 6y ago
      Sounds like a fair compromise when the alternatives includes at least one of the following tradeoffs: harder, less safe, and/or slower.
  - heavyset_go 6y ago
    > Also there is no ABI so you cannot use anything like a native DLL. Pretty sure this isn't the case with Kotlin Native[1]. [1] https://kotlinlang.org/docs/native-dynamic-libraries.html https://kotlinlang.org/docs/native-dynamic-libraries.html
- abhijat 6y ago
  Is kotlin/native a first class option today for server side programming? Last I looked at it, which was fairly recently, that did not seem to be the case.
  - The_rationalist 6y ago
    While Kotlin native is likely more mature than crystal I would say that graal native is much better as it allow you to reuse Java libraries and therefore spring native.
- iomcr 6y ago
  That doesn't stop 99% of the mind share and language design from being "Java with lipstick".

bovermyer 6y ago

Well, speaking purely from personal experience, Crystal is much more enjoyable to write and read than Java derivatives. Take that with a grain of salt, though, since I have a deep-seated hatred of Java stemming from experiences in the early 00s.

The_rationalist 6y ago
Interesting, could you characterize some of what make it more enjoyable?
- bovermyer 6y ago
  Sure. The simplicity and predictability are key with Crystal; everything is an object, and the control structures are limited in number. Crystal code is very concise and legible. You might say it's crystal clear.
- ezrast 6y ago
  Kotlin is indeed very Crystal-like, and I enjoy both languages, but I really miss union types in Kotlin, as well as deeper type inference. For example, in Crystal you can write def foo_then_bar(a, b) a.foo b.bar end and it will just work for any two types that implement `foo` and `bar`, respectively. This isn't something I do often - I like the clarity that type-annotated parameters give - but it's a really nice feature to have available in the 2% of cases where I want it. Then there's all the ecosystem stuff - Kotlin makes me do extra work to target native, and has little bits of weirdness inherited from Java all around the edges. None of it's deal-breaking, but it is friction.
  - The_rationalist 6y ago
    Thanks for the example, that's interesting. Note that Kotlin has union types through this compiler plugin: https://github.com/arrow-kt/arrow-meta/issues/570 https://github.com/arrow-kt/arrow-meta/issues/570 However it is experimental and shouldn't yet be used in production. Btw sealed classes take care of many uses of union types. What kind of extra work is needed? I'd say that graal native is transparant for any library that doesn't do weird use of reflection but it's true that many libraries do abuse of reflection.

socialdemocrat 6y ago

Why Kotlin when you got Swift is an equally valid point. People like choice and for a lot of us, running on the JVM is a non starter. Try creating a small command line tool for a JVM language. You need to distribute a virtual machine with it. You got the overhead of firing up a VM or JIT just for a short lived session. Also JVM gobbles memory. You would not want a system made up of lots of tiny command line tools all running on a JVM. That would be a lot of overhead.

himujjal 6y ago
kotlin/native doesnt require jvm swift support for windows is non-existent
- eyelidlessness 6y ago
  > swift support for windows is non-existent I was prepared to suggest WSL, but apparently Swift support for Windows is existent[1]. 1: https://swift.org/blog/swift-on-windows/ https://swift.org/blog/swift-on-windows/
dm3 6y ago
This information was true a few years ago. Now, with modular JVM you do not ship a VM with the program. JVM by itself is lean and starts up pretty fast. You can also compile to native with GraalVM - this is a viable option if you want to write lots of tiny command line tools. See Babashka[0] for an example scripting toolkit written in Clojure. [0]: https://github.com/babashka/babashka https://github.com/babashka/babashka
pjmlp 6y ago
Since 2000 AOT compiling into native code has been available to Java developers, no different from using something like Go. That many didn't want to buy those compilers and settled with the free beer that could get hold of is another matter.
- cb321 6y ago
  Just to corroborate - with gcc's gcj Java folk could get compilation to an ELF binary for free as well. I was profiling such in 2004. This was unpopular/unmaintained enough that eventually gcc discontinued it. Sadly, people often confuse "prevailing mindset of the noisiest authorities of some programming language" with "the programming language itself" { not that this is the only confusion or maybe even the worst... :-) }

ibraheemdev 6y ago

> What make ruby/crystal more "elegant" (I would prefer the term readable) than the competition? In the words of David Heinemeier Hansson: > In fact, Ruby, to me, so much of the enjoyment in Ruby is these incredible subtleties, of how many different ways you can structure a conditional. Like, Ruby has, I don't know even the count, there's gotta be 60 different ways you can say `if something`, right? And it is in those 60 different ways that I find half the enjoyment of writing Ruby. Like, it was one of those things where I knew, very early on, that Python was not a language for me because it said, right in the manifesto, there should be preferably one and only one way to do things. Ruby has the exact opposite approach, there should be preferably ten thousand subtle different ways of doing things, that will allow you to write that particular conditional, with just the right emphasis, do you write it in the front, do you put it at the back, is it multi-line, is it single line? Like, there's so much variety and it's in that variety that I find poetry. And it is the poetry of writing Ruby code, of making those subtle distinctions where, at the end, you can like, "Ehh, should we move it around" like, where I just go like, giggles, right? Like, this where like we talked about that big smile, right? So much of that big smile comes from, not just like solving the problem, but solving it in a poetic way.

pansa2 6y ago
> there should be preferably ten thousand subtle different ways of doing things This doesn’t sound elegant (meaning “pleasingly ingenious and simple”) at all. It also only seems readable in the most shallow sense - certainly not understandable.