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

51–60 of 103 posts

Re: C++26: Erroneous behaviour

#51

Post by quamserena »

jjmarr wrote: post #45
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…

> Safe rust doesn't segfault ever . https://github.com/Speykious/cve-rs > That is why cve-rs uses #![deny(unsafe_code)] in the entire codebase. There is not a single block of unsafe code (except for some tests) in this project. > cve-rs implements the following bugs in safe Rust: * Use after free * Buffer overflow * Segmentation fault

Rust’s borrow checker has been mathematically verified to be always sound.[0] These are edge case implementation bugs that user code is unlikely to touch. I have never had a soundness hole/segfault from safe Rust, and I am not aware of any code in the wild which stumbled into one of these soundness holes either. The main bug is [1], which is very contrived lifetime shenanigans that wouldn't appear in real code. Some bugs [2] are miscompilations coming from the LLVM side. If implemented perfectly, all safe Rust code would be sound, but of course all programs have bugs. The important part is that 99.9% of safe Rust code is sound.

[0] https://hal.science/hal-01633165v2/document

[1] https://github.com/rust-lang/rust/issues/25860

[2] https://github.com/rust-lang/rust/issues/107975

Re: C++26: Erroneous behaviour

#52

Post by pjmlp »

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…

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++.

Backwards compatibility is what keeps C and C++ relevant, for better or worse.

All major languages value backwards compatibility to certain extent.

Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things around.

Re: C++26: Erroneous behaviour

#53

Post by leoh »

pjmlp wrote: post #52
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…

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Backwards compatibility is what keeps C and C++ relevant, for better or worse. All major languages value backwards compatibility to certain extent. Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things aroun…

Really? I have found the UX stuff with egui to be super ergonomic. It's not "native", though. Trying to do macOS UX with it, I have found, generally sucks (curious if anyone knows of any good libraries). Then again C++ probably sucks for native macOS too. So I really don't think Rust is far off.

Re: C++26: Erroneous behaviour

#54

Post by leoh »

quamserena wrote: post #51
jjmarr wrote: post #45

Earlier quoted context omitted.

> Safe rust doesn't segfault ever . https://github.com/Speykious/cve-rs > That is why cve-rs uses #![deny(unsafe_code)] in the entire codebase. There is not a single block of unsafe code (except for some tests) in this project. > cve-rs implements the following bugs in safe Rust: * Use after free * Buffer overflow * Segmentation fault

Rust’s borrow checker has been mathematically verified to be always sound.[0] These are edge case implementation bugs that user code is unlikely to touch. I have never had a soundness hole/segfault from safe Rust, and I am not aware of any code in the wild which stumbled into one of these soundness holes either. The main bug is [1], which is very contrived lifetime shenanigans that wouldn't appear in real code. Some…

Ditto. I have literally never encountered a segfault in Rust in almost 2y except when calling C code via FFI.

Re: C++26: Erroneous behaviour

#55

Post by pjmlp »

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?

Easy to reach these numbers.

Many developers never do the math of what their salaries actually cost.

We in consulting are deeply aware of the impact mapping hours and days into money, plus license and support costs, and infrastructure.

Hence why I dislike all those "I rewrote X into Y", great and how many thousands did that fun endeavour cost to the employer?

Re: C++26: Erroneous behaviour

#56

Post by pjmlp »

leoh wrote: post #53
pjmlp wrote: post #52

Earlier quoted context omitted.

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Backwards compatibility is what keeps C and C++ relevant, for better or worse. All major languages value backwards compatibility to certain extent. Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things aroun…

Really? I have found the UX stuff with egui to be super ergonomic. It's not "native", though. Trying to do macOS UX with it, I have found, generally sucks (curious if anyone knows of any good libraries). Then again C++ probably sucks for native macOS too. So I really don't think Rust is far off.

Yes really, because it is nothing like Qt, in IDE integration, tools for designers, or ecosystem from 3rd parties components.

C++ sucks for macOS, because it was never a first party language, unless using it via Objective-C++.

The only role of C++ in macOS is for drivers, LLVM and being the Metal Shader Language (C++14 with extensions).

Re: C++26: Erroneous behaviour

#58

Post by Ygg2 »

jjmarr wrote: post #45
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…

> Safe rust doesn't segfault ever . https://github.com/Speykious/cve-rs > That is why cve-rs uses #![deny(unsafe_code)] in the entire codebase. There is not a single block of unsafe code (except for some tests) in this project. > cve-rs implements the following bugs in safe Rust: * Use after free * Buffer overflow * Segmentation fault

> https://github.com/Speykious/cve-rs

Caution: Lifetime may not live long enough

https://github.com/Speykious/cve-rs/issues/48

Re: C++26: Erroneous behaviour

#60

Post by Ygg2 »

pjmlp wrote: post #52
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…

Python isn't for people that care about performance, and Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++. Backwards compatibility is what keeps C and C++ relevant, for better or worse. All major languages value backwards compatibility to certain extent. Python was lucky that after Python 2 to Python 3 mess, being the AI scripting language, has turned things aroun…

> Rust has still lots of work to do to provide any GUI, game engine or GPU framework as ergonomic as C++.

Slint, Bevy and no idea what a GPU framework is (even search engines are stumped; they keep recommending Framework laptops). Is it just CUDA?

Not gonna lie, what exactly is this mismatch of stuff? How to be C++ in 3001 steps?

Ergonomic as C++? That sounds as oxymoronic as "musical as nails on a chalkboard or a cat drowning in porridge." Having had the displeasure to read some relatively complex C++ codebase (SIMD json), has left me in deep appreciation of Java.

Post reply on HN