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

Switching from C++ to Rust

laplab.me

Post reply on HN
Print view View original

151–160 of 289 posts

Re: Switching from C++ to Rust

#151

Post by School-Cotton »

cmrdporcupine wrote: post #105
xiphias2 wrote: post #5

The most fun thing reading this comparision is again that for an experienced C++ programmer who is used to managing memory by hand (and fixing segfaults), Rust's memory model doesn't seem that hard, because it makes sense, and he understands why the checks are important.

when I started moving from C++ to Rust I found the easiest initial way to make sense of the borrow checker was to basically imagine that almost every argument passed in a function call was wrapped in a std::move.

every argument is passed by move, not just almost every.

Types that implement Copy are still moved. Copy just means “the original value is still usable after move”.

Re: Switching from C++ to Rust

#152

Post by chombier »

To me, one of the best thing in Rust compared to C++ is that I no longer have to be super careful all the time to avoid common pitfalls, I just write stuff and fix compilation warnings/errors until the compiler is happy, and things mostly just work (apart from domain-specific bugs of course)

After getting used to the basics of Rust, I found the cognitive load to become much lower compared to C++. There's just no way I could write correct C++ code in such a careless fashion.

So now I can spend brain cycles on things that actually matter, and it's great.

Re: Switching from C++ to Rust

#153

Post by School-Cotton »

faitswulff wrote: post #110
unwrap_abuse wrote: post #81

So the problem with rust you will find is the abuse of unwrap in ecosystem, so your code will need to be panic-safe. We wanted to get rid of C++ exceptions but traded it for panic hell.

What libraries have you found to use unwrap liberally?

The standard library is one example. Indexing into a vector unwraps, as do many other stdlib functions.

Re: Switching from C++ to Rust

#154

Post by School-Cotton »

alphanullmeric wrote: post #115

Rust will only be a real competitor once it’s generics can hold a candle to C++ templates.

I disagree, Rust is already being used for tons of real-world projects. It’s quite rare that you miss the flexibility of templates (and can’t accomplish a similar thing using macros or generated code).

Re: Switching from C++ to Rust

#155

Post by fulafel »

mgsloan2 wrote: post #66
zabzonk wrote: post #19

Earlier quoted context omitted.

so, um, unions? i have to say that in many years of programming, i have almost never needed to use such types.

In my experience with languages that lack concise sum types and pattern matching, you end up with data types that have lots of implicit invariants. If you find yourself writing docs or thinking in your head things like "Field X is only set if field Y is true" or "If field X is non-null then field Y must be null and vice-versa", then these are indications that sum types would model the data better. Then these invarian…

Type systems are of course not the only possible mechanism that can enforce these kinds of invariants. In dynamic languages, schema style solutions (eg malli or spec in Clojure) have advantages: they have more expressivity than typical type systems, you can manipulate them as data, you can use in contexts that are not statically verifiable, like at the data interfaces of yuor app.

Re: Switching from C++ to Rust

#156

Post by Sparkyte »

gnulinux wrote: post #87
burntsushi wrote: post #3

The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…

This is exactly what I think too. Sum types are so powerful, I feel a lot safer in Python + mypy with sum types (`from typing import Union`) than anything with C++ [1] even though C++ has a significantly more complex type system (it's type system is TC) and Python is as type-unsafe as a language can get. C++ made this odd choice as if any complex type system is better than a simple type system. When I was a younger s…

You can just make your python modules out of another language. I am not sure why code has to be big. Break it down and make it executive, not very friendly in terms of threads but if you're writing an API you are writing it for Linux which is vastly safer for threads than Microsoft or Mac.

https://developers.redhat.com/blog/2017/11/16/speed-python-u...

Re: Switching from C++ to Rust

#157

Post by cornholio »

otabdeveloper4 wrote: post #141
unwrap_abuse wrote: post #81

So the problem with rust you will find is the abuse of unwrap in ecosystem, so your code will need to be panic-safe. We wanted to get rid of C++ exceptions but traded it for panic hell.

"Panic" and "exception" is literally the same thing. Sorry you were misled, but programming is, indeed, hard, and no, you can't go shopping instead.

A panic is an unrecoverable error caused by violating runtime invariants. A bug exists in the program and there is no (correct) way for the program to continue execution. For example, an array was accessed at index "-1".

Exceptions are a particular technique for dealing with errors in general, that can be used for both unrecoverable and recoverable errors. They infamously trade programmer convenience for hard to understand bugs, fragile run-time behavior and unmaintainable code.

Re: Switching from C++ to Rust

#158

Post by delta_p_delta_x »

jesse__ wrote: post #124
bluGill wrote: post #97

Earlier quoted context omitted.

I hate it too, but every alternative can't handle some dark corner of my build that just works in cmake.

Have you tried just using bash? (not a joke) I do this for personal projects and honestly, considering the alternatives, I think it rules.

I think the issue with CMake is exactly the issue with C++.

There's a 'modern' way to do things, and a 'legacy' way to do things, and the respective designers of CMake and C++ have decided that it was—for several reasons—better to leave the 'legacy' stuff in the languages, rather than pull a Python and make a clean split.

In 'modern' CMake, there are targets, and properties on said targets, i.e. compile and link options, C/C++ versions, libraries, headers, other custom dependencies, etc.

There are also functions and generator expressions[1] to make control flow a little easier. On top of these, CMake's built-in `find-package` and `FetchContent` make package management a lot easier than it used to be. Want Boost? Just do `find_package(Boost)`, and then `target_link_libraries( Boost::boost)`. It gets easier still with a proper C++ dependency manager like vcpkg or Conan.

In legacy CMake, all these were set with global variables and there was no unified way to handle packages. I fully foresee going forward that at least a plurality of C++ developers will coalesce on a CMake + vcpkg (which has more packages than Conan) workflow.

[1]: https://cmake.org/cmake/help/latest/manual/cmake-generator-e...

Re: Switching from C++ to Rust

#159

Post by the_gipsy »

burntsushi wrote: post #3

The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…

Same here, go would be such a killer language if it just had sum types.

Re: Switching from C++ to Rust

#160

Post by pharmakom »

gnulinux wrote: post #87
burntsushi wrote: post #3

The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages that don't have them. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort…

This is exactly what I think too. Sum types are so powerful, I feel a lot safer in Python + mypy with sum types (`from typing import Union`) than anything with C++ [1] even though C++ has a significantly more complex type system (it's type system is TC) and Python is as type-unsafe as a language can get. C++ made this odd choice as if any complex type system is better than a simple type system. When I was a younger s…

C++ has std::variant though?
Post reply on HN