Earlier quoted context omitted.
Doesn't share the fugly OCaml syntax.
Not a great way to convince OCaml fans to use something else.
All 3 of them? Jokes aside, they're probably aiming for Ruby fans (or fans of other dynamic languages).
A new year resolution to have Crystal reach the 1.0 milestone in 2017
41–50 of 79 posts
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#42Earlier quoted context omitted.
Not any more than several other languages, because as usual, the show stopper is the lack of decent cross-platform desktop GUI libraries. There's QT, which is huge and unwieldily and not so good looking on OS X, GTK+ which is a mess on both Windows and OS X, wxWidgets (based on other libs), and a few fringe, and incomplete libs. For one-platform apps, though, or a single backend for multiple platform UI frontends, it…
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. Crystal at the very least has good support for binding C so maybe this will be the language which finally produces a modern gui toolkit, but with the move towards web apps its becoming increasingly unlikely.
>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).
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#43How does Crystal handle concurrency?
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#44How does Crystal handle concurrency?
Like Golang, using fibers & communicating via channels. I/O is also asynchronous similar to Node (using an event loop).
You can read more here: https://crystal-lang.org/docs/guides/concurrency.html
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#45Earlier 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.
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.
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#46Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#47Earlier quoted context omitted.
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. Crystal at the very least has good support for binding C so maybe this will be the language which finally produces a modern gui toolkit, but with the move towards web apps its becoming increasingly unlikely.
> 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…
Libui, which was on hn a while ago, looks like the basic minimal cross-platform gui library to me. And that's already got bindings to crystal.. I think most developers are searching for something more.
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#48Earlier 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.
Not to those of us that enjoyed using OSes like Oberon.
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#49Earlier 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 a good enough replacement for C, for user space applications. Are you sure you are not describing Rust?
No, please research Oberon and read the Project Oberon book.
Re: A new year resolution to have Crystal reach the 1.0 milestone in 2017
#50Earlier 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.
> As for the flaws, anyone that had the pleasure to work with the Algol and Wirth family of languages is well aware of them. I just don't want to have to deal with a bunch of second guessing judgmental jerks anymore. Nobody in the Crystal community is going to go after me for something "not idiomatic" I published.
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.