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

I think C++ is still a desirable coding platform compared to Rust

lucisqr.substack.com

Post reply on HN
Print view View original

21–30 of 110 posts

Re: I think C++ is still a desirable coding platform compared to Rust

#21

Post by jmcomets »

distcs wrote: post #3

I've done some C++ but no Rust. I'd like to learn a few things from people who have done both. 1. How many years of C++ programming do you have under your belt? How many years of Rust? 2. For new work projects, do you choose C++ or Rust? Why? 3. For new hobby projects, do you choose C++ or Rust? Why? 4. Is there something about C++ that you wish Rust had? 5. Is there something nice about Rust (apart from the borrow c…

1) C++: 7+ years; Rust: 3+ years.

2) C++, my employer's choice. Their rationale: easier to hire people with experience, internal codebase is mostly C++ so tooling/people more versed.

3) Rust. For me it's just easier overall to work with. It takes me an hour or so to get my head back into Rust's standard library and idioms/quirks, but afterwards it feels much better to work with: dev. workflow, testing, expressiveness. Plus it catches programming errors for me every once in a while.

4) I wish Rust had wider adoption by the industry. It's always compared to C/C++/Java/Go and the usual argument boil down to "not enough people use it".

5) I wish C++ had better compiler error messages. I have to rely on instinct when it's not scrolling through nested template/SFINAE errors to understand what's happening. Rust tells me "here's what's wrong" 99% of the time.

Re: I think C++ is still a desirable coding platform compared to Rust

#23

Post by synergy20 »

distcs wrote: post #7

A few things I've found notoriously difficult to do in C++: 1. Add two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit integers. If the sum is going to overflow, generate an error. If the sum is not going to overflow, evaluate the sum. 2. Multiply two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit in…

use some bigint libraries,or,use long double?

Re: I think C++ is still a desirable coding platform compared to Rust

#24

Post by vlmutolo »

distcs wrote: post #7

A few things I've found notoriously difficult to do in C++: 1. Add two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit integers. If the sum is going to overflow, generate an error. If the sum is not going to overflow, evaluate the sum. 2. Multiply two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit in…

Rust often has convenience methods in its standard library for things like this that are common and tend to produce bugs when re-implemented over and over, and have a reasonable way to do it without making tradeoffs that will annoy some people over others.

In this case, it’s:

    10i64.checked_add(20i64)
    10i64.checked_mul(20i64)
Both expressions return an Option type, which is effectively a tagged union with type safety on top so you can’t misuse it. You can either call “unwrap” to get the value out and trigger stack unwinding on error, or pattern match on the Option and its inner value in a more functional style.

Re: I think C++ is still a desirable coding platform compared to Rust

#25

Post by chalsprhebaodu » 

    Calling “unsafe” as an escape for Rust’s rigid system is the same as saying that C++ can do inline assembly so you can copy/paste infinite optimizations done outside the compiler infrastructure.
That’s not the same at all. Unsafe can be used pragmatically.

    [Regarding UB in C++] So why C++ ignored that possible edge case? Because signed overflow in C++ is undefined behavior and as far as the compiler is concerned, it will never happen. With the edge case reasoned away by the language, the compiler is free to implement that optimization…

    If you compile a similar function in Rust, you will see that Rust will be unable to optimize that expression away because both signed and unsigned overflows in Rust are well defined in the language as a two’s complement… 

    Again, pundits will state that you could have called one of the arithmetic wrapping functions, which will force the compiler to do this optimization. Well you can do many things but here we are measuring the effect of the compiler over two similar blocks of code.
Talk about premature optimization. You’d rather have all of the pitfalls of Undefined Behavior to get an optimization you can achieve in Rust because you’d rather be less explicit?

This article is clearly not directed at me.

For the record, I love C++ and use it daily and will continue to do so. I also like Rust. It can be frustrating at times to have to change the way you think about structuring your program between the two, but that doesn’t mean that one or the other can’t be used effectively and safely.

Re: I think C++ is still a desirable coding platform compared to Rust

#26

Post by Philpax »

distcs wrote: post #3

I've done some C++ but no Rust. I'd like to learn a few things from people who have done both. 1. How many years of C++ programming do you have under your belt? How many years of Rust? 2. For new work projects, do you choose C++ or Rust? Why? 3. For new hobby projects, do you choose C++ or Rust? Why? 4. Is there something about C++ that you wish Rust had? 5. Is there something nice about Rust (apart from the borrow c…

1. Hard to count. Started as a youth on game modding, but in terms of serious projects, probably 5-7 years.

2. Rust. It's a Rust shop, and the only C++ we have is in dependencies that we wrap with Rust interfaces.

3. Rust. I've probably shaved a not-inconsiderable amount of time off my life in debugging C++ issues at both compile-time and runtime (inscrutable behaviours, memory safety, broken / unstandardized tooling, platform-specific nonsense, template metaprogramming sins that I've had to debug and - worse - add to, and much more)

4. Hmm. Template specialisation and more constant-time evaluation, I think. There's probably a few others, but that's what comes to mind.

5. Uh. Pretty much everything?

- Consistent tooling that works across all platforms (I will be happy if I never have to look at a line of CMake ever again)

- Built-in dependency management

- A robust engineering culture (your code should account for failure!)

- Consistency of code itself, made possible through rustfmt and clippy

- Generics that surface issues at point of definition and not at point of instantiation

- ADTs

- Reduced reliance on human strictness / "getting it right" to, well, get it right. This isn't just the borrow checker - most APIs in Rust are designed to make using them wrong difficult. Even things like `Mutex`, which combines a mutex and value, to make sure you can't access the value without locking, and you can't lock without knowing what you're locking.

- Easy multithreading through invariants that the compiler tracks (the Send+Sync traits); they're not perfect, but there's nothing like the first time you change an `iter` to Rayon's `par_iter` and your code is magically eight times faster.

- A value-based typed rich error handling scheme, so that you can see what errors a given piece of code might produce and be able to handle and propagate them with little fuss. (Similar to checked exceptions, but much more convenient! Adding some context to an error is a function call and `?` away, not a per-statement try-catch-rethrow).

---

Honestly, I could keep going for a while, but my general point is that Rust has had the ability to learn from its predecessors, and it shows. Many of the mistakes, bad ideas, or poorly-fitting features of past languages just aren't present in Rust because the language was deliberately designed to avoid them.

It's not a perfect language by any means - async Rust is the first and most obvious pain point - but it solves my problems in a much more ergonomic - and dare I say it, more fun - way than C++ ever did.

Re: I think C++ is still a desirable coding platform compared to Rust

#27

Post by zdimension »

distcs wrote: post #7

A few things I've found notoriously difficult to do in C++: 1. Add two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit integers. If the sum is going to overflow, generate an error. If the sum is not going to overflow, evaluate the sum. 2. Multiply two signed 64-bit integers without overflowing on either side (negative or positive) and without using 128-bit in…

> 1. add two signed 64 but it's without overflowing

  fn f(x: i64, y: i64) -> Option {
    x.checked_add(y)
  }
Option being the Rust equivalent for std::optional, but with all the nice ADT features so it's ergonomic to use. You can transform it to a Result if you want, or even just panic and exit if it overflows. In any case, the overflow handling is built-in and doesn't use 128 bit ints.

> 2. Multiply two signed 64 bit ints without overflow

  x.checked_mul(y)
(https://doc.rust-lang.org/std/primitive.i64.html#method.chec..., https://doc.rust-lang.org/std/primitive.i64.html#method.chec...)

Re: I think C++ is still a desirable coding platform compared to Rust

#28

Post by distcs »

> In many years of coding C++, very rarely I experienced a stack overflow or segmentation fault. It is literally not an issue in every codebase I have worked with.

Is this true for most people though? What do you think about this quote?

Frankly I've seen a lot of segmentation fault issues with C++ projects. Granted much of it can be detected pre-emptively with good tools and when a segfault happens, I can debug it quickly too using a good debugger.

But I've to say that they still do happen and I still see them happening enough while developing and testing that I cannot simply dismiss segfaults as something unimportant.

Re: I think C++ is still a desirable coding platform compared to Rust

#29

Post by synergy20 »

cmrdporcupine wrote: post #10
distcs wrote: post #3

I've done some C++ but no Rust. I'd like to learn a few things from people who have done both. 1. How many years of C++ programming do you have under your belt? How many years of Rust? 2. For new work projects, do you choose C++ or Rust? Why? 3. For new hobby projects, do you choose C++ or Rust? Why? 4. Is there something about C++ that you wish Rust had? 5. Is there something nice about Rust (apart from the borrow c…

I currently work in a mixed C++ & Rust shop -- embedded Linux, autonomy systems for tractors -- and know C++ very well. I choose to work exclusively in Rust. 1. 10-20 years of C++ depending on your definition. But used C++ part-time casually/open-source from mid-90s to 2012 or so, and then mostly full-time from that point on @ Google, with a big chunk of that working in the Chromium source tree. 2ish years Rust, incl…

same here embedded Linux,until rust apps can share the same shared libraries as c++ can, we have a size issue using rust,so,no rust

Re: I think C++ is still a desirable coding platform compared to Rust

#30

Post by dale_glass »

The "The Dubious Benefits of Safety" is highly naive.

I think the author greatly underestimates the ease with which code ends up exposed to attackers. Sure, the author works on some internal thing. But where does the data come from? And data often comes in complex formats. Does the application deal with say, images or zip files? Lots of room for something to go wrong there. Projects that start internal can become part of something exposed to the outside. A modern, large project may have a few dozen dependencies, the quality of each is far from guaranteed.

For crashes, the issue is that in a complex enough project, troubeshooting is often far from trivial. Things often explode in a different place from where the bug was. My hobby project simply doesn't run under Valgrid, it's too slow for the code to run under it.

Post reply on HN