- Elegance of Ruby

- Statically type checked + global type inference

- No Nulls

- Go-like concurrency

- Easy C ffi

- High performance

I really hope the Crystal succeeds and the language goes mainstream - this release is a huge step forward towards that. Congrats to the Crystal team for reaching the 1.0 milestone!

And macros.

EDIT: also forgot to ask if Crystal has a "killer app" yet? Ruby had Rails, Python had scipy/pandas(several others), Rust had servo etc.

Energize C++ and VA C++ v4.0 showed the way of a Smalltalk like experience for C++, the tools just need to catch up with the past.

VC++ and C++ Builder are on the good path for it.

I don't know how opensolaris kernel builds are, but they're not nearly as simple to wrap your head around as the linux kernel. As a result the level of participation is quite low.

Of course this is more a build issue than it is a language issue in this case.

But yes as you said the compile speed on the linux kernel is partly because it's C and not C++

Also, you are comparing compiled languages to interpreted ones, but the GP talked about differences between compilation time (i.e. compiled languages). And others are also comparing it to e.g. go (compiled but quick to compile).

Does it not? It has 'nil', just like Ruby. Basically the same thing, the docs literally say it's 'similar to null in other languages'.

https://crystal-lang.org/reference/syntax_and_semantics/lite...

So a function might return an Int or a Nil, but if you then try to, say, invoke a function expecting an Int on a Nil, it predictably blows up. An Int cannot be Nil itself.

It's not entirely unlike how algebraic data types with a "None" case work in the ML family of languages.

In most languages without ML-like type systems, null is treated as a "bottom type", as if it were a subclass of all classes. This violates the Liskov substitution principle and results in an unsound type system.

When I was working on Google's indexing system, I was very excited to hear rumors that Ken Thompson and Rob Pike were working on a new language. When it was unveiled, I was pretty disappointed to learn that it repeated Tony Hoare's billion dollar mistake.

[0] https://crystal-lang.org/reference/syntax_and_semantics/type...

I’d really love to see OCaml get true parallelism, green threads, and a decent HTTP server story. Then, I don’t think I’d look anywhere else.

https://caramel.run/

I just don't understand why other people seem to think Ruby isn't enough.

I don't have any use for it, however as language geek it is quite nice to see ecosystems blossom.

Thank you

Once replaced a python script while it was running. Expected time, python: 12 hours. Time to get it running in Crystal: 20 min. Time to finish in Crystal: 12 minutes.

Can you please elaborate on this?

Agreed.

I don’t do enough python to judge them. But, then again, I had even less experience in Crystal back when I worked on this.

I think Elixir is one of crystal's top competitors, but only for servers. Probably you'd never leave Elixir to write a webserver in Crystal. That's just Erlang's specialty. You would leave golang, Ruby, python, PHP, etc. for crystal though, because of the type system, performance, threads, binary, etc..

I've actually started using crystal to write the kinds of scripts people would normally use python for, despite it not being a scripting language.

Take that with a grain of salt, though, since I have a deep-seated hatred of Java stemming from experiences in the early 00s.

    def foo_then_bar(a, b)
      a.foo
      b.bar
    end

Then there's all the ecosystem stuff - Kotlin makes me do extra work to target native, and has little bits of weirdness inherited from Java all around the edges. None of it's deal-breaking, but it is friction.

Note that Kotlin has union types through this compiler plugin: https://github.com/arrow-kt/arrow-meta/issues/570 However it is experimental and shouldn't yet be used in production. Btw sealed classes take care of many uses of union types.

What kind of extra work is needed? I'd say that graal native is transparant for any library that doesn't do weird use of reflection but it's true that many libraries do abuse of reflection.

I did try Kotlin/native hoping it would make it easier to remain in blissful ignorance of the JVM ecosystem, but as of a year or two ago it had significant holes in the standard library (most notably no file abstractions other than thin bindings to libc) and pretty atrocious compile times (something like 10s for hello world, and 30+ for a couple thousand lines of code).

The simplicity and predictability are key with Crystal; everything is an object, and the control structures are limited in number.

Crystal code is very concise and legible. You might say it's crystal clear.

Also, Crystal was first released in 2014, when Kotlin was like 3 years old, and 100% JVM-bound.

Also there is no ABI so you cannot use anything like a native DLL.

Native compilation while possible is clearly second class on the JVM platform. For Crystal it is first class.

Pretty sure this isn't the case with Kotlin Native[1].

[1] https://kotlinlang.org/docs/native-dynamic-libraries.html

This was not the case when Crystal development started.

Try creating a small command line tool for a JVM language. You need to distribute a virtual machine with it. You got the overhead of firing up a VM or JIT just for a short lived session.

Also JVM gobbles memory. You would not want a system made up of lots of tiny command line tools all running on a JVM. That would be a lot of overhead.

See Babashka[0] for an example scripting toolkit written in Clojure.

[0]: https://github.com/babashka/babashka

Sadly, people often confuse "prevailing mindset of the noisiest authorities of some programming language" with "the programming language itself" { not that this is the only confusion or maybe even the worst... :-) }

swift support for windows is non-existent

I was prepared to suggest WSL, but apparently Swift support for Windows is existent[1].

1: https://swift.org/blog/swift-on-windows/

In the words of David Heinemeier Hansson:

> In fact, Ruby, to me, so much of the enjoyment in Ruby is these incredible subtleties, of how many different ways you can structure a conditional. Like, Ruby has, I don't know even the count, there's gotta be 60 different ways you can say `if something`, right? And it is in those 60 different ways that I find half the enjoyment of writing Ruby. Like, it was one of those things where I knew, very early on, that Python was not a language for me because it said, right in the manifesto, there should be preferably one and only one way to do things. Ruby has the exact opposite approach, there should be preferably ten thousand subtle different ways of doing things, that will allow you to write that particular conditional, with just the right emphasis, do you write it in the front, do you put it at the back, is it multi-line, is it single line? Like, there's so much variety and it's in that variety that I find poetry. And it is the poetry of writing Ruby code, of making those subtle distinctions where, at the end, you can like, "Ehh, should we move it around" like, where I just go like, giggles, right? Like, this where like we talked about that big smile, right? So much of that big smile comes from, not just like solving the problem, but solving it in a poetic way.

This doesn’t sound elegant (meaning “pleasingly ingenious and simple”) at all.

It also only seems readable in the most shallow sense - certainly not understandable.

The biggest factor drawing me to experiment a little with Crystal is that it is one of very few languages providing what otherwise has been pretty unique to Go: Lightweight threads+Channels+M:N concurrency (automatically multiplexing the lightweight threads onto a smaller number of OS threads).

Also it does it with a very readable and clean syntax.

Wrote a little about it, with code comparisons, before:

https://rillabs.com/posts/crystal-concurrency-easier-syntax-...

For Crystal 1.0, the number of OS threads is always 1, isn’t it? So although this provides concurrency, it’s less powerful than Go where the same mechanism also provides parallelism.

    (page1, page2) <- concurrently (getURL url1) (getURL url2)

edit: there seem to be some clues about FFI effects in this case of the PG connection library: https://forum.crystal-lang.org/t/issue-with-crashes-hangs-wi...

Take a look at yourself and reflect. If there's dozens or hundreds of interactions that go poorly, notice that YOU are the common denominator.

What you've written here is clearly delusional and makes me worry for your health.

Nobody is attacking you, I'm expressing concern for you. Want to talk privately?

Email in my bio.

It's fantastic. I can think in it. Thank you to all the devs behind this wonderful language!

Migration seems like it might be tough. The ORM (Avram) is missing some things still. (Like I think - tables without primary keys, seems like 'has many through' needs some work, stuff like that.) My API is quite simple.

So a project that compiles to native code but uses Ruby-like syntax is very much "what I would build if I committed to building a language". But I've kept pushing off learning it on the notion that I could always justify learning other things that were "version 1" and "production ready (whatever that means)".

I'm thinking now is the time to jump in and try this out finally.

Any real world users care to explain some domains that either are or are not well suited for this at the moment? Any "gotchas" with writing C-bindings, should I need to? Or is the library ecosystem fairly strong?

Hopefully 1.0 would allow more companies to use it. I've been following the evolution of Crystal for more that 3 years now.

I came from Ruby. Got a JSON/nested structures first program in Crystal working without even reading the docs. Was impressed by Crystal being "a cleaner Ruby" (some of the Ruby quirks removed, some nice things added), compile time NULL checks, type inference and of course it's runtime speed.

Next I've rewritten a small web service from Ruby to Crystal and seen a huge speedup with API requests serving in microseconds. The pre-import CSV data process (took ~ 40s in Ruby) was replaced by just reading CSV on the fly during server boot (~ 2s). Not even tried to optimize anything, just straightforward "make it work".

I would encourage anyone who loves Rube to check Crystal.

I would also suggest not to look at Crystal as just faster (fancier) Ruby. Although on the surface it looks very similar it actually quite different.

It's a great language regardless.

Nim, Crystal and Swift all compile to native code and is designed for that.

Swift is not a GC language in the normal sense since it uses automatic reference counting. That is fully deterministic and with low latency. There is no stop the world to collect garbage like with Java and C#.

Swift is akin to C++ code with smart pointers.

VM vs native is one way, but you can also go by the level of abstraction they provide, which very much puts them in the same category.

Also, this debate comes up every time, but ARC is widely classified as a form of garbage collection, just not a tracing one. It is transparent and automatic to the user. (Well, apart from cycles)

FWIW Chris Lattner, the language creator, put Swift into a non-GC camp.

Widely acknowledged CS books see it differently,

https://gchandbook.org/

LLVM, GIMPLE, TIMI, TenDRA,...

Java and C# also targeet native code,

.NET Native, CoreRT, IL2CPP, Mono AOT, SubstrateVM, GCJ, ExcelsiorJET, OpenJ9, PTC, Aicas,...

Languages and implementations are orthogonal.

Also, you can compile both Java and Kotlin to native images with Graal.

https://www.graalvm.org/examples/java-kotlin-aot/

Naturally it requires understanding the whole stack, how to improve performance in general, picking the right data structures and algorithms as well.

Of course, there are scenarios where that might not be enough, and that is where a C or C++ native library might come into play.

No need to be siloed into a single language.

https://github.com/ffwff/lilith

Swift is the only one on that list that really feels tied to any particular platform.

C# has been extremely portable for years now thanks to .NET Core. Even SQL Server runs on Linux these days, if you really just enjoy spending money.

Java has always had a strong focus on portability, of course.

Nim... I don't know much about. Doesn't it compile to C? I don't think it intentionally has any particular platform affinity, although I wouldn't be surprised if it worked best on Linux.

Java is tied to JVM

Swift is tied to MacOS.

Of course, with the exception of JVM, they are all nominally "cross-platform" in the OS sense of the word. But I haven't seen any substantial Linux/Mac .Net codebases yet, same with Swift on Windows

Edit: I just saw the person that you replied to said the same thing, so I'm not sure why you're pushing that it has a complicated cross-platform story.

No, which doesn't really matter since we're talking about .NET, not .NET Framework. Poor naming choice by Microsoft I guess.

TL;DR rewrite it - there is no migration path!

It left a bad taste, but maybe that was because I wasn't using a distro like Ubuntu.

My experience with C# and .NET Core on ARM Linux is that it comes with a lot of crashes and segfaults. On x86-64 Linux it works well, though.

If your environment is anywhere similar, and you OK with .NET 2.1.18, you can try my package: https://github.com/Const-me/Vrmac/releases/tag/1.0 Sources: https://github.com/Const-me/Vrmac/tree/master/net-core

I figured Crystal was for Ruby developers who want a good static type system.

Crystal is interesting to me because its a systems language, using Ruby syntax and idioms.

I'm a Rails developer by trade but I've been pining to go back into desktop GUI development. Right now the only viable cross-platform options seem to be Swing and Electron. I'm not sure what the desktop story is with Crystal but if it there is a workable solution based on GTK or something similar I'd be very happy!

Categorically, what I've seen of this falls closer to "lintable comments" than it does "actual static types". Static types are a foundational aspect of crystal, it's not like a sticker slapped on as an after thought.

this issue tracks Windows progress, it hasn't been really updated in a while. I've been following Crystal Windows port for over a year, nothing changed yet.

- Ruby itself

- Crystal

- Elixir

I'm massively keen on Zig, too, but it still feels like early days for the language itself. The C-interop is utterly astounding but I don't want to write Zig as syntax-sugar around C libraries.

However, as far as I understand it there is also an argument to be made that multiple dispatch is at least as close to Alan Kay’s original intent for OO (e.g. [1]) than is the currently-ubiquitous class-based version of OO that leads to things like `RequestProcessorFactoryFactory` s with `RequestProcessorFactoryFactory.getRequestProcessorFactory(Class)` methods.

[1] https://medium.com/javascript-scene/the-forgotten-history-of...

That said, my current dayjob is around a Rails codebase, so I might not be representative of the normal systems programming crowd.

The only exception to this is untrusted input, but for that an string is usually always fine.

Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.

I have no problem when a language allows the programmer to explicitly opt for a variable to be an undefined/dynamic type, whether as part of generics or as part of a defensive ingest of untrusted data. I admit this is previously unspecified nuance but in my mind this doesn't break my rule: "this variable is always going to be a dynamic type, never not a dynamic type." This means you know when to interact with it defensively.

The thing I'd like in a hybrid static-dynamic language is type assertion blocks which restore some benefits of static typing while dealing with dynamic typed variables. E.g.:

  declare x as dynamic;
  x = untrusted_source();
  if (x IS_A string) {
    // Inside here, x behaves as a statically typed string.
    // The compiler knows it and checks types appropriately.
    // Passing x elsewhere will send a static typed string.
    function_that_demands_a_string(x);
  }
  else if (x CAN_SAFELY_BECOME_A uint) {
    // True for any non-negative integer regardless of data type.
    // Inside here, x is always a statically typed uint.
    // If it was some other type, it was converted for me.
  }

https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCk...

Note how the language is pretty smart about flow-typing variables as you narrow down their types. `x` here is typed as a tagged union (String | Int32 | Array(Char) | Float64 | UInt32), but by the time the program gets to the final `else` the compiler has figured out that the String and Array cases have already been dealt with (even though we never mentioned Array by name, just asked if the object implements a method that only Array implements), so it lets us call `x.abs`, which only works for numeric types. Of course, `abs` has different implementations for Int32 and Float64, but the signatures are compatible so the compiler lets it fly, resorting to dynamic dispatch at runtime.

The missing part is that there's nothing like a CAN_SAFELY_BECOME_A operator so I had to implement that test myself (as `try_to_u32`) and call it early to get the flow typing to work.

The Wikipedia article for the concept is https://en.wikipedia.org/wiki/Flow-sensitive_typing

With a

  <T>createMapWithStringKey(T arg) -> Map<string, T>

  AType a
  var b = createMapWithStringKey<AType>(a)
  // b is for certain a Map<string, AType>

In any serious statically-typed language, the type system does real heavy lifting. In practice that means that libraries execute code at compile time that, in effect, generate the code you would otherwise need to write (again) yourself.

C, Pascal, and Go are examples of statically typed languages whose type system does only trivial work.

The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C.

Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you would write C, C++, or Rust.

There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation.

In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.

It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript.

You can lookup ahead of time how each function will get compiled with given input types.

You can't analyse functions like this ahead of time:

   function foo(x)
     x + y
   end

It's very explicit in almost anything the language designers wrote from the beginning. Julia has always had it's language semantics designed around a JIT. Keep in mind, julia's JIT is not at all like JS JITs, julia's style is often called 'just ahead of time'.

For the you quote, the only thing causing a problem is the global y. Using global variables is very frowned upon in julia for this reason. However, if you write

    function g(y)
        function f(x)
            x + y
        end
    end

If there's a point in the program where type inference fails to produce concrete types, then the compiler just generates code up to that point and then waits until the types are resolved at runtime, and then using the new runtime type information does static analysis going forward from that point until it either encounters another type instability, or the program is finished.

This is why writing code that isn't concretely inferrable can carry a heavy performance penalty in julia, but it's also why inferrable code can be so fast. The trick is just to keep type dynamism away from performance bottlenecks and you'll be fine.

Next generation climate models are built with Julia. You would not pick a slow language for such a high performance dependent task.

You're confusing dynamic typing and type inference.

As an implementation detail, it has a statically typed intermediate representation that's used for very aggressive and impressive optimization.

But that's an implementation detail, and is not what most people mean when they talk about a language being dynamically or statically typed.

> Julia is dynamically typed, feels like a scripting language, and has good support for interactive use.

Literally on the front page.

Absolutely yes. If you don't know the shape of your data at compile time then you're going to destroy your performance discovering and validating it at runtime.

An Introduction to Crystal - https://news.ycombinator.com/item?id=26217013 - Feb 2021 (39 comments)

Switch from Ruby to Crystal - https://news.ycombinator.com/item?id=25005780 - Nov 2020 (35 comments)

Go vs. Crystal Performance - https://news.ycombinator.com/item?id=23615303 - June 2020 (160 comments)

Ruby vs. Crystal Performance - https://news.ycombinator.com/item?id=23431941 - June 2020 (148 comments)

Crystal 0.34 - https://news.ycombinator.com/item?id=22800139 - April 2020 (31 comments)

Towards Crystal 1.0 - https://news.ycombinator.com/item?id=22725829 - March 2020 (32 comments)

Crystal 0.33 - https://news.ycombinator.com/item?id=22331005 - Feb 2020 (42 comments)

Nim vs. Crystal - https://news.ycombinator.com/item?id=21883882 - Dec 2019 (147 comments)

Lilith: x86-64 OS written in Crystal - https://news.ycombinator.com/item?id=21860713 - Dec 2019 (251 comments)

Crystal 0.31 - https://news.ycombinator.com/item?id=21053366 - Sept 2019 (15 comments)

Parallelism in Crystal - https://news.ycombinator.com/item?id=20897029 - Sept 2019 (41 comments)

Crystal 0.29 - https://news.ycombinator.com/item?id=20110253 - June 2019 (7 comments)

Crystal 0.28.0 Released - https://news.ycombinator.com/item?id=19694006 - April 2019 (30 comments)

Crystal 0.27.0 released - https://news.ycombinator.com/item?id=18370498 - Nov 2018 (36 comments)

Crystal 0.26.0 released - https://news.ycombinator.com/item?id=17753367 - Aug 2018 (40 comments)

Crystal 0.25.1 released - https://news.ycombinator.com/item?id=17424639 - June 2018 (152 comments)

Crystal 0.25 - https://news.ycombinator.com/item?id=17319689 - June 2018 (68 comments)

Why Crystal Is My Next Language - https://news.ycombinator.com/item?id=17280969 - June 2018 (192 comments)

The Crystal Programming Language - https://news.ycombinator.com/item?id=16842442 - April 2018 (73 comments)

Why I'm excited about Crystal in 2018 - https://news.ycombinator.com/item?id=16221053 - Jan 2018 (7 comments)

Crystal 0.24.1 released - https://news.ycombinator.com/item?id=16021965 - Dec 2017 (22 comments)

Overview of the Crystal language - https://news.ycombinator.com/item?id=15945262 - Dec 2017 (90 comments)

Crystal in Production: Diploid - https://news.ycombinator.com/item?id=15574714 - Oct 2017 (120 comments)

Journey from Node to Crystal - https://news.ycombinator.com/item?id=15240984 - Sept 2017 (6 comments)

Crystal Lang vs. Node.js vs. Go Benchmarks - https://news.ycombinator.com/item?id=14368050 - May 2017 (10 comments)

From Ruby to Crystal: A Quick Look - https://news.ycombinator.com/item?id=13949353 - March 2017 (43 comments)

Building a Command-Line Application with Crystal - https://news.ycombinator.com/item?id=13945591 - March 2017 (33 comments)

Porting Ruby to Crystal - https://news.ycombinator.com/item?id=13837109 - March 2017 (34 comments)

A new year resolution to have Crystal reach the 1.0 milestone in 2017 - https://news.ycombinator.com/item?id=13281333 - Dec 2016 (78 comments)

The Crystal Programming Language - https://news.ycombinator.com/item?id=13209575 - Dec 2016 (193 comments)

Crystal: Fast as C, Slick as Ruby - https://news.ycombinator.com/item?id=12223395 - Aug 2016 (429 comments)

Kemal: Fast, simple web framework for Crystal - https://news.ycombinator.com/item?id=11143811 - Feb 2016 (16 comments)

The future of the Crystal language - https://news.ycombinator.com/item?id=10803635 - Dec 2015 (36 comments)

Crystal-Lang – Beauty of Ruby, Faster Than Go - https://news.ycombinator.com/item?id=10014178 - Aug 2015 (31 comments)

Amethyst – Rails inspired web-framework for Crystal language - https://news.ycombinator.com/item?id=9716508 - June 2015 (8 comments)

Crystal Language - https://news.ycombinator.com/item?id=9669166 - June 2015 (171 comments)

Crystal: the programming language - https://news.ycombinator.com/item?id=8658358 - Nov 2014 (51 comments)

Meet Crystal language in its birthday. It is compiled and has ruby like syntax - https://news.ycombinator.com/item?id=6342609 - Sept 2013 (84 comments)

Side note: Anybody know of tools that auto-compile lists like this? I'm sure it's not perfect, but these sorts of reviews really add value to the current conversation.

when you browse via the web (unsure which apps support this feature), clicking the title - in this case, Crystal 1.0 – does what you expect and takes you to the article. in tinier font next to the title - in this case, (crystal-lang.org) - is a link that shows all the previous HN submissions for that website, which happens to be pretty similar to what dang posted.

this wont work for platforms like medium or reuters, but is a big head start for a single-issue website like this.

Edit: I still want to make this a community/collaborative effort. As HN's archive grows it gets richer, so this gets increasingly worth doing over time. The recent changes are a small step in that direction.

Edit 2: maybe someday it could be integrated somehow with the criminally neglected Usenet archive and go all the way back.

It would help if the front page were to say.

We embarked on a huge project (search engine) using Crystal a year ago after also considering Rust. We have been very satisfied with the exceptional performance, language capabilities and the community.

To me, dealing with JSON is always a challenge in truly static type language. Crystal solved it very nicely https://crystal-lang.org/api/1.0.0/JSON/Serializable.html

Perhaps you mean something else, but this is from the book Programming Crystal:

> Returning Values

> A method returns the value of its last expression, so there’s no need to explicitly return that or declare its type. However, if you want to document or directly control that return type, you can explicitly specify the type, as in this example:

> methods_and_procs/methods.cr

    def typed_method : Array(Int32)
      (42..47).to_a.select { |n| n % 4 == 0 }
    end

    typed_method # => [44]

I would like Crystal compiler to take into account such definitions and speed up somehow. I know I am talking without experience, I just feel that coming from Ruby to Rust, declaring types on function definitions is not that much of a hassle.

    # version 1:
    def add(x : Int, y : Int)
      x + y
    end

    # version 2:
    def add(x : Number, y : Number)
      x + y
    end

    # version 3:
    def add(x : Number, y : String)
      x.to_s + y # convert a number to a string with to_s method
    end

    # version 4:
    def add(x, y)
      x + y
    end

    # new methods:
    # version 5:
    def add(x : Number, y : Bool)
      y ? x : 0
    end

    # version 6:
    def add(x : String, y : String)
      if x.to_i? && y.to_i?
        add x.to_i, y.to_i # calls version 1
      else
        x + y
      end
    end

    add(2, 3)                # => 5
    add(1.0, 3.14)           # => 4.14
    add("Hello ", "Crystal") # => "Hello Crystal"
    add(42, " times")        # => "42 times"
    add 5, true              # => 5
    add 13, false            # => 0
    add("12", "13")          # => 25

> I just feel that coming from Ruby to Rust, declaring types on function definitions is not that much of a hassle.

I'm another one who doesn't understand why declaring types is seen as a hassle, but then I went from C# to Ruby so perhaps I was already used to it. Happy to bring a little back!

They allow specifically that though?

https://crystal-lang.org/reference/syntax_and_semantics/type...

How would providing types speed up anything? As far as I can see, the compiler still has to infer types in order to know whether the type you provided is correct.

I think that would be good no only to reduce compile times but also to make code more readable

I find the API nice and easy specially for those familiar with CSP or go. Performance should improve once it gets the necessary love for it to be released to be on by default.

Windows requires a lot of boring work, especially considering most of the core devs use Linux / MacOS. Once they make it as priority it should be doable within a few months of work.

Note that all of Crystal's competitors give first-class support to Windows: go, zig, nim, ruby, etc.

I say this as a suggestion, rather than a critique. Actually, as a hopeful suggestion. :-)

There's sense in just releasing for nix platforms if you have them ready to go, especially when you expect your initial target market to be deploying on nix systems.

https://framework.embarklabs.io/news/2019/11/18/nim-vs-cryst...

A better Nim impl would use `parsejson` directly at which point its speed can approach the fastest of any impl. [1] Also, it is implementions (like stdlib) that are assessed not the speed of the language. There are like 10 json parsers beyond the stdlib. No idea about Crystal ecosystem diversity...

EDIT: Also, I just ran the base64 encode/decode and with `crystal build --release b64.cr` vs. `nim c --gc:markAndSweep -d:danger --cc:gcc --passC:-flto b64`, the Nim ran twice as fast not half as fast.

Anyway, people should not draw conclusions like "Crystal is faster than Nim" from things like this.

[1] https://forum.nim-lang.org/t/6920

Plugging this great howto video, which I didn't make https://youtu.be/DxFP-Wjqtsc

My only complaints: * compilation speed * type inference is sometimes not intuitive (class members * too OOP oriented (no constness, no UFCS/pipeline, no general monad operator,...etc)

Now I'm going to spend time writing something non-trivial in Crystal. Very excited!

Can anyone who writes Crystal today dispel or confirm that information? I imagine the inferred typing makes building a fast compiler really tough.

Compiling isn't fast. By the language design it won't ever be possible to be in the same ballpark as golang. It's common for us that our 5k lines app, take >1m to build in release mode as we added more and more dependencies for integrations with different nosql databases (elastic, rocksdb etc).

Using LLVM as backend is great for getting top notch performance, but to generate multiple IR methods for each type signature consumes a lot of time, especially when doing optimisation in release mode builds. I guess it's a similar problem that cranelift is trying to fix in Rust.

Open classes makes it hard to cache compilation results from dependencies / libraries.

Yes, for this reason I think crystal could be one of the best languages for microservices or faas.

There is no solution really. If you want a language to feel like it is dynamically typed but actually has types, something gotta give, and in this case it is compilation times. And it gets quite high fast.

You might know a lot more than me about the subject, so feel free to correct me, but I think it used to be truly global inference - as in you were expected to write the whole program with no annotations. But now you're required to annotate instance and class variable types, because compile times were becoming intractable.

In contrast, local inference considers a predefined context, such as the current module or class, and is much faster, easier to cache, etc.

I've long wanted to get into Smalltalk and this looks like a very nice, modern way of doing so.

There are two pretty big web frameworks in the Crystal world right now, one is Kemal which strives to be the Sinatra or Flask of the Crystal world (lightweight, supporting plugins), and the other is Crystal which is trying to be the Ruby on Rails or Django of the Crystal world (full-featured, opinionated).

https://athenaframework.org is pretty unique. It's one of the more flexible frameworks IMO. It was inspired by Symfony and Spring, so takes a bit of a different approach as most other frameworks come from a more Ruby background.

Edit: Ok, looks like there is a "why" section on github!

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

So what is the performance like?

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

- 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

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?