
A new year resolution to have Crystal reach the 1.0 milestone in 2017 - spalladino2
https://crystal-lang.org/2016/12/29/crystal-new-year-resolutions-for-2017-1-0.html
======
andyfleming
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.

~~~
lmm
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.

~~~
galfarragem
> it doesn't sound like it brings anything new to the table

A fast and typed Ruby, isn't it enough? ;)

~~~
lmm
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?

~~~
coldtea
Doesn't share the fugly OCaml syntax.

~~~
uryga
Not a great way to convince OCaml fans to use something else.

~~~
oblio
All 3 of them? Jokes aside, they're probably aiming for Ruby fans (or fans of
other dynamic languages).

------
camus2
Well I hope you succeed. Competition is good and in the "Go" space, there's
need to be more competition to demonstrate the technical flaws of Go, or just
give an option for those who want to quit an obnoxious and patronizing
community. You should really be set on the type system and concurrency by now.

~~~
pjmlp
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.

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

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

~~~
nickpsecurity
The language was designed by an expert on Wirth-style languages plus the two
inventors of C. They wanted to create minimal, useful language based on old
techniques with only features they could all agree on. Pike used Oberon-2 back
in the day, knowing its advantages. The C inventors naturally wanted it more
like C. The result is a merger of these. The concurrency stuff was an
exception that came from Limbo language Pike worked on.

The Wirth languages were categorized by a focus on absolute simplicity and
safety with just enough complexity to make building large programs easier.
They constantly added or removed features in various language revisions in a
search of balance. His main metric was compile time: anything that took too
long was kicked out. The result was these languages were easy to learn,
compiled _fast_ (100kloc a sec on good machine), rarely crashed, and ran
reasonable speed. They had GC's but also allowed manual management. They were
objectively better than C language because people could produce correct
programs more quickly with same effort put in due to design.

[http://www.projectoberon.com/](http://www.projectoberon.com/)

Modula-3, designed at DEC, was probably the best of that line given it's like
a safer, simpler C++ with a subset closer to C. Here it is:

[https://en.wikipedia.org/wiki/Modula-3](https://en.wikipedia.org/wiki/Modula-3)

Used in SPIN operating system that let you live-load code into the kernel for
acceleration safely due to type-safe linking on top of memory-safe interfaces.
Quite a few commercial deployments. Didn't take off since C was too popular &
programmers only went with C-like alternatives. Lots of vulnerabilities and
crashes happened.

Another alternative was Delphi, which succeeded for a while. _Way_ more
productive and crash-resilient than using VC++. It fell away due to C/C++
popularity but Free Pascal community still maintains a variant of it. Their
compiler targets a ton of platforms which was common for Pascal.

[http://www.freepascal.org/](http://www.freepascal.org/)

~~~
groovy2shoes
> _The language was designed by an expert on Wirth-style languages plus the
> two inventors of C._

Did Dennis Ritchie have a hand in creating Go? I must have missed that.

While Ken Thompson's earlier B language no doubt had an influence on C, Dennis
Ritchie is widely regarded as the creator of C, which is really rather
different from B, borrowing more heavily from BCPL and Algol-68. As an early
(and heavy) user of C (perhaps the earliest, besides Ritchie himself), I'm
willing to concede that he had enough input on C's design to be called a co-
designer or co-creator. But which other "inventor of C" played a role in the
creation of Go?

I also find it hard to label Rob Pike as an expert in any kind of language
design. An expert in windowing systems and concurrency, perhaps, but language
design? Hell, no. Even his earlier design, Newsqueak, was more of an
experiment in concurrency than in language design—and it notably was a
collaboration with Luca Cardelli, an expert in ML and OOP who also worked on
Modula-3, and whose influence can be seen in Modula-3's several very ML-like
constructs. Articles like this one[1] by Pike only serve to reinforce my
thoughts that he, though a rather smart guy otherwise, is really rather
ignorant about language design and about the role of types in programming in
general.

> _The Wirth languages ... had GC 's but also allowed manual management._

None of Wirth's languages had GC until Oberon, as far as I'm aware. And
spiritual successors by other groups, like Object Pascal and Ada, never really
picked up on GC, either (Ada had GC as an optional part of the standard, but
was removed in the latest standard because it was so rarely provided by
implementations). As far as I can tell, Modula-3 is the only other "Wirth-
style" language to provide GC.

Modula-3 was indeed a great language, and I think it's a real shame that it
didn't get picked up more widely. At a time, it had several really solid
implementations, and the language's definition is very short while still
providing a plethora of useful features for programmers. The silver lining is
that it was, at least, a very influential language, despite its limited
adoption.

Oberon, on the other hand, was a very spartan language that offered little in
terms of features, and it exhibited that Wirth really didn't grok OOP at the
time he designed it (which, if I recall correctly, is something he later
admitted, though I'm having trouble finding a citation at the moment). Some of
Oberon's issues were fixed in later versions of the language, but some of its
issues were also "doubled down" in later versions, as well.

> _Another alternative was Delphi, which succeeded for a while. Way more
> productive and crash-resilient than using VC++._

Delphi was indeed a real alternative for a while, and while you're right that
it was more productive than VC++, that's not saying much. Later versions of
Delphi grew to C++ levels of size, complexity, and hairiness, and that's
reflected in Free Pascal's implementation, as well. It's something that I've
lamented on more than one occasion because I remember how great it was and
feel as though it could still be great with a bit of streamlining.

[1]: [https://commandcenter.blogspot.com/2012/06/less-is-
exponenti...](https://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html)

~~~
pjmlp
> As far as I can tell, Modula-3 is the only other "Wirth-style" language to
> provide GC.

Besides Oberon, there was Oberon-2, Active Oberon, Component Pascal, Zonnon,
Modula-2+, Modula-3.

All of them with roots actually on the Xerox PARC workstation that used
Mesa/Cedar.

~~~
groovy2shoes
Ah, cool. I wasn't thinking of Oberon-2 or Active Oberon as separate languages
when I made that statement. I didn't know Modula-2+ had GC, and was unfamiliar
with Component Pascal or Zonnon. Thanks!

~~~
nickpsecurity
Well, he kept changing them enough to break compatibility & even how you
express concepts at times. Oberon is both a language and a name for a whole
family of languages that represent his people's life-long experimentation with
simple, language design.

Unlike Cardelli, his weren't ultra-practical but they did try with a
commercialized one called Component Pascal. It got significant adoption for a
Wirth language along with IDE. As usual, the BNF grammar is pretty small
despite its expressive power. It kind of came and went far as adoption but
people are still apparently posting to the forum in 2016.

[https://en.wikipedia.org/wiki/Component_Pascal](https://en.wikipedia.org/wiki/Component_Pascal)

[http://blackboxframework.org/index.php?cID=home,en-
us](http://blackboxframework.org/index.php?cID=home,en-us)

~~~
groovy2shoes
Cool, thanks for the pointers :)

------
ksec
Looking forward to 1.0, and cant wait to see an implementation of Ruby in
Crystal, going full circle.

It will still be CRuby, but the "C" is Crystal.

------
alehander42
Windows support is very important for all kinds of apps and libraries

~~~
galfarragem
I didn't 'play' yet with Crystal exactly for that reason: lack of Windows
support.

edit: Windows 7

~~~
RX14
If you just want to play with it, and have windows 10, it runs fine in the
Linux emulator thingy.

~~~
throwaway7645
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"

------
nailer
How does Crystal handle concurrency?

~~~
Svenskunganka
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](https://crystal-
lang.org/docs/guides/concurrency.html)

------
singularity2001
As stated elsewhere Crystal could become a big success if either * they
compile to WebAssembly * they become official 'native ruby' (similar to
cython) * they reduce compliation time to under half a minute (to become a
template for other languages)

~~~
RX14
Compiling to web assembly should actually be quite easy, given llvm's support.
The hard part will be porting the standard library to the environment wasm
provides.

We're already well past the point where we could become "native ruby" and I'm
glad of that. Ruby has quite a few warts, and I'm glad most of them haven't
been copied by crystal.

Compilation times are already well under a minute for the whole of the crystal
compiler itself. It was actually improved quite a bit on Linux in the latest
crystal release.

------
gravypod
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".

~~~
RX14
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.

~~~
gravypod
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.

------
preordained
Wow. I like this. I already like Ruby, so I'm happy to see a language taking
after and improving, adding more. This as opposed to "here's a bunch of new
synataxes and conventions to keep straight!"

------
greyman
Can it be used (in the future) to implement cross-platform desktop apps?

~~~
coldtea
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 will do just fine, provided we get bindings for Cocoa, Windows
UI libs, GTK etc.

~~~
RX14
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.

~~~
coldtea
> _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).

~~~
RX14
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.

~~~
coldtea
Yep, something exactly like that, with good documentation, and bindings for
multiple languages, can go a very long way for lots of apps.

