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

C++26: Erroneous behaviour

sandordargo.com

Post reply on HN
Print view View original

11–20 of 103 posts

Re: C++26: Erroneous behaviour

#11

Post by kachapopopow »

mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

I just don't see a reason to use c++ anymore when rust does quite literally, everything better. For prototyping, hacking, firmware and native interfacing though? c++ any time of the day.

Re: C++26: Erroneous behaviour

#12

Post by anon-3988 »

mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

Based on Hyrum's Law (since they preserve backward compatibility), any line of "modern" C++ code is also basically just C code. There's no way around this. I don't think there will ever be a point where C++ is so safe and rigid that it feels comfortable to write in without thinking of the 100s different ways the languages screws you over.

They love to say C++ is for everyone but it is clearly not. Only wizards and nerds burdened by sunk cost fallacy is willingly writing these modern C++ code. I personally just use C++ as a "nicer" C.

Re: C++26: Erroneous behaviour

#13

Post by mcdeltat »

saghm wrote: post #9
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

> do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? This is an interesting perspective to me, because my view as someone who's been using Rust since close to 1.0 and hasn't done much more than dabbled in C++ over the years is basically the opposite. My (admittedly limited) understanding is that this has ne…

It's true that without backwards compatibility concerns, Rust looks like a great alternative.

However I think C++ still has some things going for it which may make it a useful option, assuming the core issues were fixed. C++ gives ultimate control over memory and low level things (think pointers, manual stack vs heap, inline assembly). It has good compatibility with C ABIs. It's very general purpose and permissive. And there are many programmers with C++ (or C) knowledge out there already.

Further, I think C++ started on its current feature path before Rust really got a big foothold. Consider C++ has been around a really long time, plenty long enough to fix core features.

Finally I reckon the whole backwards compatibility thing is a bit weird because if the code is so ancient and unchangable, why does it need the latest features? Like you desprately need implicit long-to-int conversion but also coroutines?? And for regular non-ancient code, we already try to avoid the problematic parts of C++, so fixing/removing/changing them wouldn't be so bad. IMO it's a far overdone obsession with backwards compatibility.

Of course without a significant overhaul to the language you'd probably say "screw it" and start from scratch with something nicer like Rust.

Re: C++26: Erroneous behaviour

#14

Post by dwattttt »

> with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game.

Unless they were incumbent and inertia keeps them in. Or they're the only choice you have for a niche target. Or you have some other reason to keep them, such as (thinking?) the performance they bring is more important.

Re: C++26: Erroneous behaviour

#15

Post by AnimalMuppet »

bluGill wrote: post #5
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

That doesn't matter - it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help. sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while…

60 million dollars a year in development for 15 years? What are you working on?

Re: C++26: Erroneous behaviour

#16

Post by webdevver »

C++26, C++29, C++32, ... C++50?

Surely all good things come to an end, but where? i reckon there will be a C++29. what about C++38? C++43 sounds terrifying. Mid-century C++? there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.

Re: C++26: Erroneous behaviour

#17

Post by goalieca »

AnimalMuppet wrote: post #15
bluGill wrote: post #5

Earlier quoted context omitted.

That doesn't matter - it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help. sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while…

60 million dollars a year in development for 15 years? What are you working on?

There are many large projects with ~1000 engineers will end up costing more than that.

Re: C++26: Erroneous behaviour

#18

Post by dwattttt »

quotemstr wrote: post #6
mcdeltat wrote: post #3

As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can contin…

> As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? Memory safety semantics aside (needed and will be disruptive, even if done gradually) --- You could get 80% of the way to ergonomic parity via a 1:1 re-syntaxing, just like Reason (new syntax for O…

It's an interesting proposal. A new grammar which can express everything (legal) that C++ can, can be automatically translated, but can avoid being ambiguous (https://stackoverflow.com/a/794083).

You'd have an existing language with a new syntax; it can perfectly interact with existing C++ code, but you could make those suggested changes, and could also express things in the new syntax that couldn't be done in the old one.

EDIT: taking an example elsewhere in this thread; taking an address of an uninitialised variable and passing it to a function. Today the compiler can't (without inter-procedure analysis) tell whether this is a use of uninitialised data, or whether it's only going to write/initialise the variable.

A new syntax could allow you to express that distinction.

Re: C++26: Erroneous behaviour

#19

Post by paulddraper »

AnimalMuppet wrote: post #15
bluGill wrote: post #5

Earlier quoted context omitted.

That doesn't matter - it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help. sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while…

60 million dollars a year in development for 15 years? What are you working on?

Chrome doesn’t fit those figures exactly but is close.

Re: C++26: Erroneous behaviour

#20

Post by foobar10000 »

AnimalMuppet wrote: post #15
bluGill wrote: post #5

Earlier quoted context omitted.

That doesn't matter - it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help. sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while…

60 million dollars a year in development for 15 years? What are you working on?

Many large financial operations - HFT such as Hudson River Trading or Optiver or IMC or Citadel, or the big C++ systems in the banks - 200-400 developers working on an ecosystem of components can easily clear that.
Post reply on HN