5 ms·

And it does not scale to a business application that needs to be deployed independently of target systems across the world.

munk-a 6y ago
Maybe? Only if the business is actually deploying the server-side to folks. Using C++ to run data-servers is a choice you can make - one that I'd be a bit wary of since if C++ has a glaring weakness it's everything having to do with strings and I/O[1] which is going to be a big component of what you're writing. 1. C++ can do these things, and can do them quite performantly - but it takes an amount of effort far exceeding doing the same thing in say, Go or Java.
- secondcoming 6y ago
  What string weakness?
  - munk-a 6y ago
    The lack of native marshalling and unmarshalling approaches outside of the style perpetuated by sputf and no support for any on-the-go string variable injection or templating without pulling in libraries. This is a weakness that can be overcome, but it's a weakness.
    - account42 6y ago
      > without pulling in libraries I don't see having these things as separate libraries to be a weakness - this way they can evolve independently from the language and can be much more specialized.
- FpUser 6y ago
  >"C++ can do these things, and can do them quite performantly - but it takes an amount of effort far exceeding doing the same thing in say, Go or Java." Not my observation, writing business servers in modern C++ using some libraries is a piece of cake. I do not have any problems with I/O and strings either.
FpUser 6y ago
Well some applications must be able to run on IE 4.0. Granted I do not cover such cases. But I do not really care. So far my clients (from across the world mind you) do not have such requirements, hence it is not my problem. What I do have instead is stellar scalability and performance.
neogodless 6y ago
The irony for me is that I often see very small applications that use a long list of technologies... and end up taking much longer to build (and load on a client browser) than a server-side rendered application would have. To be sure, if you can accurately roadmap an application such that you can see how it's going to grow and expand across teams, then you can see where it makes sense to use frameworks to build areas, navigation, components, etc. and then be able to distribute work across teams. But often very small applications with very small teams are built in a way that is unnecessarily complex, and the expected (later) payoff never arrives.

munk-a 6y ago

Maybe? Only if the business is actually deploying the server-side to folks. Using C++ to run data-servers is a choice you can make - one that I'd be a bit wary of since if C++ has a glaring weakness it's everything having to do with strings and I/O[1] which is going to be a big component of what you're writing. 1. C++ can do these things, and can do them quite performantly - but it takes an amount of effort far exceeding doing the same thing in say, Go or Java.

secondcoming 6y ago
What string weakness?
- munk-a 6y ago
  The lack of native marshalling and unmarshalling approaches outside of the style perpetuated by sputf and no support for any on-the-go string variable injection or templating without pulling in libraries. This is a weakness that can be overcome, but it's a weakness.
  - account42 6y ago
    > without pulling in libraries I don't see having these things as separate libraries to be a weakness - this way they can evolve independently from the language and can be much more specialized.
FpUser 6y ago
>"C++ can do these things, and can do them quite performantly - but it takes an amount of effort far exceeding doing the same thing in say, Go or Java." Not my observation, writing business servers in modern C++ using some libraries is a piece of cake. I do not have any problems with I/O and strings either.

FpUser 6y ago

Well some applications must be able to run on IE 4.0. Granted I do not cover such cases. But I do not really care. So far my clients (from across the world mind you) do not have such requirements, hence it is not my problem. What I do have instead is stellar scalability and performance.

neogodless 6y ago

The irony for me is that I often see very small applications that use a long list of technologies... and end up taking much longer to build (and load on a client browser) than a server-side rendered application would have. To be sure, if you can accurately roadmap an application such that you can see how it's going to grow and expand across teams, then you can see where it makes sense to use frameworks to build areas, navigation, components, etc. and then be able to distribute work across teams. But often very small applications with very small teams are built in a way that is unnecessarily complex, and the expected (later) payoff never arrives.