Live data from Hacker News

Matt Godbolt sold me on Rust by showing me C++

collabora.com

521–530 of 675 posts

Re: Matt Godbolt sold me on Rust by showing me C++

#521

Earlier quoted context omitted.

> The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions This isn't really true since Rust has panics. It would be nice to have out-of-the-box support for a "no panics" subset of Rust, which would also make it easier to properly support linear (no auto-drop) types.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

The issue with this in practice is that there are always cases where panics are absolutely the correct course of action. When program state is bad enough that you can't safely continue, you need to panic (and core dump in dev). Otherwise you are likely just creating an integrity minefield for you to debug later.

Not saying there aren't applications where using these lints couldn't be alright (web servers maybe), but at least in my experiences (mostly doing CLI, graphics, and embedded stuff) trying to keep the program alive leads to more problems than less.

Re: Matt Godbolt sold me on Rust by showing me C++

#522

Earlier quoted context omitted.

Based on the rest of your comment I suspect you're already familiar, but a decent candidate for "Rust with a GC" is OCaml, the language the first Rust compiler was written in.

It's close. Perhaps there's an interesting conversation to be had about why OCaml hasn't taken over the world the way Rust has. The toolchain might be a first candidate. Rust's toolchain feels so very modern, and OCaml's gives me flashbacks to late nights trying to get my homework done on the department's HP-UX server back in college.

Can I interest you in some Moonbit?

https://www.moonbitlang.com/blog/first-announce

Re: Matt Godbolt sold me on Rust by showing me C++

#523
post #387
post #350

Earlier quoted context omitted.

> I just almost never have problems with this sort accidental conversion in practice. 95% of C++ programmers claim this, but C++ programs continue to be full of bugs, and they're usually exactly this kind of dumb bug. > will be noticed by literally just running the code once. Maybe. If what you're doing is "tricky mathematical algorithms", how would you even know if you were making these mistakes and not noticing the…

It’s the sociology of software development. The guild of software developers has no real standards, no certification, no proven practices outside and while continuing to depend on the whims of project managers, POs and so-caled technical leaders and others which can’t tell quality code from their own ass. There’s usually no money in writing high-quality software and almost everything in a software development project…

This. The industry is a hot-pot of gut feelings/seat of my pants mixed with true engineering and mathematical rigor.

It is all hit or miss. Everyone claims they do high-quality, critical software in public, while in private, they claim the opposite, that they are fast and break things, and programming is an art, not math.

And then you have venture capital firms now pushing "vibe coding."

Software development is likely the highest variance engineering space, sometimes and in some companies, not even being engineering, but "vibes."

It is interesting how this is going to progress forward. Are we going to have a situation like the Quebec Bridge [https://colterreed.com/the-failed-bridge-that-inspired-a-sim...]. The Crowdstrike incident taking down the whole airspace proved that is not enough. Market hacks in "decentralized exchanges," the same. Not sure where we are heading.

I guess we are waiting for some catastrophe that will have some venture capital liable for the vibe coding, and then we will have world wide regulation pushed on us.

Re: Matt Godbolt sold me on Rust by showing me C++

#524

Hey, check this out: #include struct Price { double x; }; struct Quantity { int x; }; void sendOrder(const char *symbol, bool buy, Quantity quantity, Price price) { std::cout } int main(void) { sendOrder("GOOG", false, Quantity{100}, Price{1000.00}); // Correct sendOrder("GOOG", false, Price{1000.00}, Quantity{100}); // compiler error } If you're trying to get it to type check, you have to make a type first. I don't…

That still has the issue of Quantity{-100} being a-ok as far as the compiler is concerned, but there are other things one can do (as the article alludes to).

My reading of this article wasn't to say that these things are impossible in C++, just that they're not the default or the first thing you try as a beginner is perfectly wrong.

Re: Matt Godbolt sold me on Rust by showing me C++

#525

Earlier quoted context omitted.

This is already a thing, I do this right now. You configure the linter to forbid panics, unwraps, and even arithmetic side effects at compile time. You can configure your lints in your workspace-level Cargo.toml (the folder of crates) “”” [workspace.lints.clippy] pedantic = { level = "warn", priority = -1 } # arithmetic_side_effects = "deny" unwrap_used = "deny" expect_used = "deny" panic = "deny" “”” then in your cr…

The issue with this in practice is that there are always cases where panics are absolutely the correct course of action. When program state is bad enough that you can't safely continue, you need to panic (and core dump in dev). Otherwise you are likely just creating an integrity minefield for you to debug later. Not saying there aren't applications where using these lints couldn't be alright (web servers maybe), but…

The comment you're replying to specifically wanted "no panics" version of rust.

It's totally normal practice for a library to have this as a standard.

Re: Matt Godbolt sold me on Rust by showing me C++

#526
post #520

Earlier quoted context omitted.

I cannot follow your rant... I'll do my best to respond, but I'm probably not understanding something. Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different…

> Divide by zero must be undefined behavior in any performant language. On x86 you either have a if before running the divide (which of course in some cases the compiler can optimize out, but only if it can determine the value is not zero); or you the CPU will trap into the OS - different OSes handle this in different ways, but most not in a while that makes it possible to figure out where you were and thus do someth…

Google has a odd C++ style guide that rules out a lot of useful things for their own reasons.

There is no reason why make could not work with modules if someone wanted to go through the effort. The CMake people have even outlined what needs to be done. Ninja is so much nicer that you should switch anyway - I did more than 10 years ago.

Re: Matt Godbolt sold me on Rust by showing me C++

#527

Earlier quoted context omitted.

Honestly, I don't think libraries should ever panic. Just return an UnspecifiedError with some sort of string. I work daily with rust, but I wish no_std and an arbitrary no_panic would have better support.

Example docs for `foo() -> Result `: # Errors `foo` returns an error called `UnspecifiedError`, but this only happens when an anticipated bug in the implementation occurs. Since there are no known such bugs, this API never returns an error. If an error is ever returned, then that is proof that there is a bug in the implementation. This error should be rendered differently to end users to make it clear they've hit a b…

Funny that as a user of this library, I would just unwrap this, and it results in the same outcome as if library panicked.

Re: Matt Godbolt sold me on Rust by showing me C++

#528
post #444
post #236

Earlier quoted context omitted.

Counterpoint: Decades of C++/Python/Java/... has strongly biased me against the try/except pattern. It's obviously subjective in many ways. However, what I dislike the most is that try/except hides the error path from me when I'm reading code. Decades of trying to figure out why that stacktrace is happening in production suddenly has given me a strong dislike for that path being hidden from me when I'm writing my cod…

There should be a way to have the function/method document what sort of stuff can go wrong, and what kinds of exceptions you can get out of it. It could be some kind of an exception check thing, where you would either have to make sure that you handle the error locally somehow, or propagate it upwards. Sadly programming is not ready for such ideas yet. --- I jest, but this is exactly what checked exceptions are for.…

I totally agree with you that Java checked exceptions suck. IME exceptions are far more ergonomic than Result.

Nim has a good take on exception tracking that's elegant, performant, and only on request (unlike Java's attempt).

Re: Matt Godbolt sold me on Rust by showing me C++

#529
post #506

Earlier quoted context omitted.

A lot UB is things you wouldn't do anyway. While it is possible to define divide by zero or integer overflow, what does it mean. If you code does either of those things you have a bug in your code (a few encryption algorithms depend on specific overflow behavior - if your language promises that same behavior it is useful). Since CPUs handle such things differently whatever you define to happen means that the compiler…

This is a bad answer too, IMO. I think there is a solid case for the existence of undefined behavior; even Rust has it, it's nothing absurd in concept, and you do describe some reasoning for why it should probably exist. However, and here's the real kicker, it really does not need to exist for this case . The real reason it exists for this case is due to increasingly glaring deficiencies in the C++ language, namely,…

I agree very much with what you wrote.

> the lack of any form of pattern matching for control flow

Growing features after the fact is hard. Look at the monumental effort to get generics into Go. Look at how even though Python 3.10 introduced the match statement, it is a statement and not an expression - you can't write `x = match ...`, unlike Rust and Java 14. So it doesn't surprise me that C++ struggles with this.

> Undefined behavior indeed should exist

Agreed. Rust throws up its hands in narrow cases ( https://doc.rust-lang.org/reference/behavior-considered-unde... ), and even Java says that calling Thread.stop() and forcing monitor unlocks can lead to corrupted data and UB.

> but not for common cases like

Yes, C/C++ have far, far too many UB cases. Even down to idiotically simple things like "failing to end a source file with newline". C and C++ have liberally sprinkled UB as a cop-out like no other language.

> C++ does that for shit like basic arithmetic

I spent an unhealthy amount of time understanding the rules of integer types and arithmetic in C/C++. Other languages like Rust are as capable without the extreme mental complexity. https://www.nayuki.io/page/summary-of-c-cpp-integer-rules

Oh and, `(uint16_t)0xFFFF * (uint16_t)0xFFFF` will cause a signed 32-bit integer overflow on most platforms, and that is UB and will eat your baby. Scared yet? C/C++ rules are batshit insane.

> "Just get better at programming" is a nice platitude, but it doesn't work.

Correct. Far too often, I hear a conversation like "C/C++ have too many UB, why can't we make it safer?" "Just learn to write better code, dumbass". No, literal decades of watching the industry tells us that the same mistakes keep happening over and over again. The evidence is overwhelming that the languages need to change, not the programmers.

> it's obvious at this point that C++ will never get a handle on all of the undefined behavior; they've just introduced far too much undefined behavior all throughout the language and standard library

True.

> in ways that are going to be hard to fix, especially while maintaining backwards compatibility

Technically not true. Specifying undefined behavior is easy, and this has already been done in many ways. For example, -fwrapv makes signed overflow defined to wrap around. For example, you could zero-initialize every local variable and change malloc() to behave like calloc(), so that reading uninitialized memory always returns zero. And because the previous behavior was undefined anyway, literally any substitute behavior is valid.

The problem isn't maintaining backward compatibility, it's maintaining performance compatibility. Allegedly, undefined behavior allows the compiler to optimize out redundant arithmetic, redundant null checks, etc. I believe this is what stops the standards committees from simply defining some kind of reasonable behavior for what is currently considered UB.

> a meaningful "safe" subset of C++ that can guarantee safety from memory errors, concurrency errors or most types of undefined behavior is simply never going to happen

I think it has already happened. Fil-C seems like a capable approach to transpile C/C++ and add a managed runtime - and without much overhead. https://github.com/pizlonator/llvm-project-deluge/blob/delug...

> The uncontrolled proliferation of undefined behavior is ultimately what is killing C++

It's death by a thousand cuts, and it hurts language learners the most. I can write C and C++ code without UB, but it took me a long time to get there - with a lot of education and practice. And UB-free code can be awkward to write. The worst part of it is that the knowledge is very C/C++-specific and is useless in other languages because they don't have those classes of UB to begin with.

I dabbled in C++ programming for about 10 years before I discovered Rust. Once I wrote my first few Rust programs, I was hooked. Suddenly, I stopped worrying about all the stupid complexities and language minutiae of C++. Rust just made sense out of the box. It provided far fewer ways to do things ( https://www.nayuki.io/page/near-duplicate-features-of-cplusp... ), and the easy way is usually the safe and correct way.

To me, Rust is C++ done right. It has the expressive power and compactness of C++ but almost none of the downsides. It is the true intellectual successor to C++. C++ needs to hurry up and die already.

Re: Matt Godbolt sold me on Rust by showing me C++

#530

Earlier quoted context omitted.

Please find one web server being actively developed using one process per request. Handling thousands of concurrent requests is table stakes for a simple web server. Handling thousands of concurrent processes is beyond most OSs. The context switching overhead alone would consume much of the CPU of the system. Even hundreds of processes will mean a good fraction of the CPU being spent solely on context switching - whi…

> Handling thousands of concurrent processes is beyond most OS It works fine on Linux - the operating system for the internet. Have you tried it? > good fraction of the CPU being spent solely on context switching I was waiting for this one. Threads and processes do the same amount of context switching. The overhead of processes switch is a little higher. The main cost is memory.

> Threads and processes do the same amount of context switching.

Yes, therefore real webservers use a limited amount of threads/processes (in the same ballpark as a number of CPU cores). Modern approach is to use green threads which are really cheap to switch, it is like store registers, read registers and jmp.

> The main cost is memory.

The main cost is scheduling, not switching per se. Preemptive multitasking needs to deal with priorities to not waste time, and algorithms that do it are O(N) mostly. All these O(N) calculations needs to be completed multiple times per second, the higher the frequency of switching the more work to do. When you have thousands of processes it is the main cost. If you have tens of thousands it starts to bite hard.

Post reply on HN