[steveklabnik]

I don’t know much about how Babel is implemented, but this uses the excellent rayon crate, which makes data parallelism awesome and easy. Rust is also generally fast, especially when you put effort into performance, which (from the creator talking about this on reddit) was a big goal.

This is the kind of thing Rust should be excellent at.

[Matthias247]

> This is the kind of thing Rust should be excellent at.

I would actually think this (compilers) is a thing where Rust doesn’t have that big of an advantage. Compilers are very special. They mostly deal with some kind of tree transformation. And as soon as those trees use owned nodes (E.g. in the form of Box of Rc) things are not that far from what a speedy managed language would do. Compilers are also non realtime at all. It doesn’t really matter if there’s a GC pause or not, and whether individual allocations are quick or slow. The only thing that matters is the overall throughput/performance.

Now this statement shouldn’t mean that Rust is bad at doing compilers (enough projects tell otherwise). Only that in other domains (E.g. realtime and low level code, graphics, audio, etc) it’s advantages might be even bigger.

[girvo]

I agree - which is why I’ve kept an eye on Fastpack as a replacement for my biggest bottleneck which is bundling — which is really just a special case of a compiler in a lot of ways. OCaml is brilliant for these tasks.

https://github.com/fastpack/fastpack/blob/master/README.md

[peterhunt]

I bet if you compared single threaded performance you’d still blow Babel out of the water. Even with the best JITs, idiomatic js code is so much harder/impossible to optimize than idiomatic rust or c/c++ code.

[steveklabnik]

This might be true, but Babel is a big, important project. I’d have expected performance to be something they’ve invested in. That may be wrong.

[acemarke]

The Babel team is great.... and they're also tiny, overworked, and underfunded. (See some of Henry Zhu's recent conference talks on dealing with being an OSS maintainer for background.)

I think Babel 7 had some perf improvements (including tweaks contributed by Benedikt Meurer from the v8 team), but I don't think they've ever had time to focus on just improving perf.

[hzoo]

Yep there's been various PRs for perf over the years but it's never been a focus per-se, and we've had help from various people including the v8 team https://twitter.com/left_pad/status/927554660508028929. Haha yeah no one wants to hear about open source sustainability in a thread about asking that tools be correct/fast/easy to use at the same time :D

It's true, speed is not really a concern on my mind at the moment - rather that we have enough people even willing to contribute back at all

[steveklabnik]

Trust me, I am well aware that even big open source projects don’t get the resourcing they deserve. Everyone always has to make do. Babel is a fantastic project.

[hzoo]

haha oops I totally wasn't looking at who I commenting with, definitely agree! Thanks!

[steveklabnik]

Yeah, those kind of one-off contributions was what I was meaning. You are 100% right with regards to expectations, and I don’t mean to imply that they should have. Only that it’s a bit more likely than some random projetct that nobody uses.

[vram22]

>this uses the excellent rayon crate, which makes data parallelism awesome and easy.

Is that somewhat similar to D's std.parallelism module? A simple example of its use here:

https://jugad2.blogspot.com/2016/12/simple-parallel-processi...

[steveklabnik]

A similar idea, yes. Details may be a bit different.

[vram22]

Got it, thanks.

[purple_ducks]

> which makes data parallelism awesome and easy

There's still going to be a finite number of cores on a machine. I can't see gaining parallelism being that big a boost (as opposed to gaining concurrency(if not already there))

[steveklabnik]

I would expect this task to be CPU bound, not IO bound. Maybe that’s incorrect.

[zozbot123]

You'd be surprised, even consumer-grade CPUs are fast approaching manycore territory these days. Just look e.g. at AMD's Threadripper, which BTW is being targeted at hobbyists and enthusiasts, not just professionals. (There are also ARM-based 'desktops'/'workstations' with comparable number of cores.) If we want to make anywhere near full use of these capabilities, we'll need easy parallelization (for applicable problems) to become essentially ubiquitous. Rust and Rayon are perfect for that.