9 ms·

I'm a C++ developer, and Rust looks very exciting to me. Maybe I'm optimistic, but Rust really looks like it can be a serious C++ contender in the long run. T

by davvid 12y ago

I'm a C++ developer, and Rust looks very exciting to me. Maybe I'm optimistic, but Rust really looks like it can be a serious C++ contender in the long run. Talking with other C++11/C++14 users here, the general feeling is that, yes, C++ is a good language because of the performance you can get out of it and some of the nice features that have been added, but the language carries around a lot of cruft that is unavoidable due to its age and maturity. C++ has always been an expert's language. These days it's the expert's expert language++. There are no shortages of landmines and gotchas in the C++ landscape. Modern C++ is a new language, and it really does help, but for the first time there's another language that can actually fill those same shoes. A really big deal that isn't really addressed by golang is the fact that you can produce shared libraries with rust, and call them from existing C/C++ programs through a C interface. That's a really big deal in places with a lot of legacy code. Another big deal (from the scientific computing POV) is the lack of garbage collection. Yes, GC is helpful, but replacing C++ means squeezing every last bit of performance out of your hardware. Rust does not sacrifice in this regard. I really hope that Rust has a bright future. It's almost like "C++ done right", but I would stray away from such a label since someone might Linus you and say, "there's no way to do C++ right". I also view golang as the successor to Python. It's faster, modern, addresses concurrency, and makes things easier for developers. It takes a strongly opinionated stance, and that's exactly the right choice for many problem domains. Python, unfortunately, is dead to me. The GIL is a deal-breaker, and even though we have lots of Python code in production, I can definitely see a future where Python is phased out in favor of something like golang. Basically, I'm bullish on Rust + Golang, neutral on C++, and slightly bearish on Python/Ruby-like languages that do not address the concurrency problem.

tedajax 12y ago
Personally I tried to like Rust but I just found it endlessly frustrating to write code in. Yeah C++ has a lot of gotchas but they're gotchas I know. I feel like the Rust compiler is just yelling at me constantly and a lot of patterns from C++ land don't really translate well into Rust code.
- adamnemecek 12y ago
  > I feel like the Rust compiler is just yelling at me constantly that's the point. if it's yelling at you you are probably doing something wrong. > and a lot of patterns from C++ land don't really translate well into Rust code that's the point, you can't really get rid of all the c++ warts without changing things
  - kibwen 12y ago
    > if it's yelling at you you are probably doing something > wrong. That's not necessarily the case, any static type system must be inherently conservative and therefore must reject some otherwise valid programs. It also takes time to learn Rust's idioms for creating cyclic data structures, and surely we can still take steps to improve our documentation to that regard.
    - Animats 12y ago
      Often, it's not at all obvious what the type inference system is doing. The borrow checker has better error messages than the type checker. As for cyclic data structures, one would often like to have a primitive which encapsulates a forward owning pointer and a backpointer tied to it, with the backpointer unable to outlive the forward pointer. That's enough to handle most tree-like structures, and doesn't require reference counts or reference-counted weak pointers. It's a compile-time concept checkable by the borrow checker. Something to think about for Rust 2. Also, for Rust 2, I'd suggest exceptions. The "new error handling model"[1] is excessively verbose. Repackaging low-level errors for the next level up requires considerable coding. I understand the big problem with exceptions is what to do about unsafe code. I'd suggest "just say no". Unsafe blocks cannot raise exceptions. If an exception in safe code unwinds into an "unsafe" block, it becomes a panic. Unsafe code in Rust is usually to interface with non-Rust code. If you have unsafe sections in pure Rust code, you're probably doing it wrong. The secret of exception sanity is a standard exception hierarchy, like Python's. Catching an exception class in Python also gets all its subclasses. "EnvironmentError" covers all I/O errors, network errors, and such, but doesn't cover internal program errors. New user-defined exceptions are added below the most appropriate part of the standard exception hierarchy. So Python usually doesn't have Java's exception hell. If exceptions go into Rust, do it that way. Require that all exception objects descend from some predefined exception object in the standard exception hierarchy. An additional advantage of a standard exception hierarchy is that it leads to straightforward internationalization. If all the standard exceptions have translations, users get semi-reasonable error messages in their own language. If you have too many string-type error messages in a program, it's hard to handle multiple languages. Go is starting to get exceptions through the back door. People are abusing the "panic"/"recover" mechanism in Go to get exceptions.[2] Don't go there. [1] http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ [2] https://code.google.com/p/go-wiki/wiki/PanicAndRecover#Usage_in_a_Package https://code.google.com/p/go-wiki/wiki/PanicAndRecover#Usage...
mehrzad 12y ago
Isn't Go more like the new Java? Python is probably still going to grow and Ruby possibly as well, while Java is disliked fairly heavily in many communities.
- aikah 12y ago
  No Go is clearly for Rubyists/Pythonists . Java programmers will hate Go for its lack of classes,generics and other stuff like that.
  - timclark 12y ago
    I did lots of programming in Java between 1995 and 2004 when the language had no generics. I did lots of programming in C++ prior to 1995 when it barely had generics. Now I do a fair amount of programming in Go and I don't really miss generics.
    - aikah 12y ago
      Well, just have a look at gosearch and see all the generic generators poping up in Go. Most developers want generics period. By the way while Java didn't have generics before Java reflection and static polymorphism could make up for them. C++ has a preprocessor so even without template you can do generic programming. Go has ... code generation that isn't even triggered by Go compiler.
    - aros 12y ago
      How can you missing something that you have never experienced?
  - threeseed 12y ago
    Java programmers don't hate Go and isn't classes, generics that make the difference. It is the fact that pretty much every single problem every experienced has a Java library somewhere. Java is a complex, mess of a platform for a reason.
  - mehrzad 12y ago
    I meant more that Go and Java are statically typed and GC-based and are both *(while FOSS) are controlled by major software corps and grow quickly.
hendzen 12y ago
I think C++ has a very bright future - due to two driving forces: 1) The C++ Standards committee has been doing a very, very good job. Aside from the big one (compiler enforced memory safety), some of the best Rust features are on their way into C++. For example: - Traits: C++ concepts are on their way - there is even a working implementation in a gcc branch. - Iterators: See Eric Niebler's range proposal and accompanying range-v3 library. - Monadic error types (including do-notation!) proposal: http://www.hyc.io/boost/expected-proposal.pdf http://www.hyc.io/boost/expected-proposal.pdf Other great stuff coming to C++ over the next few years: - ASIO in the standard library - see prototype here: https://github.com/chriskohlhoff/asio https://github.com/chriskohlhoff/asio - Resumable functions - Composable futures - Parallel algorithms + concurrent containers ... much much more 2) Clang/Libc++ development is unbelievably rapid and it has greatly improved the tooling available to C++ developers. Some highlights here: - Clang-format and clang-tidy to help developers write cleaner code - Sanitizers like AddressSanitizer, MemorySanitizer, ThreadSanitizer, UndefinedBehaviorSanitizer that instrument binaries to find bugs at runtime - Much better error messages for template heavy code - an API for easy development of custom tools that parse/consume C++ code ... much more
- jdub 12y ago
  Because adding more things to C++ will make C++ better. :-)
  - kbenson 12y ago
    Short, succinct, and utterly inscrutable[1]. ;) 1: http://en.wikipedia.org/wiki/Poe%27s_law http://en.wikipedia.org/wiki/Poe%27s_law
- heinrich5991 12y ago
  Sanitizers only help find bugs that are actually triggered. Security vulnerabilties usually come from code paths that are not commonly exercised.
  - makomk 12y ago
odiroot 12y ago
Whoa, how is Go a successor to Python, with completely different philosophy? Especially considering static typing. It's light years closer to C++.
- threeseed 12y ago
  I would disagree with it being a successor to Python likewise I disagree that it is close to C++. It is more like Java 1.0. A simple, fast and approachable platform for building smaller server side systems apps. I just can't imagine anyone writing larger, monolithic apps with it. Whilst people have been doing it with C++ for decades. Then again Go is in its infancy so will be interesting to see which direction it does take.
  - zuzun 12y ago
    Have you ever programmed C? Almost everything Go has is somehow related to C. Of Nim, Rust and Go, it's Go whose the closest programming language to C. That said, Go is the least suitable C replacement of these three.
    - threeseed 12y ago
      Yes. And it's less about the language and more about the platform. There is an ecosystem around C/C++ for supporting large codebases. There isn't anything like it (yet) for Go. And to be honest given that there is a gap in the "market" for a microservices language I can't imagine much being built in the future.
      - bkeroack 12y ago
        There is an ecosystem around C/C++ for supporting large codebases. There isn't anything like it (yet) for Go. Sorry, does not compute. Go was specifically designed for large teams and big codebases. While I find the new features of modern C++ interesting, the (lack of) tooling is what keeps me away. I simply refuse to write Makefiles or deal with preprocessor nonsense in 2015. "go build" just works. "import github.com/foo/bar" just works. "go test", "go test -bench" just work. Etc.
fnord123 12y ago
>slightly bearish on Python/Ruby-like languages that do not address the concurrency problem. I can understand this in the context of server side development. But Python is gaining ground in data analysis.

by davvid 12y ago

tedajax 12y ago

Personally I tried to like Rust but I just found it endlessly frustrating to write code in. Yeah C++ has a lot of gotchas but they're gotchas I know. I feel like the Rust compiler is just yelling at me constantly and a lot of patterns from C++ land don't really translate well into Rust code.

adamnemecek 12y ago
> I feel like the Rust compiler is just yelling at me constantly that's the point. if it's yelling at you you are probably doing something wrong. > and a lot of patterns from C++ land don't really translate well into Rust code that's the point, you can't really get rid of all the c++ warts without changing things
- kibwen 12y ago
  > if it's yelling at you you are probably doing something > wrong. That's not necessarily the case, any static type system must be inherently conservative and therefore must reject some otherwise valid programs. It also takes time to learn Rust's idioms for creating cyclic data structures, and surely we can still take steps to improve our documentation to that regard.
  - Animats 12y ago
    Often, it's not at all obvious what the type inference system is doing. The borrow checker has better error messages than the type checker. As for cyclic data structures, one would often like to have a primitive which encapsulates a forward owning pointer and a backpointer tied to it, with the backpointer unable to outlive the forward pointer. That's enough to handle most tree-like structures, and doesn't require reference counts or reference-counted weak pointers. It's a compile-time concept checkable by the borrow checker. Something to think about for Rust 2. Also, for Rust 2, I'd suggest exceptions. The "new error handling model"[1] is excessively verbose. Repackaging low-level errors for the next level up requires considerable coding. I understand the big problem with exceptions is what to do about unsafe code. I'd suggest "just say no". Unsafe blocks cannot raise exceptions. If an exception in safe code unwinds into an "unsafe" block, it becomes a panic. Unsafe code in Rust is usually to interface with non-Rust code. If you have unsafe sections in pure Rust code, you're probably doing it wrong. The secret of exception sanity is a standard exception hierarchy, like Python's. Catching an exception class in Python also gets all its subclasses. "EnvironmentError" covers all I/O errors, network errors, and such, but doesn't cover internal program errors. New user-defined exceptions are added below the most appropriate part of the standard exception hierarchy. So Python usually doesn't have Java's exception hell. If exceptions go into Rust, do it that way. Require that all exception objects descend from some predefined exception object in the standard exception hierarchy. An additional advantage of a standard exception hierarchy is that it leads to straightforward internationalization. If all the standard exceptions have translations, users get semi-reasonable error messages in their own language. If you have too many string-type error messages in a program, it's hard to handle multiple languages. Go is starting to get exceptions through the back door. People are abusing the "panic"/"recover" mechanism in Go to get exceptions.[2] Don't go there. [1] http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ http://lucumr.pocoo.org/2014/11/6/error-handling-in-rust/ [2] https://code.google.com/p/go-wiki/wiki/PanicAndRecover#Usage_in_a_Package https://code.google.com/p/go-wiki/wiki/PanicAndRecover#Usage...

mehrzad 12y ago

Isn't Go more like the new Java? Python is probably still going to grow and Ruby possibly as well, while Java is disliked fairly heavily in many communities.

aikah 12y ago
No Go is clearly for Rubyists/Pythonists . Java programmers will hate Go for its lack of classes,generics and other stuff like that.
- timclark 12y ago
  I did lots of programming in Java between 1995 and 2004 when the language had no generics. I did lots of programming in C++ prior to 1995 when it barely had generics. Now I do a fair amount of programming in Go and I don't really miss generics.
  - aikah 12y ago
    Well, just have a look at gosearch and see all the generic generators poping up in Go. Most developers want generics period. By the way while Java didn't have generics before Java reflection and static polymorphism could make up for them. C++ has a preprocessor so even without template you can do generic programming. Go has ... code generation that isn't even triggered by Go compiler.
  - aros 12y ago
    How can you missing something that you have never experienced?
- threeseed 12y ago
  Java programmers don't hate Go and isn't classes, generics that make the difference. It is the fact that pretty much every single problem every experienced has a Java library somewhere. Java is a complex, mess of a platform for a reason.
- mehrzad 12y ago
  I meant more that Go and Java are statically typed and GC-based and are both *(while FOSS) are controlled by major software corps and grow quickly.

hendzen 12y ago

I think C++ has a very bright future - due to two driving forces: 1) The C++ Standards committee has been doing a very, very good job. Aside from the big one (compiler enforced memory safety), some of the best Rust features are on their way into C++. For example: - Traits: C++ concepts are on their way - there is even a working implementation in a gcc branch. - Iterators: See Eric Niebler's range proposal and accompanying range-v3 library. - Monadic error types (including do-notation!) proposal: http://www.hyc.io/boost/expected-proposal.pdf http://www.hyc.io/boost/expected-proposal.pdf Other great stuff coming to C++ over the next few years: - ASIO in the standard library - see prototype here: https://github.com/chriskohlhoff/asio https://github.com/chriskohlhoff/asio - Resumable functions - Composable futures - Parallel algorithms + concurrent containers ... much much more 2) Clang/Libc++ development is unbelievably rapid and it has greatly improved the tooling available to C++ developers. Some highlights here: - Clang-format and clang-tidy to help developers write cleaner code - Sanitizers like AddressSanitizer, MemorySanitizer, ThreadSanitizer, UndefinedBehaviorSanitizer that instrument binaries to find bugs at runtime - Much better error messages for template heavy code - an API for easy development of custom tools that parse/consume C++ code ... much more

jdub 12y ago
Because adding more things to C++ will make C++ better. :-)
- kbenson 12y ago
  Short, succinct, and utterly inscrutable[1]. ;) 1: http://en.wikipedia.org/wiki/Poe%27s_law http://en.wikipedia.org/wiki/Poe%27s_law
heinrich5991 12y ago
Sanitizers only help find bugs that are actually triggered. Security vulnerabilties usually come from code paths that are not commonly exercised.
- makomk 12y ago

odiroot 12y ago

Whoa, how is Go a successor to Python, with completely different philosophy? Especially considering static typing. It's light years closer to C++.

threeseed 12y ago
I would disagree with it being a successor to Python likewise I disagree that it is close to C++. It is more like Java 1.0. A simple, fast and approachable platform for building smaller server side systems apps. I just can't imagine anyone writing larger, monolithic apps with it. Whilst people have been doing it with C++ for decades. Then again Go is in its infancy so will be interesting to see which direction it does take.
- zuzun 12y ago
  Have you ever programmed C? Almost everything Go has is somehow related to C. Of Nim, Rust and Go, it's Go whose the closest programming language to C. That said, Go is the least suitable C replacement of these three.
  - threeseed 12y ago
    Yes. And it's less about the language and more about the platform. There is an ecosystem around C/C++ for supporting large codebases. There isn't anything like it (yet) for Go. And to be honest given that there is a gap in the "market" for a microservices language I can't imagine much being built in the future.
    - bkeroack 12y ago
      There is an ecosystem around C/C++ for supporting large codebases. There isn't anything like it (yet) for Go. Sorry, does not compute. Go was specifically designed for large teams and big codebases. While I find the new features of modern C++ interesting, the (lack of) tooling is what keeps me away. I simply refuse to write Makefiles or deal with preprocessor nonsense in 2015. "go build" just works. "import github.com/foo/bar" just works. "go test", "go test -bench" just work. Etc.

fnord123 12y ago

>slightly bearish on Python/Ruby-like languages that do not address the concurrency problem. I can understand this in the context of server side development. But Python is gaining ground in data analysis.