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

The Rust compiler is still getting faster

blog.mozilla.org

Post reply on HN
Print view View original

81–90 of 100 posts

Re: The Rust compiler is still getting faster

#81

Post by nn3 »

carlmr wrote: post #69
nn3 wrote: post #67

1. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.

For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.

Yes that's true. Coverity and similar are even slower.

But then rust errors out on a lot of things the C++ analyzer wouldn't, a lot of those things are actually being reasonable code.

For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust version, which they undoubtedly will.

It's not that swapping is an obscure operation, many important and fundamental algorithms depend on it.

I'm probably overly cynical there, but I sometimes feel that all these arbitrary restrictions that make code hard to write make people feel better about rust because if they get their code to actually compile it's a sense of achievement that makes them proud. Kind of like a journey to find yourself or something like that.

But then i see that there is actually some progress in Rust to relax some of these restrictions (e.g. non lexical lifetimes in the borrow checker). If my theory above is true that would actually lower Rust's popularity over time. True? Probably not. But it's an interesting thought.

Re: The Rust compiler is still getting faster

#82

Post by carlmr »

nn3 wrote: post #81
carlmr wrote: post #69

Earlier quoted context omitted.

For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.

Yes that's true. Coverity and similar are even slower. But then rust errors out on a lot of things the C++ analyzer wouldn't, a lot of those things are actually being reasonable code. For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust v…

>For example I discovered recently that you cannot swap two pointer variables in rust without using unsafe. Surely there is some deep reason for that, that is really important until they can figure out how to fix it in some future Rust version, which they undoubtedly will.

Wouldn't this work? https://doc.rust-lang.org/std/mem/fn.swap.html

>But then i see that there is actually some progress in Rust to relax some of these restrictions (e.g. non lexical lifetimes in the borrow checker). If my theory above is true that would actually lower Rust's popularity over time. True? Probably not. But it's an interesting thought.

I'm not sure. Sometimes these restrictions are there, because it's too difficult to decide what should happen. I don't think it's malevolence on the language creators side. And I do think usability is always better.

I find that I'm running into way fewer such situations now than last year though, so I think a lot is happening here.

Re: The Rust compiler is still getting faster

#83

Post by carlmr »

oblio wrote: post #77
blub wrote: post #76

Earlier quoted context omitted.

A static analyzer which requires correct code to be rewritten in a certain way to satisfy the analyzer does not deserve to be called amazing.

Don't all static analyzers do that? Or they're just ignored, which happened in almost every large project I've ever seen.

Exactly. C++ code has so much variability that 90% of static analyzer warnings are worthless. So people ignore them and create terrible unsafe code.

Re: The Rust compiler is still getting faster

#84

Post by adrianmonk »

sddfd wrote: post #2

This is great! Many dev hours are spend waiting for the compiler, every second counts! The second order effects are even worse. After a minute, the programmer will start thinking about other things, running flow. If compiles regularly take 5min, devs will leave their desks (and honestly, who can blame them for it).

> start thinking about other things, running flow.

I've found it a helpful practice as a programmer to be intentional about this.

With a little awareness, you can identify situations where it really would be best to busy-wait while something compiles. (If the wait is not all that long and switching tasks harms focus.)

And with a little mental discipline and practice, you can train your mind not to wander. You don't totally blank your mind out, but you also don't let unrelated thoughts distract you. Just continue to think about the same thing you were when the compile started. Don't shift gears mentally, just ease up on the mental gas pedal.

It's so easy to let anxiety or guilt about wasting 2 minutes lead you into giving up focus, which is more precious. It's a false economy, and thus doing something else with those 2 minutes is actually more of a temptation than a smart idea.

(Of course, it's better if the tools are just fast! But sometimes you can't have that.)

Re: The Rust compiler is still getting faster

#86

Post by stcredzero »

derefr wrote: post #18
nindalf wrote: post #7

Earlier quoted context omitted.

The rust compiler team continues to set ambitious goals. Last I checked they wanted to extract much of the compiler front end into independent crates that can be reused by the Language Server. That's a pretty daunting refactoring, but the way they're going seems like it's achievable.

The one thing I’ve always wanted from a language runtime is for the data structures used by the compiler to be exposed in the stdlib. E.g. every compiler uses control flow graphs; so why doesn’t every language give me a batteries-included digraph ADT, that has every feature you’d need to implement a control flow graph, such that the compiler’s CFG is just a stdlib digraph instance? It’d be a great boon to writing you…

E.g. every compiler uses control flow graphs; so why doesn’t every language give me a batteries-included digraph ADT, that has every feature you’d need to implement a control flow graph, such that the compiler’s CFG is just a stdlib digraph instance?

By the same token, I'd like to see dynamic languages with a tracing JIT, show what types are used in the actual runtime. There was an article posted to HN a few years back, where some researchers noted that most dynamic language servers seem to go through an initial startup period, where there's some dynamic type shenanigans, then settle down to a state where the types are basically static.

Re: The Rust compiler is still getting faster

#87

Post by gpderetta »

taejo wrote: post #79
ynik wrote: post #41

Earlier quoted context omitted.

Yes, but they hide the memory layout as an implementation detail, thus negating most advantages of an intrusive list. You can't call `std::list ::erase()` with a Node* , and you can't write a function that converts from Node* to `std::list ::iterator` in standard C++, even though it's really just a matter of subtracting a fixed number of bytes from the pointer value. So you instead need to store the `std::list ::iter…

There's boost::intrusive::list which IME actually works quite well. There is a node type which elements derive from or contain, so you can get an iterator from an element, as well as the other way round. To include an element in multiple lists, just aggregate the node type multiple times.

Boost.Intrusive is beyond awesome. You can add nodes not only to multiple lists, but also to maps, set, hash_maps to build multi-indexed data structures (and with delete hooks all indices can be kept consistent).

Re: The Rust compiler is still getting faster

#88

Post by tracker1 »

nn3 wrote: post #67

1. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.

    - correct
    - cheap
    - fast
Pick two

Re: The Rust compiler is still getting faster

#90

Post by jplayer01 »

hu3 wrote: post #73
sfkdjf9j3j wrote: post #66

Earlier quoted context omitted.

Ada languished for years with expensive, proprietary compilers and a community that largely ignored open source culture. Is it any surprise that Rust is having more success breaking into the modern mainstream software world?

I fail to see how your parent implied surprise.

I don't feel the comment was made in an adversarial way. Just pointing out some reasons why Ada didn't become widespread. There are plenty of decent languages with great high-level constructs and features that failed to gain/maintain meaningful industry penetration after C hit the stage. I'd say Ada is just another victim of that success, along with the issues he mentions. It's unfortunate, but that's how it is. Maybe Rust can reach a wider audience in a way Ada was unable to, while providing similar safety guarantees.
Post reply on HN