71–80 of 180 posts
Just curious, why Crystal? It looks just like Ruby. What problem(s) are you addressing with Crystal?
It's a compiled language.
Earlier quoted context omitted.
They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.
The advantage of the monadic approach is that it's easy to abstract over, because it's just an ordinary type in the language. So e.g. in scala I can call the same "sequence" method on a List[Option[Int]] as I do on a List[Future[Int]] or a List[ErrorMessage \/ Int]]. Unions seem like more of a language-level feature, so I'm not sure you could abstract over them in the same way.
Nonetheless, I am thrilled that we are seeing more and more languages that don't have implicit nullability on any type.
Earlier quoted context omitted.
They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.
The advantage of the monadic approach is that it's easy to abstract over, because it's just an ordinary type in the language. So e.g. in scala I can call the same "sequence" method on a List[Option[Int]] as I do on a List[Future[Int]] or a List[ErrorMessage \/ Int]]. Unions seem like more of a language-level feature, so I'm not sure you could abstract over them in the same way.
I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Specifically, you need lightweight processes and no-shared-memroy architecture. While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up. Erlang got this right and build a lot of infrastructure around…
No you don't. I mean, that's one way to do it, but its not the only way and is often not an option if you want real performance. CUDA (a language specifically designed for SIMT parallelism) supports shared memory for good reasons; the threads are also not lightweight in that way (though they rely on memory and branch coherence).
Earlier quoted context omitted.
He probably meant the results of compilation: superfast binaries ;)
In that case, what he missed was AOT optimization :) Many Lisps have had compilation to binaries. But having a binary doesn't imply being faster than an interpreted language. Theoretically, a JIT optimization can end up with faster code than an AOT optimizer can produce, thanks to runtime profiling. In fact, I'd be interested in seeing benchmarks, which Crystal is probably not ready to share, but may have conducted:…
not sure about D, but Go is known to have very little in the way of optimisation, that's a big factor in its speedy compilation.
Earlier quoted context omitted.
It seems to have a fair slew of type-system features, so how does it manage to compile so fast, compared to for instance the Rust compiler, which doesn't do global type inference?
It's because we spent some time thinking the algorithms and optimizing them, and whenever we make changes to the compiler we make sure the times remain pretty much the same (it's hard because the compiler's size grows so the times inevitably grow, at least for the compiler). And from time to time we profile and optimize further, we like speed. I believe with time Rust can achieve a similar performance, maybe even bet…
Does this mean that if a library doesn't have complete test coverage compile-time errors could be discovered only by clients?
Just curious, why Crystal? It looks just like Ruby. What problem(s) are you addressing with Crystal?
We like the way Ruby lets you quickly prototype things, but its performance isn't very good (it's just good) and it also lacks static type checks (for example "undefined method '...' for Nil" is a very common runtime error). So, we are trying to create a language with all the nice aspects of Ruby but with static checks and better performance. Of course that comes at a price: no dynamic aspects (no eval, no instance_e…
For example, JRuby+Truffle runs Crystal's own sample programs around twice as fast as Crystal does, without static compilation, and while still supporting all the metaprogramming and dynamic features of Ruby such as monkey patching, send, method_missing, set_trace_func, ObjectSpace etc.
https://gist.github.com/chrisseaton/91c7cbf8f6f4f6ea44bb
However Crystal does start faster, and I'm sure it has lower overhead.
Earlier quoted context omitted.
http://elixir-lang.org may be even faster than go. web apps respond in microseconds.
Elixer and Erlang are not faster than go. The ability to respond in microseconds is a latency issue, not a raw speed issue. Erlang and Elixer can do that because of the way the core systems are architected but the underlying VM and language constructs are quite a bit slower than anything that Go has to offer. For maximum throughput out of a given chunk of hardware you'd want Go. Erlang / Elixer and the associated VM…
I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…
Earlier quoted context omitted.
I'm curious how possible it is in practice to write large software that relies exclusively on global type inference. Does the compiler itself go without ever explicitly specifying a type?
GHC does global type inference, and has very sophisticated types.