6 ms·

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff that may or may not work at all, it doesn't care, which can lead to all sorts of undefined behaviour down the road. Compilers are not all created equal.

swaroop 11y ago
The new C++ Core Guidelines & Guidelines Support Library and related tools are interesting efforts to specifically solve those problems.
- Buttons840 11y ago
  If the issue is that "C++ compiles stuff that may or may not work at all" then I don't see how those guidelines will help the situation. A C++ project may or may not follow those guidelines and then we're back where we started.
  - swaroop 11y ago
    My understanding is that the tools are the answer - it's a linter that must be run before landing/merging. See https://youtu.be/hEx5DNLWGgA https://youtu.be/hEx5DNLWGgA for a demo of such tools.
    - bjz_ 11y ago
      Tools are just band-aids over an unsafe type system, and they are all too easy to ignore or never use them in the first place.
      - swaroop 11y ago
        It depends on the community. See gofmt & gometalinter in the golang community.
SomeCallMeTim 11y ago
Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.
- outworlder 11y ago
  > But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? It definitely is. This is not the usual C++ experience. You are probably sidestepping all sorts of undefined behavior due to experience alone.
  - taneq 11y ago
    This matches my experience with C++. My code has improved hugely in simplicity and robustness as I've learned which C++ features are productive and which are just minefields.
- vvanders 11y ago
  You really owe it to yourself to give Rust a shot. A lot of things that you've encoded in convention(as any good C++ programmer should) are right there at the language level. Ownership? You get an awesome sliding scale of Borrow Checker <-> Boxed <-> Rc/Arc Mutation? Covered in Copy+Clone/Cell <-> &/&mut <-> RefCell Thread Safety? Sync + Send guarantee that things which need to stay on a specific thread cannot be shared. Combine that with Sum Types, Pattern Matching and much stronger functional constructs makes for a very compelling language.
  - SomeCallMeTim 11y ago
    Rust does sound interesting, but it doesn't seem to be focused on the areas that I need right now. Go has GoRoutines, which are light threads; they can be executed on multiple CPU threads, but by default Go only allocates one CPU thread per physical CPU, even if you allocate tens of thousands of GoRoutines. For the kind of networking server code I'm writing, light threading is far more efficient than using an OS thread per connection. 25-50x faster at higher server loads. That's why I've ignored Rust to date; if Rust has light threading built in, but no one is talking about it (haven't found anything but real threads in my quick Google searches), then I'll take a look. Otherwise it will need to wait for me to have a task that Rust would be good for, and I'll stick with Go and TypeScript for the problems I'm solving right now.

swaroop 11y ago

The new C++ Core Guidelines & Guidelines Support Library and related tools are interesting efforts to specifically solve those problems.

Buttons840 11y ago
If the issue is that "C++ compiles stuff that may or may not work at all" then I don't see how those guidelines will help the situation. A C++ project may or may not follow those guidelines and then we're back where we started.
- swaroop 11y ago
  My understanding is that the tools are the answer - it's a linter that must be run before landing/merging. See https://youtu.be/hEx5DNLWGgA https://youtu.be/hEx5DNLWGgA for a demo of such tools.
  - bjz_ 11y ago
    Tools are just band-aids over an unsafe type system, and they are all too easy to ignore or never use them in the first place.
    - swaroop 11y ago
      It depends on the community. See gofmt & gometalinter in the golang community.

SomeCallMeTim 11y ago

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

outworlder 11y ago
> But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? It definitely is. This is not the usual C++ experience. You are probably sidestepping all sorts of undefined behavior due to experience alone.
- taneq 11y ago
  This matches my experience with C++. My code has improved hugely in simplicity and robustness as I've learned which C++ features are productive and which are just minefields.
vvanders 11y ago
You really owe it to yourself to give Rust a shot. A lot of things that you've encoded in convention(as any good C++ programmer should) are right there at the language level. Ownership? You get an awesome sliding scale of Borrow Checker <-> Boxed <-> Rc/Arc Mutation? Covered in Copy+Clone/Cell <-> &/&mut <-> RefCell Thread Safety? Sync + Send guarantee that things which need to stay on a specific thread cannot be shared. Combine that with Sum Types, Pattern Matching and much stronger functional constructs makes for a very compelling language.
- SomeCallMeTim 11y ago
  Rust does sound interesting, but it doesn't seem to be focused on the areas that I need right now. Go has GoRoutines, which are light threads; they can be executed on multiple CPU threads, but by default Go only allocates one CPU thread per physical CPU, even if you allocate tens of thousands of GoRoutines. For the kind of networking server code I'm writing, light threading is far more efficient than using an OS thread per connection. 25-50x faster at higher server loads. That's why I've ignored Rust to date; if Rust has light threading built in, but no one is talking about it (haven't found anything but real threads in my quick Google searches), then I'll take a look. Otherwise it will need to wait for me to have a task that Rust would be good for, and I'll stick with Go and TypeScript for the problems I'm solving right now.