Crystal: Fast as C, Slick as Ruby • Hacker News Board

Re: Crystal: Fast as C, Slick as Ruby

#181

Post by bjz_ » Thu, Aug 04, 2016, 11:24 AM UTC

iamd3vil wrote: post #165

solidsnack9000 wrote: post #128

Earlier quoted context omitted.

The biggest practical downside with Elixir relative to Crystal is lack of types. The per-thread GC is an important advantage, though.

Elixir has optional typing though. You can type check with Erlang's Dialyzer.

Dialyzer uses success types, which don't always let you know when you have a soundness problem. The only thing you can count on is that if it does cry out, there certainly is something you need to fix. It also lacks parametric polymorphism, which means you often lose a great deal of useful type information. The theory behind Dialyzer is impressive, but I was pretty disappointed with it in practice.

Re: Crystal: Fast as C, Slick as Ruby

#182

Post by exDM69 » Thu, Aug 04, 2016, 11:27 AM UTC

pjmlp wrote: post #175

exDM69 wrote: post #170

Earlier quoted context omitted.

About GC: it would be nice if there would be some kind of standard-ish implementation framework for a GC in an LLVM language. LLVM has been enabling fantastic new programming languages, and while it has support for a GC, I have not found a GC library that would be easy to embed in a new compiler/runtime environment. Now there are dozens of LLVM-based languages (or language prototypes) that have different, incompatibl…

It is very hard to have a general purpose GC library, because the best GC algorithms require a tight cooperation between compiler, GC and language semantics. For me, the only viable alternative to GC are substructural type systems like in Rust's case.

You're definitely right and it's not an easy task.

However, I think there's a sweet spot where you could implement a fairly nice boilerplate/framework that would be an 80% solution to the problem which would be a vast improvement over the current state.

The missing 20% would be language specifics and that would be either solved by forking the boilerplate code or writing some kind of callbacks for discovering references given a root object.

edit: Additionally, there's no simple example of using a GC with LLVM. It would be very helpful if there was, for example, a GC'd version of the Kaleidoscope language used in the LLVM tutorials. Even a trivial Lisp-style cons/car/cdr object system coupled with the simplest possible mark'n'sweep GC would be good.

Re: Crystal: Fast as C, Slick as Ruby

#183

Post by iamd3vil » Thu, Aug 04, 2016, 11:32 AM UTC

StavrosK wrote: post #169

rdtsc wrote: post #36

Earlier quoted context omitted.

> that if it wasn't FOSS I'd have decided it's being astroturfed. That's a good sign! You know why? Because it has a great community and is very friendly for new comers. Jose, Eric and the rest of the team made that a priority and it shows. It doesn't just mean being nice on IRC, it also means putting usability first, putting more effort in how example looks, how documentation looks and so on. If Google invented a la…

"Friendly for newcomers"? I tried to write something the other day, and had an Erlang developer friend to help me. The Elixir docs section just says "buy one of these books to get started", which is completely unacceptable, and we (mostly my friend, as I had no idea what anything is) spent an hour trying to figure out how to run a node, with Google not providing any useful answers. That's as hostile to newcomers as i…

Elixir has a very good getting started guide[0]. I don't know if you have seen this or not. Even in the learning section, it recommends going through the getting started guide. It mentions other books in other resources. I don't know why you think it's hostile to new comers.

I learned Elixir totally from Getting started guide and then the documentation. Then for OTP, I have read an Erlang book to understand it well. Elixir's documentation is really awesome and one of the best I have seen.

[0] - http://elixir-lang.org/getting-started/introduction.html

Re: Crystal: Fast as C, Slick as Ruby

#184

Post by wott » Thu, Aug 04, 2016, 11:46 AM UTC

bluetomcat wrote: post #67

Athas wrote: post #6

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's re…

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…

> 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 much as possible. You craft your own data structures suited for the problem at hand, rather than using the standard "one size fits all" ones. Compare that to the "new this, new that" style of programming that's prevalent today.

Exactly! I cannot agree more.

I have a small test program I port to different languages to test the length of the code and the speed of the program. Of course it only represents a single use case.

* C is first, of course.

* twice as slow, come Pascal, D and... Crystal!

* x3 to x5, come Nim, Go, C++ (and Unicon).

* x6 to x9, come Tcl, Perl, BASIC (and Awk).

* x15 to x30, come Little, Falcon, Ruby and Python.

* x60 to x90, come Pike, C#, Bash.

* x600 to x1000, come Perl6 and Julia.

This list looks byzantine, I know :-) The trends I can get out of it:

* the last 2 are languages with JIT compilation, and that's horrid for short programs.

* the "old" interpreted (or whatever you name it nowadays) languages (Tcl, Perl) are not so bad compared to compiled languages, and much faster than "modern" one (Ruby, Python). (Again, this is only valid for my specific use.)

* compiled languages should all end up in the same ballpark, shouldn't they? Well, they don't. The more they offer nice data structures, the more you use them. The more they have some kind of functional style (I mean the tendency to create new variables all the time instead of modifying existing ones) the more you allocate and create and copy loads of data. In the end, being readable and idiomatic in those languages means being lazy and inefficient, but what's the point of using those languages if don't use what they offer? C forces you to use proper data structures and not re-use existing ones. It comes naturally. What is unnatural in C is to copy again and again the data, it is simpler to modify the existing one and work on the right parts of it, not to pass the whole chunks every time you need one single bit. In more evolved languages, compilation won't save you by doing some hypothetical magic tricks, it cannot remove the heavy continuous data copying and moving you instructed your program to do. And that is what made the difference in speed between C on one side, and D, C++, Go on the other side.

Re: Crystal: Fast as C, Slick as Ruby

#185

Post by JohnStrange » Thu, Aug 04, 2016, 11:54 AM UTC

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

I have no problem with GC, but I want to see reasonably complicated benchmarks that actually show that it's "fast as C". Because I don't believe that at all.

Re: Crystal: Fast as C, Slick as Ruby

#186

Post by wott » Thu, Aug 04, 2016, 11:58 AM UTC

progman wrote: post #90

bluetomcat wrote: post #67

Earlier 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…

> You avoid allocations wherever possible If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast that garbage collections don't really matter in most cases. Consider SBCL (compiled Common Lisp) which is almost as performant as Java and C++. http://benchmarksgame.alioth.debian.org/u64q/lisp.html I used…

> If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast

What? RAM is not fast at all, the latencies have almost not improved in 20 years (compared to the improvement of other subsystems like the CPU, of course).

Re: Crystal: Fast as C, Slick as Ruby

#187

Post by jjnoakes » Thu, Aug 04, 2016, 12:02 PM UTC

p0nce wrote: post #118

yamadapc wrote: post #92

Earlier quoted context omitted.

The D Language ( http://dlang.org/ ) has a @nogc pragma ( https://dlang.org/spec/attribute.html#nogc ). You just annotate functions that you don't want to use the GC in with it and it'll assert that they don't use it.

Since you can: - disable the GC - deregister threads so that they are not stopped by GC - eventually avoid the runtime altogether There really is no realtime system that D can't do. The whole anti-GC thing is a giant strawman that consider all GC stop-the-world, unavoidable, and overarching. Academia decided in favor of GC decades ago, and industry has been following suit for good reasons: mental overhead associated…

You speak as if a GC is unconditionally better than alternatives and it is a solved problem but using a GC has issues as well.

On the theoretical side, not reasoning about ownership means sharing data betweent threads is done with copies (slower) or locking (slower and error prone); if you know about ownership you can share references to data while it can't be mutated for free.

Ownership is also important for any non-memory resource (file handles, mutexes, etc). GCs release those "whenever", maybe never, unless you close manually.

And even though manual memory management has some small non-deterninistic overhead for heap coalescing (which one can usually work around with pools), most GCs I've worked with add measurable overhead. This equates to more cost per server, more load, more battery life drained, higher response times...

Re: Crystal: Fast as C, Slick as Ruby

#188

Post by smnplk » Thu, Aug 04, 2016, 12:07 PM UTC

exDM69 wrote: post #168

welder wrote: post #79

Stopped reading when I saw the `end` keyword... the most annoying part of Ruby. Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys can't silence me!!! ;)

The syntax of a language is about the least interesting thing about them. I don't care about curly braces, end keywords or semicolons as long as it is consistent (and fairly easy to parse, so there can be good tooling). The interesting parts are in the semantics, type systems and runtime features. Choosing a programming language based on the syntax is like choosing your significant other based on looks alone. You're…

Or judging the performance of a sports car by its colour.

Re: Crystal: Fast as C, Slick as Ruby

#189

Post by seren » Thu, Aug 04, 2016, 12:08 PM UTC

exDM69 wrote: post #154

seren wrote: post #145

Earlier quoted context omitted.

To answer your last question, Hard real time embedded systems are everywhere in Robotics, Aerospace, Telecommunications, Automotive, Medical devices.. The real time capabilities are not always done in pure SW, there are some FPGAs, but when you do rely on SW, you often can not afford to spend even a few milliseconds in GC. In some case, that would mean killing or maiming someone. And you are often tied to the HW vend…

Even soft real time systems like games or real time networking solutions suffer from non-deterministic GC pauses. Audio processing is another example. You can get by in a GC'd system if you're careful not to allocate while being in the "hot path", but it's much more difficult than manual memory management (you need to know the internals of the GC algorithm) and interference from other threads may spoil your hard work…

It was not clear from my post, but what I would like to have is a RTOS with an implementation of the Rust std modules, to be able to develop an application on top of it. As far as I know, no one is working on that.

Re: Crystal: Fast as C, Slick as Ruby

#190

Post by CyberDildonics » Thu, Aug 04, 2016, 12:14 PM UTC

thinkpad20 wrote: post #62

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

Manual or deterministic memory management might be a must-have for certain usage domains, but for any domain in which one would be using ruby, this seems unlikely, and presumably one could FFI into C when this is the case. There are hardly any languages commonly used in industry which don't have GC (essentially just C/C++). And many of these garbage-collected languages are capable of blazingly fast code with a small…

If you write programs with a gc there is always a level which you can't get your hands on to change. If you want to create a piece of a puzzle that is tiny, does one thing, and does it right, like a shared library, a command, a linkable object, or any tiny standalone binary, the gc is always a thorn.

Anything where memory or interactivity needs to be tightly controlled is problematic with a gc. Not only that, but a gc doesn't scale as well with lots of threads. Ultimately you need thread local allocation since you will eventually be bottlenecked by the fact that typical allocation (with malloc, VirtualAlloc, mmap, etc) is protected by a mutex, and deallocation suffers the same fate.