5 ms·

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

michaelchisari 9y ago
It must depend on what you're building with it. I haven't seen any reason why it couldn't be used for serving up data for an api. But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go. That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.
shadowmint 9y ago
The point isn’t that no one does it, its that its hard to do right. ...and that is flat out the case for c++, unequivocally. In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at. Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services. Its definitely a good goal for the year~
- e12e 9y ago
  > ...and that is flat out the case for c++, unequivocally. Arguably, this is why Google made go. But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++. Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation. And that's where you're likely to encounter elder horrors lurking. [ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]
fauigerzigerk 9y ago
>Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)
- banachtarski 9y ago
  I just mentally edit "micro-services" to "services" any time I read it hehe.
  - StavrosK 9y ago
    What, do you edit the "web" out of "webscale" too? Certifiable.
  - paulddraper 9y ago
    And "REST" to "HTTP"
raverbashing 9y ago
Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code
- kbwt 9y ago
  I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known. Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.
  - sambe 9y ago
    What complexity adds up?
- civility 9y ago
  Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
  - raverbashing 9y ago
    Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.
    - duneroadrunner 9y ago
      C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
    - 9y ago
sebcat 9y ago
I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two. It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.
- pjmlp 9y ago
  Even using C++ in embedded is an issue, mostly cultural. A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that. Most recent example "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs

michaelchisari 9y ago

It must depend on what you're building with it. I haven't seen any reason why it couldn't be used for serving up data for an api. But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go. That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.

shadowmint 9y ago

The point isn’t that no one does it, its that its hard to do right. ...and that is flat out the case for c++, unequivocally. In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at. Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services. Its definitely a good goal for the year~

e12e 9y ago
> ...and that is flat out the case for c++, unequivocally. Arguably, this is why Google made go. But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++. Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation. And that's where you're likely to encounter elder horrors lurking. [ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]

fauigerzigerk 9y ago

>Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)

banachtarski 9y ago
I just mentally edit "micro-services" to "services" any time I read it hehe.
- StavrosK 9y ago
  What, do you edit the "web" out of "webscale" too? Certifiable.
- paulddraper 9y ago
  And "REST" to "HTTP"

raverbashing 9y ago

Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code

kbwt 9y ago
I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known. Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.
- sambe 9y ago
  What complexity adds up?
civility 9y ago
Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
- raverbashing 9y ago
  Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.
  - duneroadrunner 9y ago
    C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
  - 9y ago

sebcat 9y ago

I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two. It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.

pjmlp 9y ago
Even using C++ in embedded is an issue, mostly cultural. A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that. Most recent example "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs