civility

If you can reduce everything to _one_ mutex, that's simple. As soon as you have two mutexes, you need to start worrying whether one thread grabs A then B and another grabs B then A. In larger projects with multiple people contributing, the mutex and condvar approach does not scale well. It's very easy to get difficult to reproduce race conditions.

> But hey, I'm guessing you actually don't know what the words I'm using even mean

I can't believe this comment wasn't reprimanded. This is one of the least civil things I've seen someone here say in the last month. This type of response does not belong here.

I guess anything goes as long you're on the correct side of an argument. Fucking hypocrites.

I'm not going to dive into your points about constraint solvers, type classes, or "monomorphization". Unless those things take more than a few percent of the compile time, they're just more red herrings.

> 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.

I'm well aware that my opinion doesn't matter, but I doubt incremental compilation will make any real strides towards making things as good as they could be. It sounds like the real problem is here:

> 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

I suspect every single feature in idiomatic Rust has a one-to-one translation to some bit of C++ that isn't too horrible. You can do lambdas, iterators, generators, or whatever else it takes to do Rust style for loops and closures in C++, and it won't choke the compiler. So while I don't doubt rustc is generating a lot more IR, I doubt it needs to.

Maybe the MIR optimization pass will move in that direction.

> 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.

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.

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.

> I think this gets at Wirth's law a bit.

I think Proebsting's law is also relevant. Compilers did an impressive job of optimization in the 90s, and while yes there have been advancements in the last 18 years, it's foolish to over-estimate the progress.

Also, considering how much hardware changes have improved performance (speculative execution, register renaming, etc...), it wouldn't surprise me if many compiler optimizations have become less important with time. For instance, peep-hole instruction scheduling has to matter less than it once did.

> how many of those lines did the compiler actually generate code for?

Not many. How many lines would a comparable Rust program have to instantiate? (should be the same)

All I was trying to do was make an apples to apples comparison by discrediting the implication that the clang++ and g++ compilers are only faster because people use separate compilation units.

I think it's fair to compare Rust and C++ this way, and if Rust is slower to compile, then it's fair to ask why.

> Did you have optimizations enabled?

Yes, -O3. Also -Wall -Wextra and -fwrapv if you're interested.

Below, steveklabnik claims these things are miniscule. Are you really sure you know what is actually slow?

No idea, maybe a lot from the system headers. However, it was 20,000 lines of code that survived the preprocessor, 11,000 of which were inline or template from the project itself.

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

> Don't forget the differences in compilation model; C/C++'s compilation units are much smaller

Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code with "gcc -E" to get the headers, I just compiled 20,000 lines of C++ from scratch in .6 seconds with gcc and .4 seconds with clang. I don't have a comparable project in Rust.

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

Oberon certainly compiles quickly, and I believe Delphi (Pascal-ish) was fast too, but I was thinking of Microsoft's Java compiler before they got spanked.

> Incremental compilation!

Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse.

I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow.

If you neglect some of the metaclass stuff, which I believe most people do, then Python is nearly isomorphic to JavaScript. I think the comparison is very fair.

I also believe the reason Python is unlikely to ever catch up to JavaScript is the same reason that CPython will always be the dominant implementation - They've exposed so much of the C internals, that everyone is bound to the actual slow and single threaded implementation. JavaScript implementations in web browsers can do lots of magic behind the curtains because the majority of users don't rely on the actual innards being consistent from release to release.

> I see a 4x speedup on most of my slowest pure python workloads

Heh, only 25..250 X to go. We did a direct line for line translation of some numerically intensive code from Python to C++ and saw a literal 1000X speedup. On other projects, it's been more like 100X slower. That says two things: first Python can be really slow, second, for some programs, Python doesn't really save on lines of code over modern C++.

I've been very impressed with PyPy however. In testing, it can sometimes sneak up to less than a factor of 2 slower than C. However, the bummer comes when it doesn't hit that mark and you have no idea how to trick the JIT to do better. If it works, great. If it doesn't, you don't have much insight into why.

Finally, I've always been able to get Cython to parity with C++. However, when I'm done, I wonder what I gained. The C++ isn't that much more complicated than adequately type annotated Cython.

Why are they "genuine successes", but only "alleged problems"? I think you're giving them credit for alleged successes and ignoring the genuine problems.

> The other name for big-endian is "network order", after all.

I wonder where this started... I always suspected it was Sun with their "The Network is the Computer" motto, and of course they would define "network byte order" as what they used.

Today, it drives me crazy that we're constantly swapping before sending across the network and then swapping again when it's received.

Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.

Armchair preaching? Who is this "we" in "we are to do anything"? Unless you're contributing to a replacement, your proclamation simply doesn't matter.

There are lots of people who do elaborate things in Excel. I'm sure they could learn Python, but they don't and won't. Instead of changing the people, consider that maybe what they want/need is something like Excel but more powerful.

Nim has become so good that no one else should develop languages as pet projects? If that's what you're saying (which is how I read it), it's a very obnoxious sentiment.

Yep, Clojure made some nice improvements (still 4 parens, however), but I just can't get excited about the JVM.

I happen to like Lisp (well, Scheme at least), but I think a better comparison would be:

    let a = 123, b = 456, c = 789;
    # more code

vs:

    (let ((a 123)
          (b 456)
          (c 789))
          ; more code
     )

In many cases outside of function calls, there are more parens.

I don't agree they are useless - they don't stop you from accessing nullptrs, but they do help manage the lifetimes of your dynamically created objects.

And I haven't seen anything indicating unique_ptr is to be deprecated - maybe you're thinking about auto_ptr.

You can easily ignore null by accident while using smart pointers:

    struct foo { int bar; };
    std::unique_ptr<foo> bug;
    bug->bar = 123;

How about the chip in any recent model iPad or iPhone?

How about on ARM? Is its branch prediction keeping pace? I'm curious because you can't JIT to native on iOS, so finding the best way to build a VM there is interesting.

"Generally these people bring cash"