How to speed up the Rust compiler in 2018

Re:How to speed up the Rust compiler in 2018 by burntsushi on Tuesday May 01, 2018 @10:13AM (#16967156)

You're just moving the goalposts. Pretending an entire language barrier is the same as the barrier between Rust's safe/unsafe is kind of ridiculous. The friction for use is on a completely different scale, not only in terms of convenience but performance as well. For example, a regular expression library might use unsafe internally, but forcing every use of that library to operate in a higher level language to achieve safety is simply a non-starter.

> Very likely, we work on different kinds of projects.

I work heavily with finite automata. Similar libraries written in C or C++ use pointer based stuff quite heavily, but none of it has so far turned out to be necessary in Rust while also achieving comparable performance.

This continues to miss the point that Rust permits building safe abstractions over unsafe internals. Even if you need to use raw pointers in Rust, you're not only no worse off than you are in C++, but you can actually encapsulate that use in a way that is guaranteed by the type system without resorting to using a completely different programming language.

> Why do you think Mozilla doesn’t use Rust for their DOM tree implementation

I'm not involved with that project, so I wouldn't know, and I wouldn't speculate. You shouldn't either.

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by Const-me on Tuesday May 01, 2018 @06:40PM (#16972407)

> Pretending an entire language barrier is the same as the barrier between Rust's safe/unsafe is kind of ridiculous.

I’m not pretending that. Just two points.

1. If you really need unsafe code, because raw pointers, or other reasons, C++ is safer than unsafe Rust.

2. If your project has two distinct parts, unsafe lower level, and safer higher level, you don’t need to use C++ for both. Real world software use multiple languages in the same project for decades already, e.g. QuakeC was developed in 1996.

> a regular expression library might use unsafe internally

If a library wants to do that, it probably means that safe language is too slow :-) https://github.com/dotnet/corefx/tree/master/src/System.Text...

> I work heavily with finite automata.

I’m not saying Rust is useless. There are projects where it shines, and where I’d probably picked it myself. Like a web browser CSS engine, or your finite automata, or many other things.

I’m saying that there’re large problem areas out there for which, due to various reasons, other languages are still way better than Rust. I do realize Rust evolves fast; eventually these areas might shrink or disappear. But in its current state, my opinion is the applicability is limited to very narrow areas: no bare metal, no SIMD, no GPU APIs, very limited asynchronous IO, limited embedded options, very limited numeric libraries, no GPGPU…

I’ve only listed the areas where I have recently (last couple of years) developed substantial amount of code in any other language.

It just happened that I didn’t work on either finite automata, nor browser CSS engines.

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by burntsushi on Wednesday May 02, 2018 @07:30AM (#16975909)

> If you really need unsafe code, because raw pointers, or other reasons, C++ is safer than unsafe Rust.

I don't agree. I've told you why. I find speaking with you very frustrating, and it's not clear to me that you've actually understood my point unfortunately. :-/

> If a library wants to do that, it probably means that safe language is too slow

That doesn't make any sense.

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by Const-me on Wednesday May 02, 2018 @07:17PM (#16981992)

> I find speaking with you very frustrating

Yeah, same here. You’re insinuating things I didn’t said nor meant.

> it's not clear to me that you've actually understood my point

I disagree with your points, and I've told you why.

[ Parent | on HN ]