Hacker News Reader

Comment by spyremeown | Hacker News Reader

C++ has already got to a point the teams inside my company can't even talk between themselves properly (it's R&D and very heterogeneous, so not that bad) but this doesn't happen with any other language. It's ridiculous.

The newcomers struggle so much to learn the language, and tbh I just say to them to learn the sane 5% of the language and ignore the rest. It's a monstrosity, extremely hard to bring up and generally not nice to read nor write.

I really wish a good, well-maintained, modern (as in, actually break stupid compatibility, just fuck it. It's 2021 for God sakes) C++ existed.

View on HN

> I really wish a good, well-maintained, modern (as in, actually break stupid compatibility, just fuck it. It's 2021 for God sakes) C++ existed.

As a C++ programmer I would say this language is Ada 2012 (see https://pyjarrett.github.io/programming-with-ada/four-months...). It's hard to get people past the initial shock of the Pascal family syntax, but once you do, you'll find it ludicrously close feature-wise to the base C++ feature set that gets used day-to-day (RAII, templates, etc.) but with a Pascal skin. It also comes with built-in concurrency.

> Pascal family syntax

I have fantasies of doing a "new" programming language which is literally a lexical translation of Ada into curly-brace syntax and calling it Curla. I wonder if anyone would notice that it was just Ada!

This has already been done (http://www.adapplang.com/index.html).

Which is actually an April Fool's Joke. They only bothered to replace begin/end with {/} and is with :. Which results in delightfully asymmetric examples like with case:

  case Foo:
    when Bar => ...
  }

The also eliminated the need to both with and use if you use a package (the only positive change suggested on that site), and added some abbreviations like pkg and priv.

>It's hard to get people past the initial shock of the Pascal family syntax

What's so shocking about Pascal?

People throw their hands up because there's `begin...end` instead of curly braces.

If it was just that small difference, I would have picked up C decades ago, instead of despising it. There are all the .h files fractured off randomly from the source files, littering the landscape, the make system which never quite seems to work, the abuse of case sensitivity as a feature, the stupidity of uncounted strings ending with (maybe) a null, the abuses of macros which make things unreadable, then the pointers that are never quite explicit... char * or char, it never, ever* made sense to me. In Pascal, it's simple... @x is the address of X, x^ is what X points to. In pascal, you pass the value of an argument by default, or optionally you can pass it by reference, and the syntax doesn't change, and you don't have to play with the footgun that is pointers.

But sure, using the reserved words BEGIN and END at the bounds of a block of code break people's brains ;-)

I don't think it's a matter of shock, as so much people parroting the manufactured corporate resistance to Pascal that sneakily came from AT&T (birth place of C, C++, and Unix). Being "anti Pascal" or feeling its syntax is "alien" was something embedded into the C family language culture. To the extent some people act like their brain might explode if they can't have a language with curly braces or that any new language should go that direction.

I thought Rust was that better C++. It doesn't help existing large projects because nobody will ever rewrite them. However, if you're starting a C++ project in 2021 and have the option of using Rust, you might want to think twice.

There certainly are C++ programmers who express this sentiment. e.g. https://www.thecodedmessage.com/posts/hello-rust/

On the other hand, if the thing you don't like about C++ is that it keeps changing you may be unsatisfied in Rust too because Rust has in some ways an even faster pace of changes. Rust as it was written in 2015 still compiles on a modern Rust compiler (with edition set to "2015" and modulo any security issues) but it is no longer idiomatic Rust.

I think the OP is not complaining about change. Arguably, change is inevitable. He seems to dislike trying to keep backwards compatibility at the cost of sanity and usability, and the fact that C++ is an ever-growing pile of features that doesn't make sense anymore.

This is precisely what the Rust edition are there to solve: your legacy code will work but the language will change with each edition to reflect the state of the art, and if needed, it will break backwards compatibility.

> modulo any security issues

I'm not sure there are any security issues associated with using an older edition. I think when soundness holes and other things like that are fixed, they're usually fixed across all editions. Sometimes that's technically a backwards-incompatible change/fix, but Rust's back compat policy considers that acceptable if the breakage isn't widespread.

> Rust as it was written in 2015 still compiles on a modern Rust compiler... but it is no longer idiomatic Rust.

The changes since the 2015 edition have all been relatively minor in terms of idiomatic code I think. I mean sure, you can use the '?' operator instead doing a manual match and return, but most of the changes have just been making the compiler more permissive in terms of what it accepts.

The only new concept to be learnt would be async-await, and that should be familiar to most from other languages and only applies if you're doing IO.

Today an idiomatic function that twiddles some foozles has a signature like this in Rust:

fn twiddle(foozles: impl IntoIterator<Item=Foozle>)

But in 2015 you couldn't have written that. It works in the 2015 edition today, sure enough, but it would not have worked in any 2015 Rust compiler, and so it was not idiomatic Rust in 2015.

Instead in 2015 you'd have either chosen to specify what sort of container the Foozles live in, or, if you believe freedom to choose different containers is important to your users, you have to ask the caller to Box up an Iterator over their Foozles so you don't need to care what container they used.

so e.g.

fn twiddle(foozles: Vec<Foozle>) // Hope your foozles are in a Vector or else you'll need to write an adaptor function

fn twiddle(foozles: Box<Iterator<Item=Foozle>>) // Now we're incurring a heap allocation

For what it's worth, I suspect most Rust programmers would consider twiddle(foozles: &[Foozle]) to be the most idiomatic option for general use both in 2015 and today.

Mmm, but not everything we might iterate is actually eligible to be a slice.

In 2015 Rust you could write:

    fn twiddle<T: Foozle, IterT: IntoIterator<Item=T>>(foozles: IterT)

which I believe would still be considered idiomatic today. (this assumes that Foozle is a trait. If Foozle is a struct then you can simplify this). You can also now use the impl syntax you posted but it's just sugar and it's less flexible than the older method.

That's how I used to write it in 2018, before I discovered the `impl` keyword. It's the obvious way of doing it. (Though I'd've used `Iterator` rather than `IntoIterator` because I came from Python. (Yes, I know `IntoIterator` is the version best matching Python's behaviour.))

Note that impl is not exactly equivalent. If the type passed in is ambiguous, with an explicit template the caller can disambiguate, but with impl there's no template argument.

So sometimes you still want to use the "old" syntax in your public APIs, even when you could be using an impl trait

    fn twiddle<I>(foozles: I)
    where
      I: Iterator<Item=Foozle>

(or probably IntoIterator<Item=Foozle>). `impl T` is (modulo some details I don't remember right now) just syntactic sugar for this.

The only thing new in Rust 2018 is the impl Trait in argument position.

Generics and trait bounds are in the language from the start.

So you can write this function like this:

  fn twiddle<T: IntoIterator<Item = Foozle>>(foozles: T)

Which is 100% idiomatic today and is even preferred by some people over using impl Trait

impl Trait as the return type actually added quite a bit more than in argument position. In particular, it allows you to return a lambda without boxing since you cannot get the exact return type of a lambda (at least not yet). impl return types are sort of a special case of existential typing.

While I agree that Rust changed a lot, it was mostly fixing edge cases (like borrow checker limitations or associated types not being allowed to have generics) or obvious missing features in the language (const fn, const generics, async await) that have been known for a long time. Most of these have been implemented since then (at least in MVP form) to the point where there's barely any new ideas anymore and most old ones got implemented. So Rust really feels like it's nearing a "point of completion". You can see this with the Rust 2021 edition as well that contained very few changes.

Rust is C++ for OCaml developers.

Rust is a better C++. The problem is that it's a better C++, i.e. it seems to be following the same path (only faster). If in ten to fifteen years Rust will be in the same position (only with a smaller market-share) it isn't attractive enough to pay the high migration cost.

What's missing from Rust? Or what is in it that will become a problem later?

It's probably the same as that which was missing from C++ in, say, 1990 -- the needs (and fashions) of tomorrow. But it's not specifically Rust. All languages are built for the needs of their time, and then have to adapt and change as requirements and fashions change. The question is, how do they adapt? That's defined by the language's ethos. C, C++, Java, Python, and C# have all survived and adapted for some time, but they've had somewhat different adaptation approaches. Over time, their domain also shifted (in fact, contracted compared to its peak; Python is exceptional, perhaps, in that it's peak domain wasn't its initial domain).

Two limitations with the type system currently are a lack of existential types as well as a lack of GADTs (general algebraic data types). Existential types would make it easier to work with unboxed lambdas when implementing a trait (since then you would be able to use type of the lambda for things like associated data types).

GADTs are useful for extremely generic code and are required if you want to write a general Monad trait. There is currently no way to write a trait which says return Self, but with a different generic argument. And not just Self, any associated type on a trait is a single type so you can't have a requirement for an associated type to be generic.

Finally, the procedural macro system is kind of a mess at the moment. Last time I checked, you really couldn't write a hygienic procedural macro (though I think this can be added later on without. A bigger limitation is that you don't really have any way to access type information in a procedural macro. Obviously type information is only available after parsing unless you make the macro system in Rust way more complicated, but it would be nice to have static type info for other modules. Having this information would allow you to do stuff like generating serialization code for some library that you don't control.

> tbh I just say to them to learn the sane 5% of the language and ignore the rest

I thought I knew C++ well enough to get by. But in my current company, there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features. Basically, it seems they use all single features available.

And it seems some people love this mess.

And you can't really have a sane conversation with these guys either. I've never met a more arrogant programming community than the c++.

I wanted to learn more low level programming when I was a C# dev, and coming from an OOP background, I chose C++ (also I had encountered c++ in school as a first language) . Man, was it humiliating asking questions even on stack overflow. Apparently everything is obvious and I'm an idiot.

In any case, I dropped C++ (not because of the obnoxious community but the language felt so poorly designed, coming from C#) and turned to C. Its been so far an amazing experience learning from C community. They are deeply insightful about computers and genuinely willing to help new engineers. Very experienced and very high calibre c engineers were helping me out without trying to show off how much smarter they are than the rest of the world despite being clearly far better and smarter than I am.

There are a lot of hardware engineers at my company that more or less occasionally use Python or C# to get their job done. I understand that those languages are the better choice for them and gladly help them with getting C bindings done for the odd library in our industry, and to understand some low level concepts such as CPU cache when they run into problems due to those.

I turned away from the C++ unity towards the Rust community because I saw the same issue as you, and am very happy about that decision.

It is somehow ironic to read this, given the heat given to newcomers on comp.lang.c and even the moderated one on Usenet.

I'm sorry, but using stackoverflow as a proxy for any "community" is giving that s(h)ite too much credit. It is infected with arrogant assholes regardless of the field.

(I guess I'm old and misanthropic but I would not seek out answers by asking on the internet, but instead by reading one of the many excellent books on C++. It's not some obscure hobby where you need the collective wisdom of old hands.)

Now, I've been doing C++ for 20+ years, and the only real way to get help/mentorship in my experience is people you work with. There are too many ways to do any given thing in C++ and what you want is to follow the coding practices of the team.

So, your answer to somebody that found it difficult to get help from the c++ community is to first admit your are a misanthrope then direct the other guy to: go read some books and learn it for yourself!

Kind of proving the other persons point for them...

Read what I said:

1. stackoverflow is a bad "community" for any field.

2. I described how I would approach learning C++, based on my personality. I didn't "direct" anyone to do anything. Especially since I phrased it as a literal parenthetical.

Well said.

One thing i have noticed is that many people trying to learn C++ (or any other language for that matter) don't even do the basic homework (eg. read a book) before asking questions. They expect everything to be spoon-fed and to "easily" understand it all. Even a little effort is too much. They simply lack the commitment and persistence to learn anything non-trivial.

>there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features

I don't mind using the latest features, there are some really nice things like iterators, compile time expressions and so on. I just don't want it to be hard to read or understand (like you said, using ALL the latest features).

So a good rule of thumb for me has been "if I give this to a newcomer, will he be able to infer what this is doing?". If yes, it's generally "safe" to use it.

In my early 20's I got the appeal of that I think. I wrote a lot of C++, learned all the (then) new features and design patterns. I had a bunch of C++ books covering various advanced topics. I felt like a rockstar implementing ultra-sophisticated generic libraries.

I think I remember what the breaking point was for me. I had a custom serialization format (something YAML-like, because of course I had to implement my own custom format) and I wanted to pretty print it. I needed to implement some kind of indentation routine, you know, add a number of spaces at the start of a line depending on the current nesting level.

I wrote an indentation class that was fully generic. As in, the whole concept of indentation was abstracted away, I wasn't dealing with line buffers and characters, I had generic streams of objects and everything was templated and Boosted to the max. Must have taken about 20minutes to compile on the CPUs of that time. I was proud of my mad cpp skillz too.

And then the absurdity of it struck me. Over the next few years I found myself returning to the simplicity of C more and more (not that I would recommend C as a replacement for C++ in the general case, mind you).

Often when I read C++ discussions these days I think I detect the same kind of hubris I used to experience. Just writing ultra-complicated code for the sake of some perverted notion of purity and elegance.

So when you mix that mindset with the "and the kitchen sink too" ethos of the C++ language committee, you end up with the unmaintainable monstrosity that's modern C++.

I believe that deep, down its a question of identity and incentives. The right thing to do is reduce complexity.

But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated.

And then there is the question of what gives you joy? I find that for most coders, their primary motivation is not to solve a customer problem in the quickest, simplest and most efficient way, but to challenge themselves with riddles and learn new tech and follow fashion. This definitely varies by culture - Golang and Haskell are on opposite ends in that spectrum.

Overcoming delusion means to exit one's own mind and observe the real world. Looking at useful and well-made software, in which language is it implemented in? A Haskell fan will have no trouble talking for hours about how its concepts are superior. But he will not notice that there is barely any popular software written in Haskell out there, and he will not understand what that implies.

You hit the nail on the head I think. A few years into my career I was enamored by learning new programming languages, in particular functional ones. I was fully drinking the koolaid, too - pure functions and immutability would surely make writing web crud a blissful experience, right?

At some point I realized that the nice examples from the books never mapped to the real world as cleanly. Exceptions were pretty useful, local mutability made lots of things easier, and category theory has no place in calling JSON apis over http.

I think a great number of talented programmers never learn that lesson, and continue futzing about with theoretical purity for its own sake.

On the other hand there is value in learning different languages and concepts, and possibly applying them in your day to day job if it makes sense. It makes you a better programmer. But one is a means to an end, and the other is... I don't know, a philosophy? L'art pour l'art?

"But the thing that optimizes for nerd status and job security and resume building is to increase complexity, because most people cannot appreciate the sophistication of simplicity in some technological niche, and it is not easily communicated."

I think you're on to something there, except for the "job security" part. I've met very few people in tech who are concerned about losing their jobs, and fewer of them would make things much more complex---they didn't have the skills.

In fact, most of the majority I have known who produced complexity were optimizing for nerd status and resume building, but would quit rather than maintain their own complex code.

you can limit your code to a subset of c++, make it like a c with free ctor/dtor and simple classes, then it's not that complex.

I find myself largely agreeing with you about the hubris and complexity behind most c++14/17/20 discussions today. and often feel adding complexity for the sake of intellectual satisfaction is pointless and should be avoided.

My view is that we mostly read code a lot more than write it and code is basically the low level fabric on with we build higher level abstractions like business logic (except for some ultra specialized cases like shaders or vector assembly). My problem is that any senior engineer shouldn't have to waste brain cycles figuring out the language antics when reading code because that takes you away from the reality you really want to get to (the business logic or the intent of code). for a reasonbly senor coder the language really should be out of teh pecture. these antics often end up wasting attention and sometime resources because likely somebody would use that code in a way its not intended and it will have a subtle failure like using extra resources etc

PS: apologies for misspells in above para, was hoping to make a point.

You just described me in my 20s as well. I used to revel in my knowledge of C++ minutiae and being able to quote parts of the standard and recognize obscure undefined behavior.

Then I started a company and hired people to work with me and it hit me just how much of an absolute waste of time it is to know that stuff. It doesn't translate or generalize well, most C++ is a special kind of complexity that is only relevant to C++, and then when you hire people you can actually assign a dollar cost to the complexity and that cost is simply not worth it.

I still use C++ at my company, but I now use a very simple and straight forward subset of it, basically along the lines of C with classes and namespaces. No more boost, no more elaborate SFINAE, no more writing things to be so generic and obtuse and avoiding parts of the language that are too abstract.

In that vein I also avoid all of the mess introduced by C++20. Concepts were a missed opportunity, modules are beyond useless, and the fact that C++20 has both coroutines and ranges just shows how the language is designed in a Frankenstein manner. A good solution for coroutines would make the use of ranges unnecessary, and a good solution for ranges would make coroutines unnecessary.

Instead C++20 provides half-assed implementations of both.

I think this kind of philosophy is what ended up driving Go's simplicity.

Less infatuation with the tool, more focus on shipping maintainable code the first time.

> But in my current company, there's no way you can do anything in the C++ codebase without a serious understanding of the language latest features.

I feel your anecdotal example is not fair as you're trying to pass off problems created by your team with it's ill-advised approach to adopting a programming language's latest features as problems with said programing language.

For instance, I feel you could make precisely the same case with a Java or Python project if the project's coding guidelines forced the adoption of all the new bells and whistles. But that wouldn't mean the languages have a problem.

Meanwhile, the golden rule of C++ continues to be favouring the principle of least surprise and picking a language version (often C++11, and not C++14/17/20) and a subset of features to be enforced at the project's coding guidelines, and build your project around those.

Frankly, your anecdotal example sounds more like resume-driven development claiming yet another victim than a programming language being too unwielding.

I agree I was a bit unfair, in the sense that it's not a problem specific to C++. It's extremely tempting for developers to use all tools and features available to them, and without very strong guidelines, you can be sure that it will happen.

That being said, C++ is an extremely complex language, so there's much more room for the code to become insanely complex than in more modern languages.

just wanted to say that I have seen this happen in my current company and so much so that certain portions of code basically look like boost headers. many folks dont want to touch that code so they end up duplicating functionality with slight change because that one minor change would take a life of itself.

in my previous company I have seen this happen (to a less extent) as a way of marking territory since such speghetti code sans detailed documentation basically means nobody else will touch it.

> Basically, it seems they use all single features available.

And nobody is worried that the compiler implementations are not battle-tested and/or fully optimized yet? Because that alone would scare me off of using the newest features in production.

They're not using all the features for rational reasons in the first place! It's a rat race, plane and simple.

For me I got the hints of something might go wrong with STL seeing more and more use, and then boost, various pointer types.. and it kept piling on. I'd say as soon as template metaprogramming became mainstream, in a language where it looked like a tumor, that was the end of it for me personally. It was not a language I knew anymore, nor cared about. C is a bit more verbose but concise enough to get around (if there's no abuse of pre-processor). With Rust, jury is still out there.

Yes. The explosion of meta programming in C++ was what killed my interest in that language. Too many layers of worthless abstraction that looked like they could have been written by an APL programmer having a seizure.

The Dave Abrahams comment in the questions here:

https://www.youtube.com/watch?v=raB_289NxBk

"We got a lot of mileage in Swift, saying no to things"

and

"You're not going to get to a simpler language by adding features".

I've taken two comments (I don't feel that they're out of context), and they're 100% correct. As is your comment about learning the 5% part.

> I really wish a good, well-maintained, modern (as in, actually break stupid compatibility, just fuck it. It's 2021 for God sakes) C++ existed.

I often joke to my colleagues and say that C++42 will be equal to D today, or in fact D from 5 years ago.

Isn't Swift considered to be one of the more complex languages?

https://www.quora.com/Which-features-overcomplicate-Swift-Wh...

It depends what you're comparing it to. If you look at every computer language, then perhaps, but C++ is still leagues ahead in complexity.

Swift is indeed a complex language, although relatively simple when compared against C++20.

I also liked his take on safety.

I haven't coded in either¹, but I got the impression that Rust tries to supersede C++, and that Zig tries to supersede C, and that they're both slowly getting there. Is that a bad oversimplification?

¹ nor seriously coded in C++ in a long time, for that matter, so take this statement as an outsider impression

Not sure about Zig, but Rust is a pretty successful replacement for C++ by and for all the people who want low-level efficiency of C/C++ but with safety guarantees and reasonable semantics that can be understood without long and painful training.

I really want to take a good look at Rust... it does seem to have very reasonable syntax and cargo looks nice.

The bigger sell to me is that you can actually give safe rust code to a newcomer, and they won’t cut themselves on the most basic of tasks. Code review and work delegation have become soooo much easier for me as software dev lead.

It is a successful language, a successful C++ replacement remains to be seen, as per companies whose SDKs favour only C, C++ and their managed stacks.

Do people really think Rust isn't a replacement for C? For the work I do - optimisation algorithms that must run As Fast As Possible - it absolutely is a much-superior replacement for C.

I think what people mean is that Rust violates their perception of what C 'is' - 'simple, bare-metal, low-abstraction'. Well I don't think C is any of these things and Rust's memory model (borrow-checker) is a much more explicit and precise representation of the actual (implicit, undocumented) invariants of your C program. In that sense it is 'simpler'.

To reword what you are saying in a slightly less dismissive tone: there are a lot people who stick to C because they don't like the added complexity of C++ (real or perceived). The same people are likely to look at Rust and perceive a lot of added complexity on their first impression, while also already feeling comfortable with C's complexity. With that combination switching over becomes a hard sell.

Meanwhile Zig has a lot less perceived complexity, and most of it appears to be similar enough to the "C complexity" that C programmers are already familiar to not scare them off.

(Again, I'm just giving outsider impression of someone who just read a ton of blog posts and basic tutorials + standard library stuff without really coding in either language)

They can even do use-after-free errors just like in C.

Oh sure, but how many people who choose to be C programmers do you know who would be scared off by that? That's exactly what "familiar complexity" is about: people being comfortable with and not worrying about things that they're used to, even though they maybe should feel uncomfortable and worry a bit.

Many people that choose to be C programmers think they can manage it, until their code runs under SonarQube or similar tools.

It is like handling butcher knifes without metal gloves, they think they are worthless until they repent not wearing them.

I think this is definitely a reasonable take. Having said that, Rust is not quite as complex as C++ so a lot of people who have rejected C++ are more open to Rust (the linux kernel being a prominent example).

> Rust is not quite as complex as C++

Yet. C++ wasn't as complex as C++ back when it was Rust's age. It wasn't even as complex as Rust. But if you pick a language for the next 20-30 years, you don't just care about where it is now, but also about where it is headed.

If you get things right first time, you don't need to add as much complexity on the journey to ship something usable.

This is obviously easier coming from behind. You simply don't have to (and shouldn't) repeat other people's mistakes.

> It wasn't even as complex as Rust

I'm particularly dubious about this claim. Even counting from the genesis of C++ rather than standardisation, yet counting Rust as starting only in 2015, C++ after six years not only has multiple inheritance and overloading of everything, it also already has templates. That's a lot of complexity.

> If you get things right first time, you don't need to add as much complexity on the journey to ship something usable.

There's no such thing as "getting things right the first time," because what's right depends on external, mutable, factors. The best anyone can do -- and most successful languages achieve -- is being well adapted to the environment. But the environment changes. For example, Java's object model was well adapted to an environment where memory access and computation were of roughly similar speed, but hardware changed so that computation is now faster than memory access, so Java is now changing to adapt to the current environment. On the other hand, its bet that memory is cheaper than computation has so far proven relatively long-lasting. But there's no telling what needs new hardware architectures or new software requirements will bring tomorrow.

Both Java and C have adapted better, in my opinion, than C++, and it's not because of specific features, but because of their evolution ethos, which is different not only from C++'s but also from each other. My personal opinion is that C++ has tried for too long to be both high and low level, and that has shaped its particular evolution. I feel that Rust is repeating that same fundamental mistake, but, of course, others may disagree.

I don't agree that it's somehow impossible to get things right and I'm not even sure you really believe that.

Take "explicit". In hindsight I suspect even many C++ proponents would agree that actually you don't want C++ conversion behaviour (when calling a function that takes a parameter of type X and you've provided a parameter of type Y, the C++ compiler will look for any way to construct an X that only needs a Y and then call that constructor rather than report that you've got the wrong type) by default. Perhaps C++ should have implicit conversion you can opt into, but it certainly should not have (as it does today) implicit conversion you must know about and opt out of to avoid blowing your feet off by mistake.

But I argue that it goes much further than such superficial mistakes. Multiple inheritance is a mistake. Personally I'm sold on the theory that all type inheritance is a mistake full stop (heritability should be a property only of interfaces), lots of people don't agree, but far fewer support the choice C++ made to embrace multiple inheritance of types. It's just so rarely even useful let alone the best option to solve a problem.

> I don't agree that it's somehow impossible to get things right and I'm not even sure you really believe that.

That depends what you mean by "things." Obviously, languages created in 2015 might fix mistakes made in 1985, and recognised as mistakes, in, say, 1995. But the things that a language needs to solve over its lifetime are mostly unknown when it's created. How the language handles the problems that are known when it's created is less interesting. If it doesn't do it well, it will never become popular. What's interesting is how it adapts when those problems change with time and new ones appear.

If you're really, really good at C, you'll have realized that Rust doesn't add much to what you need to do. You're already doing what Rust does, you're just doing it manually without compiler support. Rust didn't create the issues associated with borrowing things, it merely surfaced them. They're always there, in any language you use, and since C is so manual, you better have figured that out if you plan on using it at a high level. I write mostly in Go, but I'm constantly tracking "ownership" issues in my language despite not having a "borrow checker", because the borrow checker doesn't create the issue.

Plus if you're using C at a high level you ought to be using a static analyzer anyhow, that may not impose the exact same restrictions on you as Rust, but should be imposing enough discipline on you that using Rust doesn't seem so foreign.

Rust is, or was, explicitly a replacement for C++, and many of its features, including the borrow checker, are more supporting C++ generics/STL collections "done right".

I think Rust has an ambition to supersede C++ but in its current form it has only superseded C. C++ is still a significantly more expressive than Rust, which limits the ability of Rust to replace it.

There's some attempts to keep C++ stuff restrained done to a sane level, for example Orthodox C++ https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b. I suggest that you stick to them.

And for everyone who feels they have to incorporate the newest features of modern C++, don't. Avoid modern fetishism and make decisions based off things that have survived the Lindy effect.

It does exist. It's your regular C++17 with Google Style on top (though perhaps with exceptions allowed), ruthlessly enforced through reviews. For larger teams to talk to each other use Protocol Buffers and GRPC to decouple interfaces. For build use Bazel. For utility code use Abseil. Do not use Boost for anything. For editing, set up Vim/Nvim + YouCompleteMe.

With this setup I find C++ pretty easy to work in. And I've built a team of ~50 devs that were productive on the same multiplatform C++ codebase (+ all sorts of language bindings).

My only gripe with gRPC is that there is no way to integrate it into a foreign event loop. I'm a big fan of single threaded event driven architecture ( I mostly do embedded work)

That is by far not the only gripe I have with gRPC, but yeah, it's not designed for embedded. It's too large and too full featured for that. Maybe there's a cut down variant somewhere though, it is an open standard, it is conceivable that someone could implement a portion of its features compactly. For instance for Protocol Buffers there's c-only nanopb.

What happens when you have to use something that isn't on your list? Do you fire people who don't like Vim?

They can figure out how to set up VSCode or CLion. Wrt everything else - tough luck. OP asked for usable subset, I gave them the usable subset, battle tested for 15 years on a multimillion LOC, codebase, quite possibly the largest and most impressive in the world.

I think the nice language is in there, but it’s buried within the backwards compatibility as you mentioned.

I’ve started putting together https://cppbyexample.com as a way for newcomers to learn because pointing them to a reference or outdated examples isn’t helping anyone.

> C++ has already got to a point the teams inside my company can't even talk between themselves properly (it's R&D and very heterogeneous, so not that bad) but this doesn't happen with any other language. It's ridiculous.

Yeah, that's totally true. But I would also say that a lot of it in my experience is people not even trying to keep up with the standards and barely even writing C++11 style code. I wouldn't expect to go into a Python shop (my other language) and work with people who hadn't tried to keep up with that language for 10 years but many C++ devs seem to have that attitude.

Have you looked at Nim? Simple like Python, but generates optimised machine code. It is also statically typed, unlike Python.

D tried, but somehow failed.

D suffered from too many options, multiple standard libraries and indecision between GC and manual memory management.

> D suffered from [...] indecision between GC and manual memory management.

It is still suffering from that. If you want to manage memory yourself you can't use some parts of the standard library + you can't use a lot of the community packages since they assume there is a GC present.

So far it looks like the best alternative is Zig, but sadly it doesn't have some of the higher-level language features such as function overloading, compile-time interfaces (Rust traits) or macros. Jai seems to have most D features and more without the GC [0] but Zig is more likely win popular mindshare since it already is in the open + comes with a C/C++ compiler which is pretty cool.

[0] https://github.com/Jai-Community/Jai-Community-Library/wiki

Exciting. The tutorial says download the compiler, somehow cannot find it, do you have a link?

Jai isn't available to public, sadly. That's why I said Zig is "already in the open". Jai has been in private beta since early 2020 and there are about 150 people that have access to the compiler beta AFAIK.

The reason for the language not being available is that the designer (Jonathan Blow) doesn't want to release something half-baked to the world (because "there is already so much garbage software out in the world", or some line of reasoning similar to that). I don't agree with his reasoning, but I understand it TBH. He also has the reputation of taking too long to develop his games, but when they're finally released they're pretty good.

Anyway, it doesn't look like it'll be released to the public soon so like I said, Zig is the best alternative right now -- and it's gaining more and more users, so when Jai finally gets released, Zig might have already won.

Jai and Zig are my next two bets (after exploring some Nim and concluding that it needs more time to develop), but Jai has made design decisions that are much more appealing to gamedev, and Zig seems less pragmatic in this regard. Both seem to be promising languages in general, I'm only comparing them from a perspective of a specific domain of programming.

- Zig doesn't have operator overloading while Jai does. Maybe a minor nitpick compared to the other ones, but this is a must-have for any math-heavy code, even crufty Orthodox C++ practicioners seem to use it.

- Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow.

- Jai's compile time evaluation is far more powerful - it can access the disk/internet and call any libraries. This is probably a horror show for any webdevs who like to do "npm install" without any thought, but in the case of gamedev where you have precise control over your dependencies this gives a much more higher degree of freedom. (For example, with this I imagine not only Jai code replacing all your build system scripts, but also asset management, packaging, localization, and publishing as well.) Jai's compile time evaluation also runs in a custom made bytecode-interpreter, which is probably going to be way faster than interpreting raw LLVM IR (which is what I think Zig's implementation is doing)

- Jai's support for switching allocators on the fly seems a bit less elegant than Zig's approach, but for actual usage I imagine it will be a lot ergonomic to use.

As you have said, you can't dismiss the community traction of Zig. But for me the most important thing will be: which language will actually ship a (reasonably sized) commercial game first. In that regard, as Jai's release will coincide with the Sokoban game that Blow's making it with, I think Jai will be the next language I try after C++ (well, if it releases though...)

> Jai's dev team is also developing a compiler backend that is much faster than LLVM

I suppose you mean compile time when you say "faster". But LLVM also gives you many backend CPU (and even GPU) targets out of the box. Rolling your own backend probably means x86 and maybe ARM. Lots of work targeting new architectures that is saved by going with LLVM.

The custom compiler backend is only intended to use for development, so limiting it to x86 makes sense (well, unless you are planning to develop with one of the new M1 Macs…)

For actual deployment (release builds for various architectures), the LLVM compiler can be used for Jai.

> Zig doesn't have operator overloading

Zig, by design, doesn't have overloading of any name, period (which also includes operators).

Sure, but I also proposed an equivalent way to get "custom operators without overloading" (lexical scope-namespacing in @ functions with a special parser rule for certain infix binary forms that do not conflict with builtin operators) and this, too, was rejected.

> - Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow.

So is Zig. In fact Zig might be even more aggressive about this - they chose to aim for an in-place binary patching approach explicitly for the purpose of fast rebuilds and simplifying live-reloading.

Oh, you’re right, my bad. If Zig achieves this then it will be a boon to all gamedevs using the language.

I much more happy using D that I have ever been using C++. It is a perfect replacement, with none of the issues mentionned in GP comment.

D isn't a replacement for C++ anymore than Go is. If you like it that's fantastic, but it's targeting a fairly different intersection of tradeoffs.

Have you used both?

That's what code standards are for, so you're all writing code that everyone can understand. Seems like a failure of the tech managers

Reply on news.ycombinator.com