Hacker News new | ask | show | jobs
by wsgeek 2919 days ago
I think some of the comments here are unfair to Crystal and the careful thought (and lots of work!) that has been put into it. Projects like this should not be so easily dismissed as "also-rans".

I read through the Crystal language docs (meaning just the syntax etc) and as a seasoned C++ and Python developer who is _constantly_ looking for something with better performance (than Python) yet much cleaner (than C++), I think Crystal has a lot going for it so far.

Any "great" language should be able to take a thought in a developer's head and easily allow 1) the concise expression of that thought, and 2) efficient evaluation of that thought. I mean, those things we probably would all agree on.

It saddens me to say this, but C++ is falling over as a result of it's own weight. It's become a language for experts. Perhaps more than any popular language, it can take a simple idea in a developer's head and turn it into pages of code. It's actually quite embarrassing. I won't go into that further; judge for yourself (and sorry if that comment offends anyone -- I love C++ and use it every day). But you just can't beat the speed... Well-crafted C++ _should_ exceed the speed of even C (Why? Because templates...). As an aside, it's disingenuous to put Java in the same speed category as C/C++... The "fast" Java programs out there are basically C with Java wrappers (ducks thrown tomatoes). And just like C++, Java is very noisy (but for different reasons).

Python as we all know sort of takes the opposite approach, with dynamic typing a design-as-you-go mentality. And boy what a success it has been, with a flourishing package ecosystem. There's lots of good things to say about Python, but it's f*cking slow as hell (Cython is a hack, Numba shows promise, but PyPy isn't much faster... I was excited about Pyston but don't know where that went). It's not the fault of Python that it's slow -- it's the price of such a wonderfully dynamic language.

So enter things like Crystal. And trust me -- it's definitely early days with this language. But I like the fact that the designers really seem to care about the things that (to most of us I think) matter.... Taking an idea in our brain and putting it (simply) down in code, and then having that code run quickly. Yay!

In this day and age where we are swamped with hype from all of these new languages, let's give praise where it's warranted -- to the people are out there that are trying to refine decades worth of thought and finally "get it right".

My hat is off to those people out there that are forging ahead with these types of projects. Don't mind the criticism -- keep it up and great job.

1 comments

I'm similar to you. An every-day / almost every day C++ user. I've been using Clojure for a personal project and I really enjoy the much-reduced overhead imposed by the language. Unfortunately it runs on the JVM so that's not something I'm super stoked about. But this language seems interesting. The interoperability with C libs gives it a head start. The syntax seems much nicer than Rust. Too bad about the parallelism but frankly you can get by with a single core for a lot of things, I'm sure it's on the roadmap anyhow.
Lisps are all very, very cool -- you basically get to build your own world. And the macros -- so powerful. But the parens! Not the number of them, as that is about the same as other langs, but the placement of them:

Sample factorial function:

(define fac (lambda (n) (if (= n 0) 1 (* n (fac (- n 1)))))) ; <<--- look at those parens!

And with Clojure, you don't have proper tail recursion, so you'll have to add some Clojure-only thing in there to prevent the above code from blowing up for large numbers.

There's really no getting around it -- Lisp, for many people, is just hard to parse. Consider:

def fac(n): n < 2 ? n : n * fac(n - 1)

Yay! No noise. But I agree, there are some cool things about Clojure.

How do we know that

  def fac(n): n < 2 ? n : n * fac(n - 1)
is the whole function? Maybe someone snipped

  def fac(n): n < 2 ? n : n * fac(n - 1)
              + more stuff
One of the parentheses you have there come from having an unambiguous, complete, top-level form. We know nothing has been cut off; any characters after the last closing parenthesis are not part of this form. Curly-brace languages agree with this and do the same.

One level of parentheses comes from using a dialect which uses a variable definition and lambda to define a function, instead of having function-defining syntax like defun.

   n < 2 ? n : n * fac(n - 1)
requires knowledge of the ternary operator and its precedence. Someone who has no clue about the ternary operator will not make heads or tails out of this. The Lisp is impossible to mis-parse, even by a programmer who doesn't know Lisp. You might not know how if works, but you can't miss the fact that (if ...) is a unit, which is enclosing four things: if, (= n 0), 1, and (* n ...).

You've loaded the readability dice by writing it on one line. To help with the readability issues in both languages, we can use multiple lines and indentation:

   def fac(n):
     n < 2
     ? n
     : n * fac(n - 1)

   (defun fac (n)
     (if (< n 2)
       n
       (* n (fac (- n 1)))))
yes, lisp is a fossil of a time before precedence was invented.

what I dream of is a Lisp with an additional mechanism to define precedence of functions/operators. And infix operators. Almost like Haskell.