Neat, I will check this out. Although, if I am honest I really wish there was "Crystal for python".
Nim (http://nim-lang.org/) is really as close as you're going to find.
Crystal: Fast as C, Slick as Ruby
431–439 of 439 posts
Re: Crystal: Fast as C, Slick as Ruby
#432First thing I look for whenever I run across another "C competitor" is to look which language it is implemented in. Usually that's C, or C++, but this time, it does look like Crystal is implemented in Crystal, which is, to me, a very good indication that this is a "real" system language. I believe Rust is also implemented in Rust and Go, after a few years of being implemented in C has now a compiler written in Go.
> ... which is, to me, a very good indication that this is a "real" system language. Could you expound upon that point a bit? What's the difference, in your mind?
The rationale is, that once you have a programming language that is implemented in itself (usually that means that the compiler/interpreter is written in that language), then it means that your language has tackled and can deal with many issues that "system languages" deal with. Mainly dealing with the OS in a lower level, dealing with CPU/RAM, etc.
This is a large problem space that you can glean over by using C as a layer of interaction between your language and the underlying machine, but it makes your language a: not truly a "system language" and b: it also ties you to C philosophy, API/ABI, calling conventions and so on.
Re: Crystal: Fast as C, Slick as Ruby
#433Earlier quoted context omitted.
What flags?
Try using Wunderspecs, Woverspecs, and Wspecdiffs. You'll find that dialyzer catches things that are more the shape of what you'd accept a more typical type-checking system to catch.
Oh great, thanks! Unfortunate that I missed it. Still no luck on the parametric polymorphism though... :(
Re: Crystal: Fast as C, Slick as Ruby
#434Earlier quoted context omitted.
Try using Wunderspecs, Woverspecs, and Wspecdiffs. You'll find that dialyzer catches things that are more the shape of what you'd accept a more typical type-checking system to catch.
Oh great, thanks! Unfortunate that I missed it. Still no luck on the parametric polymorphism though... :(
That's what Type Variables are explicitly for. They present the necessary semantics for bounded parametric polymorphism. In fact that's really the only reason they exist at all. The rest of the sub-type system works without them, but parametric polymorphism wouldn't work without them.
I don't know if the Erlang/Dialyzer docs cover that specifically, but I know the originial paper on Dialyzer and Dialyzer type specs does.
Re: Crystal: Fast as C, Slick as Ruby
#435Earlier quoted context omitted.
Oh great, thanks! Unfortunate that I missed it. Still no luck on the parametric polymorphism though... :(
That's what Type Variables are explicitly for. They present the necessary semantics for bounded parametric polymorphism. In fact that's really the only reason they exist at all. The rest of the sub-type system works without them, but parametric polymorphism wouldn't work without them. I don't know if the Erlang/Dialyzer docs cover that specifically, but I know the originial paper on Dialyzer and Dialyzer type specs d…
I know you can do stuff like:
@type pair(t, u) :: {t, u}
@type result(t, e) :: {:ok, t} | {:error, e}
@spec map(Enumerable.t, (element -> any)) :: Enumerable.t
@spec map[e1: Enumerable, e2: Enumerable](e1.t, (e1.element -> e2.element)) :: e2.t
@spec foo[a: Eq & Ord](a.t, a.t) :: bool
Re: Crystal: Fast as C, Slick as Ruby
#436Earlier quoted context omitted.
I wonder, could we just tell each JVM instance that it may use all of the memory on the system, and then let the OS kill the first VM that allocates more than the system has to offer? Would this get us the same semantics as those of a native application? Or does the JVM preallocate all of the memory that it is allowed to use?
The JVM allocates at start a portion, takes what it needs whenever it needs until the max, but never releases memory back to the OS. So in a given moment a 6GB vm is a 5GB process but internally is using just 3GB.
The standard JVMs do give memory back. The standard settings are not very friendly to do so but it does work.
Re: Crystal: Fast as C, Slick as Ruby
#437Earlier quoted context omitted.
4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12
damn... I actually like that a lot!
I like it for distinguishing homonym operators, but not for the precedence stuff they seem to have there. I'd like something like this though:
let a = 10;
a / 5
output> 2
let b = pwd();
b/temp
output> Directory
b / 2
error> b:Directory does not implement method "divide(:number)"
a/temp
error> a:int does not implement method "get(:string)"Re: Crystal: Fast as C, Slick as Ruby
#438Earlier quoted context omitted.
> How am I supposed to learn the language's semantics from a lexer? Not what I wanted to achieve, but the lexer contains some frequently used methods and is fairly simple and straight-forward, but if you want to learn the semantics why not just go to their docs? https://crystal-lang.org/docs/syntax_and_semantics/index.htm... > Consider this use case: I spawn five fibers. Can I send the same mutable object to all five…
> but if you want to learn the semantics why not just go to their docs? https://crystal-lang.org/docs/syntax_and_semantics/index.htm... Yep, fair enough. I'm somewhat worried about how abstract classes work: https://crystal-lang.org/docs/syntax_and_semantics/virtual_a... Apparently, Crystal can infer the methods of an abstract class from the methods of its subclasses. In the Animal/Dog/Cat example, what happens if, i…
> I'm asking about the errors that the language prevents, not the community's conventions.
My understanding is that, at the moment, the language doesn't have native threads yet. The design of multi-threading behavior and errors the language prevents is still being worked out.
Re: Crystal: Fast as C, Slick as Ruby
#439Earlier quoted context omitted.
All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as muc…
There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lan…
The first benchmark ("Nim vs Rust") I looked at says
> Rust regex! runs faster than Regex
which is a very old claim - Regex should now be much faster than regex! ever was. Any pre-1.0 Rust benchmarks are probably wrong (to be fair, most benchmarks are probably wrong anyway).