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

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

201–210 of 215 posts

Re: Rust 1.24

#201

Post by civility »

coldtea wrote: post #136
civility wrote: post #99

Earlier quoted context omitted.

Not going to budge an inch, eh? It must be as good as it will ever get.

Is it they who didn't "budge an inch", or you, that despite a reasoned explanation, insist on the original accusation? Not to mention the underlying insinuation, that the Rust compiler developers are dumb for not being able to get at the 80s compiler's level of speed -- since you don't seem to accept that this is a byproduct of the advanced optimizations and security guarantees they do.

My criticisms are meant to point out areas for actual improvement.

Try to be scientific. If you've got a conjecture, test it and see if it holds water. One excuse was that C++ is only faster because people build C++ projects with separate compilation units. Well, you can compile a project in C++ with a single compilation unit, and it's not horribly slow. Now you need a new conjecture.

The type system is comparable to Standard ML from the 70s. The lifetime analysis is a solid improvement over mainstream languages, but I have a tough time believing it needs to be an order of magnitude slower than const correctness. The optimizations are on par with C++ and Fortran (mostly because they're leveraging the guts from an existing C++ compiler). SML, C++, and Fortran do not compile as slowly as Rust. There's probably another reason.

I don't think the Rust compiler developers are dumb, and I never said that. I think several of them are brilliant but young (and occasionally very arrogant).

Rust is so close to being a great replacement for C++. I read every one of these threads about new releases hoping they'll eventually fix the problems. Compilation speed and memory use are lesser issues, but they're still important, and things like incremental compilation dodge the issues instead of fixing them.

Re: Rust 1.24

#202

Post by civility »

pcwalton wrote: post #144
civility wrote: post #108

Earlier quoted context omitted.

It means things don't usually get better until you admit they're not as good as they can be.

rustc could definitely be faster. I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I…

> I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. [...] magic bullet

I didn't suggest low hanging fruit or a magic bullet. If anything, incremental compilation is being promoted as that kind of thing, and I just wanted call it into question.

Re: Rust 1.24

#203

Post by pvg »

ZenoArrow wrote: post #154
pvg wrote: post #134

Earlier quoted context omitted.

If you understand what it means, then you'd know that it means that all programming languages are comparable I think this is where we strongly diverge and I resent, a bit, your implication that because I don't buy into this I somehow 'don't understand what it means'. I understand what it means. I just think it's plainly ridiculous.

> "I just think it's plainly ridiculous." You compared a Dremel to a plasma cutter as a way to explain the differences between Python and Rust, how is that any less ridiculous?

It’s an analogy and like most analogies it’s imperfect. My point was and remains that a really bad argument (“everything is Turing-complete!”) is not much of a critique of that or really any analogy. Because it’s so obviously shallow and bad.

Re: Rust 1.24

#204

Post by ZenoArrow »

pvg wrote: post #203
ZenoArrow wrote: post #154

Earlier quoted context omitted.

> "I just think it's plainly ridiculous." You compared a Dremel to a plasma cutter as a way to explain the differences between Python and Rust, how is that any less ridiculous?

It’s an analogy and like most analogies it’s imperfect. My point was and remains that a really bad argument (“everything is Turing-complete!”) is not much of a critique of that or really any analogy. Because it’s so obviously shallow and bad.

> "My point was and remains that a really bad argument (“everything is Turing-complete!”) is not much of a critique of that or really any analogy. Because it’s so obviously shallow and bad."

You're getting hung up on a minor detail. My main point was not about Turing completeness. My main point was that requesting a comparison of programming languages is a legitimate request. Turing completeness is just one angle by which to see this. As you seem to object to that suggestion, there are plenty of other ways to explain it.

For example, one way to compare languages is to look at the key libraries and frameworks that have been built up around them. So for example, Rocket vs Django, Diesel vs SQLAlchemy, etc... If we're comparing languages, we should compare what the languages makes it easy for us to do, and libraries are a big part of that.

Another way to look at this suggestion is that "writing performant code" is something that's easier in some languages than others, and the libraries built using those languages are likely to reflect that. However, performance is just one metric by which to compare languages/libraries/frameworks, which is another reason why these comparisons can help in building an understanding in when a language is likely to be the best one for the job.

Lastly, to make this as clear as possible, I'm not advocating for Python or for Rust, I am only advocating for language comparison as a helpful approach when building familiarity with programming language strengths and weaknesses. Both Python and Rust have niches they excel in, but there's also a large amount of overlap. As an example, game frameworks exist for both Python and Rust, and discussion can help others find what's best for them.

Re: Rust 1.24

#205

Post by ZenoArrow »

laxd wrote: post #200
ZenoArrow wrote: post #196

Earlier quoted context omitted.

If you understood what MyHDL is doing, you'd know that doesn't matter. Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.

No I am not simply talking about performance. I see you keep refering to Turing completeness in other replies, even condescendingly implying that your HN peers does not understand it, when you are clearly the one whose understanding needs to mature. A turing complete system is one where the rules are powerfull enough that you are able to implement "anything" INSIDE of them. Does'nt mean you are able to break out the…

> "Does'nt mean you are able to break out the system and manipulate the underlying environment"

I didn't think I'd have to spell things out so excessively, but... let's extend the description then... Any Turing complete language where you can write files to storage. To give an example of why the storage is relevant, let's look at Java. Java's sandboxed in the JVM right? However, if you think about it more broadly, as long as you can freely write files to disk you can write machine code to disk. In other words, as you can write a compiler in Java, you can break out of the sandbox.

As for Minecraft, I don't know enough about it, but if it's possible to write a compiler in Minecraft then that would have the same escape hatch too. It might not be a tool you choose to code a BIOS, but we're not looking at whether something is optimal, we're looking at whether something is possible.

> "I see you keep refering to Turing completeness in other replies"

> "Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win."

Perhaps you overlooked the following quote as it didn't fit with what you decided you wanted to say...

"I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option."

Re: Rust 1.24

#206

Post by pcwalton »

civility wrote: post #198
coldtea wrote: post #135

Earlier quoted context omitted.

I hope you see the irony in accusing them of that in a post announcing that the compiler just got better.

It's not ironic. I see this kind of thing all the time. Rather than cleanup and speedup an implementation, engineers will make it multi-threaded or send it off to a GPU, generally achieving limited improvements and greater complexity. In this case, rather than make the compiler faster, they hack it up with incremental compilation. It's still slow, but they apply the slow code to less data and call it a win.

Nobody who reads the rustc commit history would agree that this is what is going on. The number of straightforward changes that are constantly made in the service of small performance improvements far outweighs the work on incremental compilation.

Re: Rust 1.24

#207

Post by pcwalton »

civility wrote: post #201
coldtea wrote: post #136

Earlier quoted context omitted.

Is it they who didn't "budge an inch", or you, that despite a reasoned explanation, insist on the original accusation? Not to mention the underlying insinuation, that the Rust compiler developers are dumb for not being able to get at the 80s compiler's level of speed -- since you don't seem to accept that this is a byproduct of the advanced optimizations and security guarantees they do.

My criticisms are meant to point out areas for actual improvement. Try to be scientific. If you've got a conjecture, test it and see if it holds water. One excuse was that C++ is only faster because people build C++ projects with separate compilation units. Well, you can compile a project in C++ with a single compilation unit, and it's not horribly slow. Now you need a new conjecture. The type system is comparable to…

Borrow checking is a lot more involved than const correctness. It's not even in the same league. Const correctness just adds a few more types, whereas borrow checking involves generating sets of constraints and solving them with a constraint solver, something C++ doesn't really have to do at all.

The type system of Rust goes significantly beyond that of Standard ML, because of traits/typeclasses among many other features. Also, Standard ML is usually not implemented with monomorphization, which affects compile time.

> Compilation speed and memory use are lesser issues, but they're still important, and things like incremental compilation dodge the issues instead of fixing them.

Incremental compilation is a way of addressing the compile time and memory usage issues. It's just not the way you seem to want them to be fixed. Nobody did incremental compilation for fun; it was done because without it we didn't believe we could reach our compiler performance goals.

Again, you're asking for a magic bullet, and I'm saying it's not likely that there is going to be one. If one existed, it probably would have been found already. There's lots of hard work that has been done, and lots of hard work ahead.

If I had to guess what the most important issue is, it's that idiomatic Rust generates a lot more LLVM IR than idiomatic C++ does, because it leans on abstractions for safety and developer ergonomics. Think about how many more closures Rust code uses, what for loops expand to, what pointer arithmetic compiles to (ptr::offset), etc...

Re: Rust 1.24

#208

Post by pcwalton »

civility wrote: post #202
pcwalton wrote: post #144

Earlier quoted context omitted.

rustc could definitely be faster. I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I…

> I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. [...] magic bullet I didn't suggest low hanging fruit or a magic bullet. If anything, incremental compilation is being promoted as that kind of thing, and I just wanted call it into question.

Nobody thinks incremental compilation is a magic bullet! The article specifically says "This is still not the end story for compiler performance generally, nor incremental compilation specifically."

Re: Rust 1.24

#209

Post by littlestymaar »

ComputerGuru wrote: post #141
nine_k wrote: post #105

Earlier quoted context omitted.

Java without generics used to compile pretty fast. When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.

Basic generics in rust don’t have that much overhead; it sounds like your conflating generics with templating. Generics aren’t Turing complete, unlike C++’s templates. Other languages with powerful generics and type inference like modern C# clearly manage just fine, too.

> Generics aren’t Turing complete, unlike C++’s templates.

They are actually, but only anecdotically (like PowerPoint is also Turing Complete).

Re: Rust 1.24

#210

Post by kod »

SanFranManDan wrote: post #183
kod wrote: post #171

Earlier quoted context omitted.

Walk middle, sooner or later get the squish just like grape.

> Avoiding both these extremes, the Tathagata (the Perfect One) has realized the Middle Path; it gives vision, gives knowledge, and leads to calm, to insight, to enlightenment and to Nibbana.

But I bet Mr. Miyagi could beat up your Tathagata in a coding contest.
Post reply on HN