9 ms·

It’s safer than C++, sure, but half of other languages are safer. Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to inte

It’s safer than C++, sure, but half of other languages are safer. Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Same with JS & TS. When people move from C++ to another language for more safety, Rust is not their only option. Couple decades ago everything was written in C or C++. Desktop apps, mobile apps, web servers (cgi-bin, then COM objects for asp.classic). People wanted higher level, easier to use, faster to compile, and safer languages. Java was the first popular one, then C#, then the rest of them followed. C++ is continuing to lose the market it once had. 15 years ago, people generally stopped using C++ for web servers. Some still do for unusual requirements, but most people don’t. 10 years ago, most people stopped programmed mobile apps in C++ (I did before that time, for WinCE and PalmOS), now it’s mostly managed languages there. Recently the same happened for desktop apps, no one likes Electron but it does the job, and people do use the software. Embedded and videogames have already started the transition, IMO. Moving from C++ to better languages is a long trend, the industry is doing it for decades now. I don’t think Rust is a universally good option for that. Has issues with usability, labor market, libraries, platform support, and community. Good one for niche stuff, like some components of a web browser, or a bare metal hypervisor, but that’s it.

pcwalton 7y ago
I agree that there are many other fine languages that people should be considering.
0815test 7y ago
> When people move from C++ to another language for more safety, Rust is not their only option. That's arguably missing the point. For a very long time, managed, GC-based languages like Java or Go were the only option for workable memory safety! (Yes, I'm ignoring a lot of stuff because it's practically irrelevant. No need to tell me about ATS and the like, thank you so much.) Cyclone and now Rust have changed that, which makes for a real paradigm shift in the industry, at least potentially. Rust even contributes meaningfully to thread safety by getting rid of simple data races, which are a huge can of worms not just in C/C++ but managed languages as well!
- Const-me 7y ago
  > which are a huge can of worms not just in C/C++ but managed languages as well Multithreading with mutable shared state is harder in general. That's language agnostic. But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. This is language-agnostic too, I've tried doing same in C++ and it works, e.g. https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/DxVisuals/Hlsl/Async/CompileWorker.h https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... but with a GC and async-await it's much easier. > which makes for a real paradigm shift in the industry, at least potentially I think for most people, getting stuff done is more important than shifting paradigms. Rust is less productive than managed languages (GC helps, BC interferes), compiles slow, slightly less safe. For network people, golang is quite popular already, .NET core wants there, too. Game developers use too much C++ libraries, don't need security (console games are sandboxed or run under HW hypervisor), their most painful C++ issue is build time, and Rust is even worse. Low-level embedded, driver, linux OS kernel developers need C, too much integration and too many weird target platforms. HPC and ML people need manual SIMD and corresponding libraries. CUDA people need nVidia support. Open a job board, type C++ and press search. Do you see many positions except listed above, where people are still writing C++?
  - ComputerGuru 7y ago
    > But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. C# certainly never worked like that. `System.Threading.Thread` was the backbone of its concurrency model, together with everyone’s favorite auto/manual reset events, mutexes, and semaphores. While with .NET Core there are some libraries providing channels seeing adoption, the majority of the decline of threads in both legacy and Core .NET is from the move to async everything, which really obviates most of the need the casual developer has for dealing with concurrency primitives (at the cost of being absolutely dumbstruck when the abstraction leaks, obviously). Redmond did an incredible job updating basically every single API in the BCL for async (contrast to the pathetically slow going in the world of nodejs).
bluejekyll 7y ago
> Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Isn’t all JNI code in Java considered unsafe? Then there is http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/ http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot...
- Const-me 7y ago
  JNI is what I meant by "hard to interop with". That second thing is fine I think, the docs say "Although the class and all methods are public, use of this class is limited because only trusted code can obtain instances of it." Similar policies are in .NET and they work well IMO, you can compile a .NET DLL with /unsafe but most people leave default options, then both compiler and runtime verify that it's true. Other way works too, set up the VM to partial trust and you won't be able to access native memory at all, except memory in managed arrays and structures.
  - bluejekyll 7y ago
    But this isn’t different in Rust. unsafe is generally only reserved for low level features. In the trust-dns libraries, there’s not a single line of unsafe code, whereas in the Postgres extension library I’ve been working with some others on there’s a ton of unsafe for ffi with the C. Even with that, the intention is that for most users, they’ll never have to write unsafe. Just because of the presence of unsafe (which still guarantees more in Rust than C), doesn’t mean that the entire codebase is unsafe. This is a nitpick that is used to malign Rust, but really it’s a freedom to implement as low or high level functionality as you want, with out cumbersome interfaces like JNI or even JVM features in Java.
    - Const-me 7y ago
      .NET or Java sandbox is extremely hard to escape unless you have a door open. It's borderline impossible. Their byte code is simple, the runtime has a chance to check which classes are created or what pointers are accessed. It then has complete supervision over the program as it's running. Escaping Rust sandbox is a short keyword away. That keyword is used all over codebase, in both standard and third party libraries, to implement these lower-level features, or overcome language limitations. You can't disable it because you'd loose vectors and strings. > really it’s a freedom to implement as low or high level functionality as you want I'm a C++ and C# developer. I often use both in the same software, and I think my difference in levels is wider. On the lower level I have SIMD intrinsics, simple but very fast unsafe data structures, manual control over RAM layout. On the higher level I have LINQ, async-await has been working for a decade now, reflection. > with out cumbersome interfaces like JNI Here it's not too bad. C-style interop i.e. [DllImport] just works, even on ARM Linux where it loads .so libraries. On Windows, COM interop allows to export C++ objects from C DLLs, or expose .NET objects to C++, or move ownership either way. Some boilerplate is required on Linux to expose OO APIs without IUnknown.
pcwalton 7y ago
> Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Look at Android system libraries. They use JNI all over the place.
- pjmlp 7y ago
  You mean like using unsafe all over the place in many third party Rust libraries? Also Android is a poster child that Google hiring practices don't lead to the best quality of code implementation.
  - pcwalton 7y ago
    > You mean like using unsafe all over the place in many third party Rust libraries? Yes? I don't think Rust is particularly more, or less, memory safe in practice than Java. They're both memory-safe languages.
    - pjmlp 7y ago
      Ah sorry, I misunderstood your remark then.
ncmncm 7y ago
> C++ is continuing to lose the market it once had. This is an amusing remark. The number of C++ programmers is growing faster than ever, C++ discussion boards are busier than ever, and attendance at C++ conferences is higher than ever, and the growth rate is increasing. The number of C++ programmers is growing at a far, far greater rate than of Rust programmers. It's the difference between fads and real trends. C++ is where the hard work gets done. The language had a renaissance in 2011, and is no longer what it was. Moving to a better language is easier than ever, because C++ is that language. C++14 is better than C++11, C++17 is better than C++14, and C++20 will be way better than C++17. Talk about safety is misplaced. Modern C++ is as safe as any language you can name. Of course there are (literally!) many billions of lines of old code, most of it nothing to write home about. But it's overwhelmingly easier and safer to modernize it than to rewrite it. Save rewriting for C, where it makes the most difference; then, rewrite it incrementally in C++, keeping it fully functional at all times. The safest code is code you don't have to write at all, because it's in a fast, powerful, well-tested library you can just call. C++, overwhelmingly more than other languages, is focused on enabling powerful libraries you won't be tempted to bypass, for speed or because it might be a PITA to use. As a direct consequence of that focus, we have the libraries. Talk about Java or C# as "better" languages makes me laugh. The number of bugs is proportional to the lines of code. Such infamously prolix languages provide fertile soil for bugs, even neglecting their poorer library support. Rust is an interesting modern language that is relatively good for writing libraries in. It is a sound choice anywhere that the alternative would be C, Go, or Java, provided tool maturity and coder availability are not serious concerns. It is a somewhat risky choice, because it is still far from clear whether it will still be growing in five years, but so far so good.
- MaxBarraclough 7y ago
  > Modern C++ is as safe as any language you can name It absolutely isn't. C++ will always have the looming spectre of undefined behaviour. I've seen repeated instances of undefined behaviour in respected textbooks: initializing a struct by zeroing it out with memset. It'll probably continue to work fine on MSVC/x64, but presumably the (very knowledgeable!) author didn't realise C++ doesn't guarantee that null will be bitwise zero. Or perhaps they didn't care, and were fine with introducing undefined behaviour into their example code (the kind of sloppiness that demonstrates the value of safe languages). I suppose you could argue that isn't modern C++, but that would be weak sauce given that we're discussing the safety of the language.

pcwalton 7y ago

I agree that there are many other fine languages that people should be considering.

0815test 7y ago

> When people move from C++ to another language for more safety, Rust is not their only option. That's arguably missing the point. For a very long time, managed, GC-based languages like Java or Go were the only option for workable memory safety! (Yes, I'm ignoring a lot of stuff because it's practically irrelevant. No need to tell me about ATS and the like, thank you so much.) Cyclone and now Rust have changed that, which makes for a real paradigm shift in the industry, at least potentially. Rust even contributes meaningfully to thread safety by getting rid of simple data races, which are a huge can of worms not just in C/C++ but managed languages as well!

Const-me 7y ago
> which are a huge can of worms not just in C/C++ but managed languages as well Multithreading with mutable shared state is harder in general. That's language agnostic. But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. This is language-agnostic too, I've tried doing same in C++ and it works, e.g. https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/DxVisuals/Hlsl/Async/CompileWorker.h https://github.com/Const-me/vis_avs_dx/blob/master/avs_dx/Dx... but with a GC and async-await it's much easier. > which makes for a real paradigm shift in the industry, at least potentially I think for most people, getting stuff done is more important than shifting paradigms. Rust is less productive than managed languages (GC helps, BC interferes), compiles slow, slightly less safe. For network people, golang is quite popular already, .NET core wants there, too. Game developers use too much C++ libraries, don't need security (console games are sandboxed or run under HW hypervisor), their most painful C++ issue is build time, and Rust is even worse. Low-level embedded, driver, linux OS kernel developers need C, too much integration and too many weird target platforms. HPC and ML people need manual SIMD and corresponding libraries. CUDA people need nVidia support. Open a job board, type C++ and press search. Do you see many positions except listed above, where people are still writing C++?
- ComputerGuru 7y ago
  > But it's easier to do correctly the way managed languages do. They don't usually create threads, they use thread pool and post messages to each other. C# certainly never worked like that. `System.Threading.Thread` was the backbone of its concurrency model, together with everyone’s favorite auto/manual reset events, mutexes, and semaphores. While with .NET Core there are some libraries providing channels seeing adoption, the majority of the decline of threads in both legacy and Core .NET is from the move to async everything, which really obviates most of the need the casual developer has for dealing with concurrency primitives (at the cost of being absolutely dumbstruck when the abstraction leaks, obviously). Redmond did an incredible job updating basically every single API in the BCL for async (contrast to the pathetically slow going in the world of nodejs).

bluejekyll 7y ago

> Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Isn’t all JNI code in Java considered unsafe? Then there is http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot-unsafe/ http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot...

Const-me 7y ago
JNI is what I meant by "hard to interop with". That second thing is fine I think, the docs say "Although the class and all methods are public, use of this class is limited because only trusted code can obtain instances of it." Similar policies are in .NET and they work well IMO, you can compile a .NET DLL with /unsafe but most people leave default options, then both compiler and runtime verify that it's true. Other way works too, set up the VM to partial trust and you won't be able to access native memory at all, except memory in managed arrays and structures.
- bluejekyll 7y ago
  But this isn’t different in Rust. unsafe is generally only reserved for low level features. In the trust-dns libraries, there’s not a single line of unsafe code, whereas in the Postgres extension library I’ve been working with some others on there’s a ton of unsafe for ffi with the C. Even with that, the intention is that for most users, they’ll never have to write unsafe. Just because of the presence of unsafe (which still guarantees more in Rust than C), doesn’t mean that the entire codebase is unsafe. This is a nitpick that is used to malign Rust, but really it’s a freedom to implement as low or high level functionality as you want, with out cumbersome interfaces like JNI or even JVM features in Java.
  - Const-me 7y ago
    .NET or Java sandbox is extremely hard to escape unless you have a door open. It's borderline impossible. Their byte code is simple, the runtime has a chance to check which classes are created or what pointers are accessed. It then has complete supervision over the program as it's running. Escaping Rust sandbox is a short keyword away. That keyword is used all over codebase, in both standard and third party libraries, to implement these lower-level features, or overcome language limitations. You can't disable it because you'd loose vectors and strings. > really it’s a freedom to implement as low or high level functionality as you want I'm a C++ and C# developer. I often use both in the same software, and I think my difference in levels is wider. On the lower level I have SIMD intrinsics, simple but very fast unsafe data structures, manual control over RAM layout. On the higher level I have LINQ, async-await has been working for a decade now, reflection. > with out cumbersome interfaces like JNI Here it's not too bad. C-style interop i.e. [DllImport] just works, even on ARM Linux where it loads .so libraries. On Windows, COM interop allows to export C++ objects from C DLLs, or expose .NET objects to C++, or move ownership either way. Some boilerplate is required on Linux to expose OO APIs without IUnknown.

pcwalton 7y ago

> Java doesn’t have unsafe code at all, not even in standard library, and it’s very hard to interop with. Look at Android system libraries. They use JNI all over the place.

pjmlp 7y ago
You mean like using unsafe all over the place in many third party Rust libraries? Also Android is a poster child that Google hiring practices don't lead to the best quality of code implementation.
- pcwalton 7y ago
  > You mean like using unsafe all over the place in many third party Rust libraries? Yes? I don't think Rust is particularly more, or less, memory safe in practice than Java. They're both memory-safe languages.
  - pjmlp 7y ago
    Ah sorry, I misunderstood your remark then.

ncmncm 7y ago

> C++ is continuing to lose the market it once had. This is an amusing remark. The number of C++ programmers is growing faster than ever, C++ discussion boards are busier than ever, and attendance at C++ conferences is higher than ever, and the growth rate is increasing. The number of C++ programmers is growing at a far, far greater rate than of Rust programmers. It's the difference between fads and real trends. C++ is where the hard work gets done. The language had a renaissance in 2011, and is no longer what it was. Moving to a better language is easier than ever, because C++ is that language. C++14 is better than C++11, C++17 is better than C++14, and C++20 will be way better than C++17. Talk about safety is misplaced. Modern C++ is as safe as any language you can name. Of course there are (literally!) many billions of lines of old code, most of it nothing to write home about. But it's overwhelmingly easier and safer to modernize it than to rewrite it. Save rewriting for C, where it makes the most difference; then, rewrite it incrementally in C++, keeping it fully functional at all times. The safest code is code you don't have to write at all, because it's in a fast, powerful, well-tested library you can just call. C++, overwhelmingly more than other languages, is focused on enabling powerful libraries you won't be tempted to bypass, for speed or because it might be a PITA to use. As a direct consequence of that focus, we have the libraries. Talk about Java or C# as "better" languages makes me laugh. The number of bugs is proportional to the lines of code. Such infamously prolix languages provide fertile soil for bugs, even neglecting their poorer library support. Rust is an interesting modern language that is relatively good for writing libraries in. It is a sound choice anywhere that the alternative would be C, Go, or Java, provided tool maturity and coder availability are not serious concerns. It is a somewhat risky choice, because it is still far from clear whether it will still be growing in five years, but so far so good.

MaxBarraclough 7y ago
> Modern C++ is as safe as any language you can name It absolutely isn't. C++ will always have the looming spectre of undefined behaviour. I've seen repeated instances of undefined behaviour in respected textbooks: initializing a struct by zeroing it out with memset. It'll probably continue to work fine on MSVC/x64, but presumably the (very knowledgeable!) author didn't realise C++ doesn't guarantee that null will be bitwise zero. Or perhaps they didn't care, and were fine with introducing undefined behaviour into their example code (the kind of sloppiness that demonstrates the value of safe languages). I suppose you could argue that isn't modern C++, but that would be weak sauce given that we're discussing the safety of the language.