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

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

collabora.com

Post reply on HN
Print view View original

381–390 of 675 posts

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

#381

Post by andrepd »

Ygg2 wrote: post #357
eptcyka wrote: post #318

Earlier quoted context omitted.

As per the article, Rust has benefits beyond the ones afforded by the borrow checker.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts.

I'd love to have a syntax like

    { foo(%1, bar) }
standing for

    |x| { foo(x, bar) }
though. I'm not aware of any language that has this!

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

#382

Post by ultimaweapon »

codedokode wrote: post #355
ultimaweapon wrote: post #300

Earlier quoted context omitted.

Rust is the only language I can easily control how integer overflow should behave. I can use `var1.wrapping_add(var2)` if I want the result to be wrapped or `var1.checked_add(var2)` if I don't want it to overflow.

The functions are so verbose and inconvenient that even Rust developers themselves do not use them. For example, in this code [1] they used a wrapping addition instead of "checked_add" because it is faster to write. For comparison, Swift uses "+" for checked addition and as a result, majority of developers use checked addition by default. And in Rust due to its poor design choices most developers use wrapping additio…

Checked addition by default will have too much overhead and it will hurt performance, which unacceptable in Rust since it was designed as a system language. Swift can use checked add by default since it was designed for application software.

Your example code is not because it is faster to write, it is because it is impossible for its to overflow on that line.

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

#383

Post by blub »

quietbritishjim wrote: post #342

I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…

This article presents something I’d expect competent C++ programmers with a few years of experience to know.

Unfortunately, many programmers are not competent. And the typical modern company will do anything in its power to outsource to often the lowest bidder, mismanage projects and generally reduce quality to the minimum acceptable to make money. That’s why one needs tools like Rust, Java, TypeScript, etc.

Unfortunately, Rust is still too hard for the average programmer, but at least it will hit them over the hands with a stick when they do something stupid. Another funny thing about Rust is that it’s attracting the functional programming/metaprogramming astronauts in droves, which is at odds with it being the people’s programming language.

I still don’t think it’s a valuable skill. Before it was lack of jobs and projects, which is still a problem. Now it’s the concern that it’s as fun as , except in a straitjacket.

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

#384

Post by monkeyelite »

tsimionescu wrote: post #375
monkeyelite wrote: post #371

Earlier quoted context omitted.

I question both things. I would first of all handle each request in its own process. If there was a special case that would not work, then the design dictates that requests are not independent and there must be risk of interference (they are in the same process!) What I definitely do not want is a bug ridden “crashable async sub task” system built in my web program.

This is simply a wrong idea about how to write web servers. You're giving up scalability massively, only to gain a minor amount of safety - one that is virtually irrelevant in a memory safe language, which you should anyway use. The overhead of process-per-request, or even thread-per-request, is absurd if you're already using a memory safe language.

> You're giving up scalability massively

you’re vastly over estimating the overhead of processes and number of simultaneous web connections.

> only to gain a minor amount of safety

What you’re telling me is performance (memory?) is such a high priority you’re willing to make correctness and security tradeoffs.

And I’m saying thats ok, one of those is crashing might bring down more than one request.

> one that is virtually irrelevant in a memory safe language

Your memory safe language uses C libraries in its process.

Memory safe languages have bugs all the time. The attack surface is every line of your program and runtime.

Memory is only one kind of resource and privilege. Process isolation is key for managing resource access - for example file descriptors.

Chrome is a case study if these principles. Everybody thought isolating JS and HTML pages should be easy - nobody could get it right and chrome instead wrapped each page in a process.

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

#385

Post by andrepd »

thrwyexecbrain wrote: post #132

The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testi…

Lack of pattern matching and move only types means you physically cannot code in C++ as you would in Rust, even ignoring all the memory safety stuff.

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

#386

Post by tialaramex »

codedokode wrote: post #359
kelnos wrote: post #152

Earlier quoted context omitted.

Rust does have checked arithmetic operations (that return Result), but you have to explicitly opt in to them, of course, and they're not as ergonomic to use as regular arithmetic.

As a result, Rust developers themselves use wrapping addition where a checked addition should be used: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#2010

That's not a wrapping addition, that addition will never overflow so it has no overflow behaviour.

This line could only overflow after we need to grow the container, so immediately this means the type T isn't a ZST as the Vec for ZSTs doesn't need storage and so it never grows.

Because its not a ZST the maximum capacity in Rust is never bigger than isize::MAX which is an entire binary order of magnitude smaller than usize::MAX, as a result len + 1 can't overflow the unsigned type, so this code is correct as written.

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

#387

Post by blub »

lmm wrote: post #350
quietbritishjim wrote: post #342

I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is triv…

> 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 conspires against quality. Languages like Rust are a desperate attempt at fixing that with technology.

I guess it works, in a way, but these kind of blog posts just show us how inept most programmers are and why the Rust band-aid was needed in the first place.

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

#388

Post by imtringued »

josephg wrote: post #277
almostgotcaught wrote: post #272

Earlier quoted context omitted.

The question wasn't whether C/C++ are platonic ideals, the question was whether a language can be mature without a package manager.

If we take “mature” to mean “old” then yes - C and C++ are certainly old. If we take “mature” to mean “good”, then my answer changes.

Agreed. Getting started with a C or C++ project is such a pain in the ass that I won't even bother. Then there is the fact that unless you have special requirements that necessitate C/C++, those languages have nothing going for them.

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

#389

Post by scotty79 »

dvratil wrote: post #8

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, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking r…

> Then you top it on with `?` shortcut

I really wish java used `?` as a shorthand to declare and propagate checked exceptions of called function.

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

#390

Post by Munksgaard »

andrepd wrote: post #381
Ygg2 wrote: post #357

Earlier quoted context omitted.

Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.

I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts. I'd love to have a syntax like { foo(%1, bar) } standing for |x| { foo(x, bar) } though. I'm not aware of any language that has this!

Elixir has this, which is close:

    &foo(&1, bar)
Post reply on HN