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

91–100 of 103 posts

Re: C++26: Erroneous behaviour

#91

Post by tialaramex »

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…

There's an evolutionary process at work, so it's not really about that rewrite decision, it arguably made sense fifteen years ago to pick C++ - yeah C++ will still exist in say 2040 just like COBOL still exists today and I don't trust anybody arguing otherwise. But whether investing in C++ still makes sense is a different question. That might influence career decisions, and what new projects should do even though a choice fifteen years ago was correct, and it also impacts how to manage your existing project.

We do these night walks out in the Forest. 2-4 hours in the countryside, when it's still pleasantly warm but no sun. Owls, bats, insects and occasionally horses or deer that were not expecting humans - no sudden moves because horses or deer can easily kill you by mistake if startled. Without much light it's hard to be sure whether you're on a trail and if you've reached the fork you expected or just a place where there's a tree in the way.

So, it's not rare to realise we've made a mistake. Now, if you realise after 5 minutes you can "just" backtrack. It's nowhere near as easy in darkness, but it's possible and arguably preferable. However it is also possible to realise after say an hour. You thought you'd be in a clearing, on a ridge, but you're a mile away approaching a river crossing. Oops. It is usually not correct to retrace your steps in this case, you need a new plan taking into account what you know now about your position.

Re: C++26: Erroneous behaviour

#92

Post by kachapopopow »

halfcat wrote: post #87
kachapopopow wrote: post #49

Earlier quoted context omitted.

gpu-rs (hopefully) will do it better including all the sub-projects around it.

> rust does quite literally, everything better > (hopefully) will do it better So, not quite literally everything

work in progress, relatively new language.

Re: C++26: Erroneous behaviour

#93

Post by aw1621107 »

tempodox wrote: post #64
Kranar wrote: post #32

Earlier quoted context omitted.

There is a version of C++ that adds complete memory safety to the language by adding features to the language in a way that preserves complete backwards compatibility with existing C++ source code. That version of C++ is called Circle/Safe C++, it represents a monumental amount of effort that was written by a single individual, and it's a complete disgrace that the C++ committee has informally shut the door on that i…

There is even a reference implementation, so it could be added to existing compilers? That would at the very least be better than what we have now.

> There is even a reference implementation, so it could be added to existing compilers?

I don't think it would be that straightforwards since this is one of those changes which depends pretty heavily on compiler internals, unlike library-only reference implementations. It'd be like taking a reference implementation in Clang and "adding it" to GCC/MSVC.

Re: C++26: Erroneous behaviour

#94

Post by jibal »

kachapopopow wrote: post #92
halfcat wrote: post #87

Earlier quoted context omitted.

> rust does quite literally, everything better > (hopefully) will do it better So, not quite literally everything

work in progress, relatively new language.

"rust does quite literally, everything better"

Be honest.

Re: C++26: Erroneous behaviour

#95

Post by benreesman »

galangalalgol wrote: post #40
benreesman wrote: post #33

Earlier quoted context omitted.

I dramatically prefer modern C++ to either of Python or Rust in domains where it's a toss up. It's really nice these days. Like any language that lasts (including Python and Rust) you subset it over time: you end up with linters and sanitizers and static analyzers and LSP servers, you have a build. But setting up a build is a one-time cost and maintaining a build is a fact of life, even JavaScript is often/usually th…

I agree that python is often painful to get right. But asan really, doesn't help you unless you have tests that cover the path with the mistake it would catch. Safe rust doesn't segfault ever . Unsafe rust is still easier to get right for me than c, but mostly because c targets weird architectures with weird rules. Rust is also easier for me to develop fast in than either python or c++. For c++ that is because fragme…

If you don't have good tests with coverage information then your Python and Rust code is buggy too. If you want "as low of defects as I can get from the compiler alone" then your options are things like Haskell and theory-laden TypeScript.

If you have low-defect appropriate test coverage, ASAN approaches linear typing for the class of bugs that the borrow checker catches.

Python and Rust have their sweet spots just like C++ does, I use all three. The meme that either is a blanket replacement for all of C++'s assigned duties is both sikly by observation and not demonstrated by enthusiastic adoption in C/C++ in the highest-demand regimes: AI inference, HFT, extreme CERN-scale physics, your web browser.

Python is better for fast prototyping and other iteration critical work, Rust is unmatched for "zero defect target with close to zero cost abstractions" (it was designed for writing a web browser and in that wildly demanding donain I can think of nothing better).

C++ excels in extreme machine economics scenarios where you want a bit more flexibility in your memory management and a bit more license to overrule the compiler and a trivial FFI story. Zig to me looks likely to succeed it in this role someday.

All have their place, software engineers in these domains should know all of them well, and any "one true language" crap is zealoty or cynical marketing or both.

Re: C++26: Erroneous behaviour

#97

Post by galangalalgol »

benreesman wrote: post #95
galangalalgol wrote: post #40

Earlier quoted context omitted.

I agree that python is often painful to get right. But asan really, doesn't help you unless you have tests that cover the path with the mistake it would catch. Safe rust doesn't segfault ever . Unsafe rust is still easier to get right for me than c, but mostly because c targets weird architectures with weird rules. Rust is also easier for me to develop fast in than either python or c++. For c++ that is because fragme…

If you don't have good tests with coverage information then your Python and Rust code is buggy too. If you want "as low of defects as I can get from the compiler alone" then your options are things like Haskell and theory-laden TypeScript. If you have low-defect appropriate test coverage, ASAN approaches linear typing for the class of bugs that the borrow checker catches. Python and Rust have their sweet spots just l…

A coworker found a stack use after free in production that no amount of linters or tidyers caught. It only actually happened in the release build, and asan caught it, but only when we pushed to 100% branch coverage instead of just line coverage. Rust makes coverage much easier to get with fewer tests due to it's type system. It seems really clear to me that rust will be the c++ successor. If you need that extra flexibility, you use unsafe. That still feels less foot gun ridden than c++. The slow adoption of rust is because c++ interoperability is bad and people are stuck maintaining c++ behemoths. Green field rust adoption in c++ domains is much higher. Zig is more of a c replacement, but as much as I like it, I don't think that will happen. C is like a standardized ir. But when sonos wanted to make an arm cpu only onnx inference engine for instance, they made it in rust (tract). When c++ developers get to choose rust, we often do. I can throw earlier career c++ devs with modern c++ experience directly into a rust codebase and have them be immediately productive, but also not worry about them doing horrible things.

Re: C++26: Erroneous behaviour

#98

Post by benreesman »

galangalalgol wrote: post #97
benreesman wrote: post #95

Earlier quoted context omitted.

If you don't have good tests with coverage information then your Python and Rust code is buggy too. If you want "as low of defects as I can get from the compiler alone" then your options are things like Haskell and theory-laden TypeScript. If you have low-defect appropriate test coverage, ASAN approaches linear typing for the class of bugs that the borrow checker catches. Python and Rust have their sweet spots just l…

A coworker found a stack use after free in production that no amount of linters or tidyers caught. It only actually happened in the release build, and asan caught it, but only when we pushed to 100% branch coverage instead of just line coverage. Rust makes coverage much easier to get with fewer tests due to it's type system. It seems really clear to me that rust will be the c++ successor. If you need that extra flexi…

Yeah, you and I are both entitled to our guesses about Rust and Zig respectively in the future. Both have serious production projects (bun and TigerBeetle are best-in-class to head off any "hobby project" stuff), neither is making serious inroads to the domains I'm talking about: it doesn't get any hotter than the new CUTLASS stuff, and that's greenfield modern C++ with a standardization regime (mdarray) with 100% industry voting as a bloc for "it's still modern C++ at the frontier". HFT shops have at least some Rust at least auditioning, but the reqs are still C++, and they rewrite anything that alpha decays out.

When it's for all the marbles today? It's C++. The future is an open question, but a lot of us are pushing hard for C++.

Re: C++26: Erroneous behaviour

#99

Post by jibal »

kachapopopow wrote: post #96
jibal wrote: post #94

Earlier quoted context omitted.

"rust does quite literally, everything better" Be honest.

as a language, yes, the eco-system is still young.

You wrote "I just don't see a reason to use c++ anymore when rust does quite literally, everything better." -- there are numerous obvious reasons to continue to use C++, including its mature ecosystem, and other reasons have been pointed out.

You have been called out for dishonesty. Stop lying. I won't respond again.

Re: C++26: Erroneous behaviour

#100

Post by jibal »

kachapopopow wrote: post #50
TuxSH wrote: post #29

Earlier quoted context omitted.

> quite literally, everything better Like retained mode GUIs, games, intrusive containers or anything that can't be trivially represented by a tree of unique_/shared_ptr?

kinda don't get me wrong c++ is useful, however, rust is a platform language and should be used as such, like c++, but much further than that. modern games are almost never made in a native language, but rather on a language on top of it, be it squirle, lua, blueprints, c#, wasm, javascript, state trees, binary trees, decision trees...

No one got you wrong ... you claimed that you couldn't see any reason to continue to use C++. That was a lie.
Post reply on HN