Rust Developers Planning For The Rust 1.0 Language

[mark45]

What, what?!


It's memory safe, which C++ isn't and also it have a better and easier multi thread model.

What exactly means memory safe? If you think about it - there's no such thing as "memory safe", even in Java you have Null pointer exception despite Java having no such thing as pointers.

So "memory safe" doesn't do what the name implies and realistically dealing with pointers isn't nearly that big of a deal to warran a language transition, as a C++ and ex-Java guy I'm actually fond of pointers because you don't have unexpected, behind the curtain "optimizations".

The "better" multi thread model isn't any better except that it's a cosmetic arrangement around (hopefully) native (Linux and other OS kernels') threads. JavaScript, Qt (the toolkit) have "better" multithreading but still they're not "better", they're just handier to write, and abstracted from the OS, and dumber because don't allow for advanced features if you used pthreads etc directly.

And you still have to learn about and obey the memory visibility of the hw/language if you do multithreading, so you don't really get much relief as a programmer.

So I haven't heard of any killer feature of Rust warranting a transition from C/C++.

[Pajn]

What exactly means memory safe? If you think about it - there's no such thing as "memory safe", even in Java you have Null pointer exception despite Java having no such thing as pointers.

So "memory safe" doesn't do what the name implies and realistically dealing with pointers isn't nearly that big of a deal to warran a language transition, as a C++ and ex-Java guy I'm actually fond of pointers because you don't have unexpected, behind the curtain "optimizations".

In Java you get an exception when trying to do stuff on a null reference (NPE), not garbage data that may be harmful.
Neither you can get into other variables like you can with C/C++. And yeah you have 'unexpected, behind the curtain "optimizations"'
in C++ too, it's done by the compiler.

The "better" multi thread model isn't any better except that it's a cosmetic arrangement around (hopefully) native (Linux and other OS kernels') threads. JavaScript, Qt (the toolkit) have "better" multithreading but still they're not "better", they're just handier to write, and abstracted from the OS, and dumber because don't allow for advanced features if you used pthreads etc directly.

And you still have to learn about and obey the memory visibility of the hw/language if you do multithreading, so you don't really get much relief as a programmer.

Rust have support for cheap threads like Go wich are not just a wraper for the native OS threads (as they aren't cheap).
Rust also have support for totally isolated threads (not memory visible to each other).

[Szzz]

even in Java you have Null pointer exception despite Java having no such thing as pointers.

But not in Rust, dereferencing Null pointer will not even compile.

[MartinN]

What exactly means memory safe? If you think about it - there's no such thing as "memory safe", even in Java you have Null pointer exception despite Java having no such thing as pointers.

So "memory safe" doesn't do what the name implies and realistically dealing with pointers isn't nearly that big of a deal to warran a language transition, as a C++ and ex-Java guy I'm actually fond of pointers because you don't have unexpected, behind the curtain "optimizations".

The "better" multi thread model isn't any better except that it's a cosmetic arrangement around (hopefully) native (Linux and other OS kernels') threads. JavaScript, Qt (the toolkit) have "better" multithreading but still they're not "better", they're just handier to write, and abstracted from the OS, and dumber because don't allow for advanced features if you used pthreads etc directly.

And you still have to learn about and obey the memory visibility of the hw/language if you do multithreading, so you don't really get much relief as a programmer.

So I haven't heard of any killer feature of Rust warranting a transition from C/C++.

There are many ('killer') features - precluding the possibility of dangling (or event wild/uninit-ed) pointers... which requires skill/experience/thoughtfulness/discipline in C++ to prevent... Another thing that always annoyed me about C++ is the addition of the 'reference of' (&) operator, always seemed unnecessary to me..... The syntax too, over time has gotten fugly - unless one typedefs a whole lot in an effort to break down, you could end up with horribly looking type declarations that would make your head spin before you decipher them ... especially if you use C++ on and off like I do, since I alternate to Java a lot as well and haven't kept up with all the updates to the standard...

With a lot of discipline/experience, wise use of smart pointers, a lot of these hurdles can be overcome... but that's just it - it's an afterthought/improvement on old paradigms... there's a case to be made for inventing new - rather than improving existing paradigms. I don't expect rust will supplant C++ in the near future... anymore than Wayland/Weston or its ilk will replace X "overnight"... but if it hits a chord with devs, there's no saying where it could go... Who thought in 1996-7 Java would be what it is today, right?...

[profoundWHALE]

I don't complain about C++ but Rust is definitely the best currently at the fields that Go, C++ and D programming languages aim.

Well, IIRC, C++ is basically C and extensions. It came to be because there were some things they wanted to do with C that they couldn't do with C.
D, gathering from what I read, was meant to be C -> C++ done how it should have been done. As in, C++ wasn't a true successor and didn't fix many of the issues that C had/has.
Rust is trying something different while aiming at the same performance level as C, C++, D. A good example is how they handle memory and multi-threaded applications. Modern language for a modern time I believe would be a decent slogan.

D tried - failed, Vala tried and failed, others tried and failed, how does Rust address the reasons why its predecessors failed?

I don't see how something can fail if it meets it's own goals...