Hacker News Reader

...and for that we have C++.

For me Go is a replacement for Java. It is my "workhorse language" for server applications and for writing stuff that other people have to deal with and understand. For this type of software Java and Go are fast enough. Go has the advantage of coming with a lighter cognitive load than Java because it isn't dominated by huge frameworks. Nor is the language itself complex. These are important reasons why we chose Go.

If I were in the gaming industry or writing software that depends on wringing every last bit of performance out of the CPU, C++ would probably be relevant for me.

If Go were to get C++ style templates it would greatly reduce the fitness for purpose due to the increased cognitive load and the likelihood that developers will resort to "cleverness". Keeping "cleverness" out of your code is of the utmost importance when developing code that people have to understand.

I very occasionally do write code where every instruction counts too. Mostly on embedded platforms. Even there C++ is a bit troublesome because it is so easy for people to make mistakes. I'm not terribly fond of C++ there, but I can tolerate it. (Mostly I prefer to use C for embedded development and I really wish languages like Rust would be more ready for prime-time in embedded development)

You might like this presentation on the Curiosity rover's computer that goes into the OS, code (C++), and system design. https://media.ccc.de/v/35c3-9783-the_mars_rover_on-board_com...

I disagree.

Yes, any approach to parametric polymorphism is going to make some tradeoffs, but the benefits of C++-like generics which you've enumerated (templates perform as fast as hand-instantiated types and the ability to have complex constraints) do not require you to simultaneously have the drawbacks which the C++-like generics have.

For example, ML-style parametric polymorphism has shown us that it is possible to mostly have our cake and eat it too for 90% of cases where you actually need to use generics; unfortunately only very recently (e.g. with Rust, even if its flavour of generics is still limited compared to what you can find in functional languages) ML-style polymorphism has actually appeared in a more mainstream language.

Well, ML doesn't have subtyping or C compatibility, so it's in a very different space. C++ had to deal with adding generics while also preserving all of the important other properties that make C++ C++. You can argue that those properties also aren't important, but they obviously are for C++ users.

I thought that most MLs did type erasure, like Java, instead of completely reified types, like C++. Although I know that F#, which is an ML that can reify types at runtime using the CLR JIT.

C++ sacrificed:

    -Fast, modular compilation
    -Straightforward error messages
    -Low cognitive overhead

That's precisely the wrong way to go on every count! That's a perfect example of designing for the machine, not for the humans! (I say this as someone who wrangles C++ in my day job.)

Do you truly think that no code should be optimized to run as quickly as possible over more human considerations? I think game engine developers might like to have a word with you...

Do you truly think that no code should be optimized to run as quickly as possible over more human considerations?

No. Of course not. It's mentally lazy to just push the lever all the way over to that side. By the same token, it's also mentally lazy to just push the lever all the way over to the other side. In some kind of design space over many variables, there are going to be some maxima.

A bit more general than making the common case fast, is making the common case fast enough, debuggable, and straightforward, with the option of making something faster when and where you need it.

I think game engine developers might like to have a word with you...

I would like to think so. I'm developing a cloud resident game engine for MMOs. (Just a hobby project, admittedly.)

All that said, those 3 decisions for C++ were 3 particularly egregious ones.

Besides pointing that typeclass based generics (Rust, Haskell) have all those pros and none of the cons, none of the gains you claim are inherently lost on Java-style generics either. It's just that Java has funny language limitations, that do not apply if you remove the incompatible requisites from the language.

generics in Haskell are done via type erasure, so they definitely do not perform nearly as well as c++ templates, especially for things like numerics. I don't know how rust implements parametric polymorphism to comment.

I'm pretty sure there are mechanisms you can use in Haskell to reduce boxing despite erased generics. Specialize pragmas, for instance.

> typeclass based generics (Rust, Haskell) have all those pros and none of the cons

My understanding is that typeclasses incur a runtime penalty on invocations since the typeclass essentially carries around its V-table with it at runtime.

> none of the gains you claim are inherently lost on Java-style generics either. It's just that Java has funny language limitations, that do not apply if you remove the incompatible requisites from the language.

I don't understand how the last sentence of that does not invalidate the first. If you remove those limitations, what you get is not Java and would lose many of the other benefits that being Java has.

In Rust, type classes do not have to carrry that overhead; when you use them as a trait bound, you get monomirphized code. When you use them as a trait object, you do carry the vtable around.

For other languages, you may be correct in all cases.

And it's worth mentioning that the "trait object" form of generics is relatively rare in Rust code; there's a fair amount of friction to using them that makes them somewhat of a beginner hurdle considering how easy they are to reach for (which the future `dyn` keyword intends to rectify).

Rust's generics don't have overhead and the error messages are at least as sane as Java's. I think the problem is with how C++ implemented its templates.

C++'s templates are more expressive than Rust's generics. Rust is adding stuff to try to catch up (specialization, const generics). You might see the extra power as an anti-feature, and that's fine, but it's undeniably useful to lots of folks and is undeniably a trade off.

But doesn't the fact that Rust is managing to add these features mean the lack thereof is not a limitation of classical parametric polymorphism?

Not that they're necessarily trivial to integrate, especially when the people working on it would rather try for the stars of genericity (e.g. dependent types versus const generics).

I would be surprised if Rust's type system winds up supporting everything C++ templates do. But maybe I'll be wrong, or the only things not covered will be niche and easily worked around. I don't know.

I feel like part of the reason that I don't run into issues with Rust having less expressive generics than C++ is that Rust has a ton of other useful meta-programming features; a lot of the crazy things I've seen solved by C++ templates can be solved in Rust via things like proc macros.

Just wondering if it's possible to implement something like expression template used in Eigen3 in Rust. C++'s template can be used in more than generics.

Sure, but those are different tradeoffs than those listed above. And some of the warts with C++ templates might not be inherent to supporting the features that C++ templates offer over Rust generics--for example, what features are enabled by error messages that point into the expansion of a template rather than a type error at the template itself?

They aren't different. The last bullet point in munificient's comment is a point about expressiveness.

I honestly don't know what point you're trying to make here. This really shouldn't be controversial.

Fair point, I missed the last bullet. To me, munificent's comment reads like a false dichotomy--you either have the Java's problems or C++'s problems. I was pointing out that there are other systems that largely have neither--namely that you can have template-based generics that perform better than Java and are friendlier than C++. He may well not have meant it that way, but that's the context for understanding my posts.

C++'s templates are more expressive than Rust's generics

80/20 rule applies here. 80% of the boilerplate can be eliminated with 20% of the expressiveness.

Yes. I agree. Some might even argue that this applies to Go itself: its builtin generics get you a lot without bringing in the full baggage of user-defined generics.

There's really nothing in my comment that suggests I think otherwise, so I'm a bit confused by your comment.

I'm expanding on your comment about trade-offs. I tend to like nuanced views of cost-benefit trade-offs in language design. It is a complicated subject, after all.

Yeah, but there are some limitations with Rust's generics around numeric types. You can't declare generics with arrays of a fixed size(which is really common in performance sensitive code) so there are trade-offs.

I understand that it's being worked on. I won't disagree that C++ templates are sharp, pointy tools but there are some things that they enable which you can't get in other languages.

Yeah, my point was not "Rust generics are strictly better than C++ templates in all cases", but rather that the GP made it sound like you have to choose between C++ templates and type erasure and Rust proves that's a false dichotomy. Sorry if I was confusing.

I think it's how C++ is compiled. Until recently, there was no way to forward declare templates and that required all sorts of hoop jumping or concessions to overcome.

Similarly, the existence of header files at all is probably an anti-feature.

> and the error messages are at least as sane as Java's.

Last time I made a mistake stringing Tokio promises together, the error messages were straight from the C++ hell.

What is it about "parametric types" that wreak such havoc on error messages being intuitive? Is is it just the levels of indirection involved? If so is this also the reason for the slower/modular compilation? Thanks.

With C++ in particular, it's because type-checking happens only after a template has been instantiated, so the error messages you get are based on the instantiated types and not the original template.

I apologize if this is a naive question but could or could have C++ used type erasure at run time similar to what Java does? Or is there some technical reason it's not feasible in the C++ run time?