Hacker News Reader

Comment by Trasmatta | Hacker News Reader

They "why" is basically having a language with the aesthetics and usability of Ruby, but fully statically typed with global type inference, and impressive performance.

The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.

View on HN

See, when you add "performance" to those properties it piques my interest. I'd love me a high performance language that is sanely typed, allows for metaprogramming, feels like an interpreted language while doing so etc. However the main page says absolutely nothing about performance. I even don't care about compile times.

So what is the performance like?

You can find some benchmarks here: https://github.com/kostya/benchmarks

With the caveat of course being that benchmarks don't always reflect real world performance.

Also Crystal based web frameworks tested here (key: Cry) same caveat as above. https://www.techempower.com/benchmarks/

It's at least on par with Go, for solving similar problems, micro benchmarks, etc.

The "downside" you forgot to mention a lot of important things:

- tooling is abyssmal ( IDE etc ... )

- no mutli threading

- no real support, I'm not even sure if there is one paid guy anymnore on the project

- it's still immature

- they break the API all the time

> - tooling is abyssmal ( IDE etc ... )

As others have mentioned this is a side effect of how young it is.

> - no real support, I'm not even sure if there is one paid guy anymnore on the project

If paid support is all that counts then most languages would fall into that.

> - it's still immature

Tautological. Nothing can become mature without first being immature.

> - they break the API all the time

Isn't that what a 1.x is for? A stable major version?

>If paid support is all that counts then most languages would fall into that.

Can you name another recent programming language that wasn't developed in-house at a major company. Go , Dart , and Rust all started out with paid teams of programmers working on them.

Not sure if Crystal will be able to progress at a rate fast enough to keep people interested. Likewise, you'd have to be insane to try and pitch this to your project manager. I consider myself to be a risk taker, but even for my own side projects I stick to older better known programming languages.

it feels like we keep trying to solve the same problems over and over again instead of utilizing solutions which already exist

I feel like it would be easier and cheaper to negotiate a support contract with Manas (Crystal) than with Google (Go, Dart) if your company wants paid support.

Do zig, python, elisp, Clojure, Haskell (mostly a research project), etc fit the bill?

Out of those Pythons the only one that's widely used in production, and it's been around for a long time. Python itself is an extremely simple language, which I think can work as one person passion project.

Modern python has grown significantly from its first release in the 90s though. I don't think that can happen today, we all want too much out of our programming languages.

> Python itself is an extremely simple language

Unfortunately that’s not true at all - Python is far from simple. Sure, it’s no C++, but it’s very complex compared to languages like C, Go, Lua, even JavaScript.

All these companies, and more, are using Clojure in production: https://clojure.org/community/companies.

Python also has active sponsorship. Guido and the mypy folks were employed at Dropbox for the express purpose of working on Python last I checked, and even then my biggest grievance with Python is that the big hairy problems (performance, package management) still never get solved.

I can't speak to the others on the list but it seems odd to say Clojure isn't being used widely in production. Clojure's been powering big businesses for years now and Nubank, which primarily uses Clojure, is valued at $24bn: https://www.pymnts.com/news/investment-tracker/2021/brazilia....

Languages / ecosystems being immature is not a tautology. Every one is at some point immature, but it's not a self-defining attribute of a language, nor is it necessarily true for a given language. It's entirely fair to call out "this language does not have a significant, stable, healthy ecosystem behind it (yet?)" because dealing with that stands a pretty good chance of taking up a large amount of time. Some uses / users are fine with that, others are not.

Crystal is sponsored by https://manas.tech/ and the company actively provides paid support to a number of commercial clients. Breaking changes have been really low lately. I have a couple of shards that work on 1.0 as well as they did on 0.27 or so (that's 10 major dev releases ago). And with 1.0 there is a guarantee to not have breaking changes until 2.0. I don't agree to the other points too, but that's more subjective.

- tooling: there is a VS Code plugin for Crystal (https://marketplace.visualstudio.com/items?itemName=crystal-...). There is also syntax highlighting for most popular editors, if you prefer a text-editor to a fully-loaded IDE.

- no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts.

- no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions.

- still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube).

- API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)

It is a relatively new language, all of the points you listed are expected. The last one should be taken care of now that they released 1.0.

Multithreading has been present behind a compiler flag for a solid 7 minor versions (since 2019). The feature is maturing for a release in the 1.0 -> 2.0 range.

Besides funding (and maybe multithreading), I'd say that every new language will suffer from these limitations. They are difficult to avoid.

Those downsides aren't intrinsic to the design of the language, and are likely to be present for any new, immature language.

The compile times are largely a side effect of the underlying language design, and it isn't likely to get significantly better, which is why I mentioned it.

> The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.

I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .

Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed.

I believe you can speed up your compile times a bit by being explicit with annotations (which I often prefer anyway), but there's still a lot of overhead for the global type inference.

> Maybe the most powerful of any fully statically typed language?

Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.

Those functional languages don't have function overloading or named arguments. The type inference in Crystal works very differently. The type of a method can only be computed from explicit calls to it. In those functional languages the type can be computed independent of a call because it's trivial to do so if a function name always refers to a single entity.

> Those functional languages don't have function overloading or named arguments.

Scala has both, F# too (though function overloading is possible, I think it's not idiomatic), OCaml has named arguments, Haskell has overloading.

I should have qualified that statement with OO languages, not functional. Also see asterite's reply, he would know much better than me, as I believe he's one of the core Crystal developers.

thank you! this summary is enough for me to try it!

Reply on news.ycombinator.com