Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crystal: Fast as C, Slick as Ruby

blog.codeship.com

Post reply on HN
Print view View original

421–430 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#421

Post by dbaupp »

mike_hearn wrote: post #412
bluejekyll wrote: post #312

Earlier quoted context omitted.

> That doesn't mean I can't want predictable performance or deterministic destruction. Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it o…

Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a…

Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozilla both improves Firefox and works on Rust.

[0]: https://hacks.mozilla.org/2014/09/generational-garbage-colle...

[1]: https://hacks.mozilla.org/2015/07/compacting-garbage-collect...

Re: Crystal: Fast as C, Slick as Ruby

#422

Post by dikaiosune »

mike_hearn wrote: post #412
bluejekyll wrote: post #312

Earlier quoted context omitted.

> That doesn't mean I can't want predictable performance or deterministic destruction. Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it o…

Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a…

> fighting the borrow checker

My experience is that this is an initial hurdle to clear. As an example, I've almost exclusively worked in GC'd languages for a while, and after learning Rust for a few months I very very rarely have borrow check errors.

The fact that it occasionally requires a complex pattern to do right should get better with time (non-lexical lifetimes would help), and there's also discussion around GC integration so that you could interact with a scripting language GC when writing a plugin for it, or you could farm out GC'd objects when you need to have cycles (i.e. in graph algorithms).

> the Chrome guys have gone in the direction of deploying a GC into C++

Interesting. I'm curious how much of the browser relies on it. I'm also curious whether it's an attempt to paper over C++ with a little memory safety, or whether it actually offers performance improvements. My original point was not that GC is bad, per se, but that I quite like being able to avoid it when it's reliable to do so, which is not the case in C++, IMO.

Re: Crystal: Fast as C, Slick as Ruby

#423

Post by dikaiosune »

current_call wrote: post #395
anp wrote: post #262

Earlier quoted context omitted.

> But most likely - you simply do not need a language without a GC. Absolutely. That doesn't mean I can't want predictable performance or deterministic destruction. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up (i.e. on the overhead of managed runtimes and GCs). Before, I'd have argued that it was just necessary. Having spent a bunch of time…

That doesn't mean I can't want predictable performance or deterministic destruction. You're assuming your compiler or operating system won't cause memory to be freed at different times. I also think it's a shame that we waste so much electricity and rare earth minerals on keeping ourselves from screwing up. Wasting man hours on manufactured problems is far worse than wasting coal.

Memory isn't the only resource managed by deterministic destruction.

Manufactured problems? When what's now coastline is underwater, I'll be glad to see if you remain as smug.

Re: Crystal: Fast as C, Slick as Ruby

#424

Post by mike_hearn »

dbaupp wrote: post #421
mike_hearn wrote: post #412

Earlier quoted context omitted.

Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a…

Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozilla both improves Firefox and works on Rust. [0]: https://hacks.mozilla.org/2014/09/generational-garbage-colle... [1]: https://hacks.mozilla.org/2015/07/compacting-garbage-collect..…

Those are all about the JavaScript GC, right? Not using the GC for actual pure C++ objects.

Re: Crystal: Fast as C, Slick as Ruby

#425

Post by steveklabnik »

mike_hearn wrote: post #412
bluejekyll wrote: post #312

Earlier quoted context omitted.

> That doesn't mean I can't want predictable performance or deterministic destruction. Exactly. To just add to your point, there is no longer a reason to settle for GC pauses with Rust. It does require more thought while writing the code, but what you gain is a firmly consistent runtime. If your memory allocation is slow, you can create your own allocator/slab, and then use that for hot memory space and optimize it o…

Two reasons: 1) Rust appears to be significantly less productive than a true GCd language. I see a lot of people talking about "fighting the borrow checker" with Rust and I see a lot of articles describing basic patterns that would be simple in any other language, but are complex in Rust. 2) If you want to invoke code that assumes a GC you need to have one. You can do manual memory allocation in Java by the way and a…

  > I see a lot of people talking about "fighting the borrow checker" with Rust
It's also usually described as "at first, I fought the borrow checker, but then I internalized its rules and it's now second nature." You're not wrong that it's a hump to get over, but once you do, it's not a big deal.

  > that would be simple in any other language,
Any other _GC'd_ language. You still fight the same kinds of complexity when you don't have GC.

Re: Crystal: Fast as C, Slick as Ruby

#426

Post by im_down_w_otp »

bjz_ wrote: post #407
im_down_w_otp wrote: post #402

Earlier quoted context omitted.

You didn't enable the right flags.

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.

Re: Crystal: Fast as C, Slick as Ruby

#427

Post by dbaupp »

mike_hearn wrote: post #424
dbaupp wrote: post #421

Earlier quoted context omitted.

Mozilla has also put significant effort into improving their C++ GC in Firefox, e.g. switching from a non-generational one to a generation GC[0] and then to a compacting one[1]. Just like Google can both improve Chrome and work on Go, Mozilla both improves Firefox and works on Rust. [0]: https://hacks.mozilla.org/2014/09/generational-garbage-colle... [1]: https://hacks.mozilla.org/2015/07/compacting-garbage-collect..…

Those are all about the JavaScript GC, right? Not using the GC for actual pure C++ objects.

I wasn't giving examples of Mozilla doing exactly what Chrome is doing, just counterexamples to your implication that working on Rust means no work on improving memory management in Firefox.

That said, it's not even like a single-GC approach is incompatible with Rust: https://blog.mozilla.org/research/2014/08/26/javascript-serv...

Re: Crystal: Fast as C, Slick as Ruby

#428

Post by clessg »

continuations wrote: post #404
asdf1234 wrote: post #161

Earlier quoted context omitted.

Erlang/Elixir is much, much faster than either Python or Ruby especially when it comes to workloads like your typical web app. In the Techempower benchmarks the Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. Look at the error column. I assume they'll be fixed in the next run.

Error isn't why Elixir performed poorly in the web framework benchmark. Take a look at the "Single Query" test [1]. The entry for Elli has zero error and is still slower than many Python & Ruby frameworks. [1]: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

Honestly that site's benchmarks have never been accurate for me in production. But that's how benchmarks work I guess - my bad for bringing up benchmarks! My experience with using Elixir/Phoenix for web applications has been extremely positive performance-wise however, and has surpassed or matched Go, Ruby, PHP, and Python consistently in all production scenarios. For the latter three, the difference has been order-of-magnitude.

It depends on the problem domain as always. If you're doing a lot of naïve single-threaded number-crunching, have fun. But Elixir/Phoenix haven't failed me for web applications, even in very intensive situations. It's the first time I've barely had to do any tuning beyond external factors such as network and database queries (which, by the way, Phoenix's Ecto handles very gracefully and explicitly).

This is my experience with every Elixir/Phoenix app I've worked on thus far. I apologize if I made it sound like some sort of universal truth.

Re: Crystal: Fast as C, Slick as Ruby

#430

Post by binki89 »

ksec wrote: post #429

For anyone familiar with Crystal, are there any plan to add pattern matching into Crystal?

Good question about pattern matching in Crystal. I found this reply by asterite (the creator of Crystal) to a similar question that is worth reading:

https://crystal-lang.org/2014/06/19/crystal-0.1.0-released.h...

The question was asked in the comments as with the reply. I'm sorry that I can't link to it directly but it's the seventh comment from the top.

Post reply on HN