Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new year resolution to have Crystal reach the 1.0 milestone in 2017

crystal-lang.org

Post reply on HN
Print view View original

31–40 of 79 posts

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#31

Post by chrisseaton »

RX14 wrote: post #18
andyfleming wrote: post #12

I think Crystal is a very practical language to work in for web. It doesn't have the polish of Go (yet), but it feels more approachable to me. Rust has its place with low-level systems work, but Crystal gives you something that is reasonable to write and still compiles to a binary. In turn, it performs well and is easy to distribute, deploy, and containerize as well.

I think crystal has several advantages over go, first of which is the type inferrence. In crystal, you never specify types in method bodies. You don't have to specify types in method arguments either. Type unions are really expressive, and handing nil is as easy as `raise/return unless nillable_variable`. Second of which is `yield`, ruby's extremely powerful way of passing code to functions. In crystal, functions whi…

Ruby implementations with a JIT can also inline blocks, of course.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#32

Post by pimeys »

galfarragem wrote: post #17
lmm wrote: post #15

Earlier quoted context omitted.

If I'm already using, say, OCaml, why would I want to switch to Crystal? (assuming that multicore takes the same amount of time to arrive in each). Whenever I've read about Crystal it sounds like a broadly sensible language, but it doesn't sound like it brings anything new to the table - in which case I'll favour the more mature language with the bigger library/tool ecosystem.

> it doesn't sound like it brings anything new to the table A fast and typed Ruby, isn't it enough? ;)

Is this the same with Crystal, as shown in Ruby:

  irb(main):001:0> "".methods.size
  => 170

  irb(main):002:0> 0.methods.size
  => 133
If it is, I mean, I don't see it being so fast.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#33

Post by gravypod »

RX14 wrote: post #29
gravypod wrote: post #27

This was very good but... " reach a point where breaking changes to the core of the language are down to a minimum " I'm very afraid of the word minimum in this context. This is why "no one was ever fired for picking Java".

I think that's a mistake in the article, we will follow semver after 1.0.0, and we definitely don't want a 2.0.0 less than two years after 1.0.0. I'm sure crystal will provide the same stability guarantees as go and rust.

My main concerns are development time and tooling. Crystal looks great and offers some great features that no other native-compiled languages really offer at this time (which is amazing) but I am the kind of person that needs first-class IDE support to take a look. I think crystal would be the perfect platform for some great software development.

Aside from tooling I need a guarantee that my code, if following all of the best practices, should be compilable from now till the foreseeable future.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#34

Post by yxhuvud »

lmm wrote: post #15
andyfleming wrote: post #12

I think Crystal is a very practical language to work in for web. It doesn't have the polish of Go (yet), but it feels more approachable to me. Rust has its place with low-level systems work, but Crystal gives you something that is reasonable to write and still compiles to a binary. In turn, it performs well and is easy to distribute, deploy, and containerize as well.

If I'm already using, say, OCaml, why would I want to switch to Crystal? (assuming that multicore takes the same amount of time to arrive in each). Whenever I've read about Crystal it sounds like a broadly sensible language, but it doesn't sound like it brings anything new to the table - in which case I'll favour the more mature language with the bigger library/tool ecosystem.

Ruby itself never brought anything new to the table, just a really well polished collection of ideas taken from other languages. Crystal is mostly the same, marrying Ruby stdlib with go channels and compilation to native code.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#35

Post by yxhuvud »

pimeys wrote: post #32
galfarragem wrote: post #17

Earlier quoted context omitted.

> it doesn't sound like it brings anything new to the table A fast and typed Ruby, isn't it enough? ;)

Is this the same with Crystal, as shown in Ruby: irb(main):001:0> "".methods.size => 170 irb(main):002:0> 0.methods.size => 133 If it is, I mean, I don't see it being so fast.

What on earth has the size of the list of methods to do with performance?

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#36

Post by gravypod »

chrisseaton wrote: post #31
RX14 wrote: post #18

Earlier quoted context omitted.

I think crystal has several advantages over go, first of which is the type inferrence. In crystal, you never specify types in method bodies. You don't have to specify types in method arguments either. Type unions are really expressive, and handing nil is as easy as `raise/return unless nillable_variable`. Second of which is `yield`, ruby's extremely powerful way of passing code to functions. In crystal, functions whi…

Ruby implementations with a JIT can also inline blocks, of course.

That still comes at a cost. The macro/lazyeval approch is usually seen as "zero cost" because the JIT engine usually only spends time inlining if it's a hot block.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#37

Post by _uhtu »

pimeys wrote: post #32
galfarragem wrote: post #17

Earlier quoted context omitted.

> it doesn't sound like it brings anything new to the table A fast and typed Ruby, isn't it enough? ;)

Is this the same with Crystal, as shown in Ruby: irb(main):001:0> "".methods.size => 170 irb(main):002:0> 0.methods.size => 133 If it is, I mean, I don't see it being so fast.

The number of methods in the standard library really doesn't impact performance in a compiled language since you can tree shake the stuff that isn't used. And even if you don't tree shake having lots of methods isn't really a noticable performance loss in compile to binary languages since you don't need to spin up a VM

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#38

Post by FreezerburnV »

the_duke wrote: post #9
pjmlp wrote: post #4

Earlier quoted context omitted.

There is no need to demonstrate anything. Go is a good enough replacement for C, for user space applications. With some improvements, even for more lower level tasks. As for the flaws, anyone that had the pleasure to work with the Algol and Wirth family of languages is well aware of them.

Go is really more of a Java than a C replacement.

This sentiment is actually very interesting to me. I had (/have?) the same kind of sentiment toward Go, but when I spent time playing with it recently I realized just how close to C it actually is. Enough so that when someone says it's a C replacement, I can actually see where they're coming from/somewhat agree with them. And the reason for that is that Go actually seems to follow a lot of C conventions pretty darn closely, and not provide as high level of an interface as Java does. You're much more likely to work in raw "arrays" (aka: slices) in Go than you are in Java, it doesn't have generics, "classes" are structs that are defined very similarly to structs in C, error codes as return values, etc. The main differences that are adding to C as far as I'm currently aware are interfaces, the ability to add a "method" to a type (which is effectively the same as calling a function with a type as the first argument, except in the case of interfaces), and the garbage collector. All of which, to me, feel like a kind of evolution on C. A different path instead of C++ in a way. While people would argue that having a GC ruins what C is good at, it can also be viewed as a version of C that's much more memory safe, while still allowing you to dip into very low level if you need to.

...there's probably some other stuff I could say, and probably more coherently, but it's early (for me) and I kind of just wanted to get that thought out there. I hope it's at least a bit thought-provoking, or something. If not, well, my apologies for rambling at you ;)

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#39

Post by geodel »

FreezerburnV wrote: post #38
the_duke wrote: post #9

Earlier quoted context omitted.

Go is really more of a Java than a C replacement.

This sentiment is actually very interesting to me. I had (/have?) the same kind of sentiment toward Go, but when I spent time playing with it recently I realized just how close to C it actually is. Enough so that when someone says it's a C replacement, I can actually see where they're coming from/somewhat agree with them. And the reason for that is that Go actually seems to follow a lot of C conventions pretty darn c…

Maybe it makes sense. It is replacement of Java because convenient GC, decent runtime and networking/http/ssl/xml/json libs comes standard. This is where is Java is mostly used as backend server side stuff.

It is replacement of C as in low memory usage, decent level of control over memory layout, no overengineered abstractions, no classes, no generics, no exceptions, fewer concepts to grasp etc. It does not need VMs and generates executables to directly run on machines.

Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017

#40

Post by uryga »

coldtea wrote: post #22
lmm wrote: post #19

Earlier quoted context omitted.

OCaml (well, actually Scala in my case, but I can understand why people wouldn't want to have to use the JVM) is already that, as far as I can see. What is it that Crystal offers that OCaml doesn't?

Doesn't share the fugly OCaml syntax.

Not a great way to convince OCaml fans to use something else.
Post reply on HN