4 ms·

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "we

by FpUser 4y ago

>"I don't understand why so many people lately seem to want to use Rust for web domain stuff." >"Rust is the new C++. Let's just stick with that." I write "web domain stuff" in C++ and it is incredibly easy (well for me at least). In C++ I could always use my own styles / paradigms / patterns etc. etc. Not forced to any particular way. And modern C++ is incredibly safe if one wishes. So if it is bad idea to write "web stuff" in Rust it means it is anything but new C++

dataangel 4y ago
Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warnings and errors on compilers don't catch it.
- lelanthran 4y ago
  > Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haskell ... "Isn't Really Safe" because it is not possible to formally verify the logic. Etc, ad infinitum ... Maybe go for "Not As Safe As". After all, I don't even like C++ (see my comment history), but it's certainly possible (and not very hard) to get about 90% of Rust safety in C++. Safety is not a binary, it's on a spectrum. Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. That's certainly not true.
  - kobebrookskC3 4y ago
    > Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... , most likely human rights activists targeted by less-than-savory regimes. memory corruption bugs are so frequent that it is possible for nso group to sell to pretty much any regime, and not forced to be classified as top secret information.
    - cozzyd 4y ago
      > i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)
      - steveklabnik 4y ago
        That one was already reported to the tracker :) https://github.com/rust-lang/rust/issues/32670 https://github.com/rust-lang/rust/issues/32670 (To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)
        cozzyd 4y ago
        Thanks, that was an amusing read!
- pjmlp 4y ago
  Not a Visual C++ user I imagine, because that is exactly what enabling _ITERATOR_DEBUG_LEVEL does.
- coderenegade 4y ago
  So we should all be using Spark Ada? Safety isn't an all or nothing thing, and in most cases, rigorous safety comes with tradeoffs. In some applications those tradeoffs are worth it, and in others they're not. A small project probably doesn't need to be provably correct, because it's easy enough to analyze it, and you aren't gaining much if the more rigorous language is unwieldy (they often are); similarly, a large enterprise project is harder to analyze, and has larger costs if there are CVEs, so a safer language is probably a good fit. Note that this doesn't necessarily mean rust, though -- garbage collected languages sit here, too. Rust sits in the niche of "big enough and / or critical enough to justify rigorous safety", and "high performance really matters".
cmrdporcupine 4y ago
I wrote plenty of vaguely web stuff in C++ at Google. A lot of services at Google are C++. But it's kind of, not how the rest of the industry expects things. And most of that stuff there is now moving to Go.
- FpUser 4y ago
  >"not how the rest of the industry expects things" I run my own company, prefer to count money and Have no shortage of work - so could not care less about what "the rest of the industry thinks".
- DeathArrow 4y ago
  >And most of that stuff there is now moving to Go. Go is on the same page performance wise with Java and C#. Sure, if you don't need the best performance, you can move to another language. But, then, why did you start using C++ in the first place?
- pjmlp 4y ago
  I doubt pretty much that SAP and Adobe would rewrite their enterprise products in Go.
est31 4y ago
> In C++ I could always use my own styles / paradigms / patterns etc. etc. That's also one of its major disadvantages, unless you literally rewrite the entire thing when major maintainer changes happen, because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it.
- StillBored 4y ago
  I don't know, I never got heavily on the C++ inheritance bandwagon when it was popular in the late 1990's early 2000's. Rather preferring aggregation. If you application is actually using the OO parts of the language that way, even without modern C++ its fairly easy to maintain as the different styles/etc area also encapsulated in their classes. Then hopefully the top level is using some kind of message passing interface/whatever to avoid trying to glue everything together into a god class. AKA, there are a few fairly easy to understand rules that allow people to do their own thing without creating a maintainability nightmare even with very large C++ codebases. If an experienced engineer/architect/etc with a track record of successful C++ projects is in charge during the initial application design/etc you should have a fairly maintainable application. I'm not sure this is really a C++ thing though, rather being a general engineering thing. If the main architecture is well thought out and understandable, a lot of sins can be burred in places where they can't create application wide chaos. There are a lot of things that can make C++ applications suck, but you don't tend to hear about the success stories on your favorite board, those systems silently do their job. So many of the things people rail about with C and C++ simply aren't problems when appropriate engineer culture is maintained. AKA, having solid unit tests for most of the base classes being agragated, means that running them under various address sanitizer/etc tools will find the errors that aren't picked up by static analysis tools/etc. Yes, sometimes things sneak by, but i'm not sure there are any languages java/rust/etc that solve that problem completely.
- jcelerier 4y ago
  > because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it. I'd be really interested in meeting someone who has enough mental flexibility to learn C++ but not enough to accommodate different code styles in a single codebase.
DeathArrow 4y ago
That's not my experience. I'm 3 times more productive at writing web apps in C# than in C++ and that is not even taking into account compile times and hot reload and doing unit tests. Maybe I'm the worst C++ programmer in history and maybe I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience. Aside from doing more boiler plate code, the language being more ceremonious, I find that I miss the tools like frameworks and libraries which are very easy to integrate with each other and which I take it for granted in C#. Probably the story is the same with any other language used for web: Java, JS, Ruby, Python and even the (in)famous PHP. I think the situation can be much better if someone would make some nicely designed frameworks and libraries, but I guess no one is interested to as C++ is perceived as a "not for web" language. People who are into C++ are generally systems programmers who are not into Web, and people who are into Web are taught they only have to use "web languages". That is really a shame because for some situations there would be a huge benefit of having performant web apps - scaling out is not always a solution to a performance problem.
- pjmlp 4y ago
  Depends on the ecosystem, while I agree with you, at least on Microsoft stack there were always nice tooling to write C++ applications for web apps. Before .NET we had ATLServer, then C++/CLI. They also published some frameworks for writing web APIs in C++. Now, I would also advise C# and then if needed, to call into C++ via P/Invoke (or C++/CLI, C++/WinRT if on Windows), than exposing C++ directly into the wire.
- FpUser 4y ago
  >"I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience." I rewrote web apps written in PHP and Python. Those were rather decent size and in my case app specific code was about the same size in C++ as in the other 2. The performance was of orders of magnitude better. My applications do not contain millions line of code and maybe because of this and the way the code is organized I do not really suffer long compiling times. Usually it is just few seconds. Good enough for me.
kaba0 4y ago
I really don't believe that this high-level low-level language thing is true. Sure, both C++ and Rust are incredibly expressive and cool languages but they want to give control for low-level details, yet make it very easy to ignore these for the most part. But there will sure come a time when you will have to (may not happen at first write, but will definitely happen at refactor, adding a new feature, etc). Managed languages make such refactors trivial, while C++ and Rust (even with its very advanced type system) make these harder due to you having to rearchitect the whole program from a memory model perspective. Sure, it can be trivial in many cases, but not always. So all in all, I really don't think that the (long-running) productivity and maintainability of managed languages can be approached by these low-level langs. And that is fine, (thank God) not everything is a dumb CRUD web app, there are very real niches where that low-level detail is a necessity.
- FpUser 4y ago
  >"Managed languages make such refactors trivial, while C++ and Rust (even with its very advanced type system) make these harder due to you having to rearchitect the whole program from a memory model perspective. Sure, it can be trivial in many cases, but not always." This is not the function of the language but the ability of the developer to properly architect their code. And tools like Visual C++ / CLion have very advanced refactoring features.

by FpUser 4y ago

dataangel 4y ago

Modern C++ isn't really safe. Safe means the compiler catches you, generally C++ compilers don't. Trivial example is iterator invalidation -- even with all warnings and errors on compilers don't catch it.

lelanthran 4y ago
> Modern C++ isn't really safe. Can we cut it out with the hyperbole? Using "It Isn't Really Safe Unless It Is Written In My Favourite Niche Language" as an argument is .. well ... ridiculous. You can extend that argument to any practical programming language. So ... Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted, where your application deadlocks, or threads starve, etc. Haskell ... "Isn't Really Safe" because it is not possible to formally verify the logic. Etc, ad infinitum ... Maybe go for "Not As Safe As". After all, I don't even like C++ (see my comment history), but it's certainly possible (and not very hard) to get about 90% of Rust safety in C++. Safety is not a binary, it's on a spectrum. Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. That's certainly not true.
- kobebrookskC3 4y ago
  > Rust ... "Isn't Really Safe" because you can get into a point where memory is corrupted i dare you to find memory corruption in safe rust that isn't already on an issue tracker. > Saying that a language is either safe or unsafe implies that the "safe" language is actually safe while the "unsafe" language is completely deadly. tell that to the people who got owned by https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... , most likely human rights activists targeted by less-than-savory regimes. memory corruption bugs are so frequent that it is possible for nso group to sell to pretty much any regime, and not forced to be classified as top secret information.
  - cozzyd 4y ago
    > i dare you to find memory corruption in safe rust that isn't already on an issue tracker. can't you just mess around with /proc/self/mem :)
    - steveklabnik 4y ago
      That one was already reported to the tracker :) https://github.com/rust-lang/rust/issues/32670 https://github.com/rust-lang/rust/issues/32670 (To be clear, I’m not saying that there’s no issues that aren’t in the tracker yet. But there are a bunch of them that are. More will absolutely be found as time goes on, that’s just how these things are.)
      - cozzyd 4y ago
        Thanks, that was an amusing read!
pjmlp 4y ago
Not a Visual C++ user I imagine, because that is exactly what enabling _ITERATOR_DEBUG_LEVEL does.
coderenegade 4y ago
So we should all be using Spark Ada? Safety isn't an all or nothing thing, and in most cases, rigorous safety comes with tradeoffs. In some applications those tradeoffs are worth it, and in others they're not. A small project probably doesn't need to be provably correct, because it's easy enough to analyze it, and you aren't gaining much if the more rigorous language is unwieldy (they often are); similarly, a large enterprise project is harder to analyze, and has larger costs if there are CVEs, so a safer language is probably a good fit. Note that this doesn't necessarily mean rust, though -- garbage collected languages sit here, too. Rust sits in the niche of "big enough and / or critical enough to justify rigorous safety", and "high performance really matters".

cmrdporcupine 4y ago

I wrote plenty of vaguely web stuff in C++ at Google. A lot of services at Google are C++. But it's kind of, not how the rest of the industry expects things. And most of that stuff there is now moving to Go.

FpUser 4y ago
>"not how the rest of the industry expects things" I run my own company, prefer to count money and Have no shortage of work - so could not care less about what "the rest of the industry thinks".
DeathArrow 4y ago
>And most of that stuff there is now moving to Go. Go is on the same page performance wise with Java and C#. Sure, if you don't need the best performance, you can move to another language. But, then, why did you start using C++ in the first place?
pjmlp 4y ago
I doubt pretty much that SAP and Adobe would rewrite their enterprise products in Go.

est31 4y ago

> In C++ I could always use my own styles / paradigms / patterns etc. etc. That's also one of its major disadvantages, unless you literally rewrite the entire thing when major maintainer changes happen, because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it.

StillBored 4y ago
I don't know, I never got heavily on the C++ inheritance bandwagon when it was popular in the late 1990's early 2000's. Rather preferring aggregation. If you application is actually using the OO parts of the language that way, even without modern C++ its fairly easy to maintain as the different styles/etc area also encapsulated in their classes. Then hopefully the top level is using some kind of message passing interface/whatever to avoid trying to glue everything together into a god class. AKA, there are a few fairly easy to understand rules that allow people to do their own thing without creating a maintainability nightmare even with very large C++ codebases. If an experienced engineer/architect/etc with a track record of successful C++ projects is in charge during the initial application design/etc you should have a fairly maintainable application. I'm not sure this is really a C++ thing though, rather being a general engineering thing. If the main architecture is well thought out and understandable, a lot of sins can be burred in places where they can't create application wide chaos. There are a lot of things that can make C++ applications suck, but you don't tend to hear about the success stories on your favorite board, those systems silently do their job. So many of the things people rail about with C and C++ simply aren't problems when appropriate engineer culture is maintained. AKA, having solid unit tests for most of the base classes being agragated, means that running them under various address sanitizer/etc tools will find the errors that aren't picked up by static analysis tools/etc. Yes, sometimes things sneak by, but i'm not sure there are any languages java/rust/etc that solve that problem completely.
jcelerier 4y ago
> because otherwise you get a mix of different C++ styles in your codebase which leads to nobody being able to maintain it. I'd be really interested in meeting someone who has enough mental flexibility to learn C++ but not enough to accommodate different code styles in a single codebase.

DeathArrow 4y ago

That's not my experience. I'm 3 times more productive at writing web apps in C# than in C++ and that is not even taking into account compile times and hot reload and doing unit tests. Maybe I'm the worst C++ programmer in history and maybe I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience. Aside from doing more boiler plate code, the language being more ceremonious, I find that I miss the tools like frameworks and libraries which are very easy to integrate with each other and which I take it for granted in C#. Probably the story is the same with any other language used for web: Java, JS, Ruby, Python and even the (in)famous PHP. I think the situation can be much better if someone would make some nicely designed frameworks and libraries, but I guess no one is interested to as C++ is perceived as a "not for web" language. People who are into C++ are generally systems programmers who are not into Web, and people who are into Web are taught they only have to use "web languages". That is really a shame because for some situations there would be a huge benefit of having performant web apps - scaling out is not always a solution to a performance problem.

pjmlp 4y ago
Depends on the ecosystem, while I agree with you, at least on Microsoft stack there were always nice tooling to write C++ applications for web apps. Before .NET we had ATLServer, then C++/CLI. They also published some frameworks for writing web APIs in C++. Now, I would also advise C# and then if needed, to call into C++ via P/Invoke (or C++/CLI, C++/WinRT if on Windows), than exposing C++ directly into the wire.
FpUser 4y ago
>"I didn't spent too much time in trying to write web apps in C++ - it was just to test if it's a viable approach - but that was my particular experience." I rewrote web apps written in PHP and Python. Those were rather decent size and in my case app specific code was about the same size in C++ as in the other 2. The performance was of orders of magnitude better. My applications do not contain millions line of code and maybe because of this and the way the code is organized I do not really suffer long compiling times. Usually it is just few seconds. Good enough for me.

kaba0 4y ago

I really don't believe that this high-level low-level language thing is true. Sure, both C++ and Rust are incredibly expressive and cool languages but they want to give control for low-level details, yet make it very easy to ignore these for the most part. But there will sure come a time when you will have to (may not happen at first write, but will definitely happen at refactor, adding a new feature, etc). Managed languages make such refactors trivial, while C++ and Rust (even with its very advanced type system) make these harder due to you having to rearchitect the whole program from a memory model perspective. Sure, it can be trivial in many cases, but not always. So all in all, I really don't think that the (long-running) productivity and maintainability of managed languages can be approached by these low-level langs. And that is fine, (thank God) not everything is a dumb CRUD web app, there are very real niches where that low-level detail is a necessity.

FpUser 4y ago
>"Managed languages make such refactors trivial, while C++ and Rust (even with its very advanced type system) make these harder due to you having to rearchitect the whole program from a memory model perspective. Sure, it can be trivial in many cases, but not always." This is not the function of the language but the ability of the developer to properly architect their code. And tools like Visual C++ / CLion have very advanced refactoring features.