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

Of course they can, however I was describing the advantages of crystal as opposed to go.

Crystal vs Ruby don't really compete in the same way Crystal and Go do, it's very much a dynamic vs static typing split. Crystal is in general a bit more cleaned up but Ruby's community is much larger.

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.

Thanks for the summary; helpful as I've not checked out Crystal at all yet. Maybe they can steal it as their everywhere blurb.

It's not a Ruby. It doesn't even pretend to be a Ruby. I mean, to be a Ruby, this needs to work:

    a = Object.new
    list_of_modules.each { |mod| a.extend(mod) }

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?

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

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 ;)

Not to those of us that enjoyed using OSes like Oberon.

Go is based on Oberon: a family of simple, safe languages that were used to write OS's. Started with Modula-2 in Lilith project. At one point, the machines ran ETH University. By Oberon, they got a GC but could also do unsafe manipulations for hardware interfaces or performance. Forced you to put it all in modules declared SYSTEM ("unsafe").

The neat thing about the OS was that it and its compiler were simple enough for students to understand that they regularly ported or improved it a few months at a time. It's also one of the most, well-documented OS's in existence.

http://www.projectoberon.com/

That Go is basically a modified Oberon means Go, currently or with some modification, could be used for low-level, systems code up to operating systems. Even with a GC since the Oberon OS's are written in GC language. Most recent, graphical one is A2 Bluebottle if you want to look it up.

No, please research Oberon and read the Project Oberon book.

Go is not on my top 10 languages that I would use, but still I see some value on it being used.

What I meant with that remark was that those languages already had fast toolchains and were more expressive.

So in this regard I also appreciate Crystal, specially since RubyMotion decided to focus on mobile.

Ok, for my purpose I would be far less interest in programing language which has no idioms, no critical feedback, that is basically a mutual admiration society.

Having a hacky workaround isn't the same thing as first class support. Bash on Windows 10 is in my mind similar to resorting to Cygwin. No thanks. I despise Windows, but if you have an overbearing IT dept, that's your only option.

Edit* Just saw where you said "play"

or use docker for windows

>But the problem here is not the suitability of languages themselves, the problem is the huge undertaking required to build a gui library which can compete with Qt, gtk etc.

Well, the whole Cocoa/QT/WinForms scope might be huge, but we don't even have good minimal UI libs -- e.g. with just the few basic widgets: buttons, text fields, labels, radio buttons, checkboxes, kind of what HTML forms can do -- and only very limited functionality (e.g. no fancy text formatting in the labels or whatever).

Tons of programs could be GUI-fied with just the above (sort of what Tk does, but decent looking).

It's a huge undertaking because it's an undefined specification. No one really knows what a cross-platform UI library should look like. How do you follow all of the native app standards automatically? How do you handle updates and distrabution?