4 ms·

> That’s a heafty claim. It is certainly more complicated to write a network complication in C vs a higher level language like Go, but by no means a bad idea in

> That’s a heafty claim. It is certainly more complicated to write a network complication in C vs a higher level language like Go, but by no means a bad idea in terms of outcome. It is dangerous to write network connected applications in C. This is not a hefty claim, it's well understood in the industry and most major tech firms avoid writing new software this way. > A bigger issue may be the QPS that a cache generates, as you tend to check large quantities of values against it. So the network round trip to Redis isn’t ideal, and you may get into a situation where it’s single threaded nature becomes a bottleneck if your values are large (tho generally Redis is memory or network bounded, not CPU). For most modern deployment models of Redis, I do not think that this is correct. Redis tends to be run locally with API responders, and as such the RTT will be lost in the noise that most web frameworks introduce. Surely if there is a big RTT that is a problem, but that's not a Redis-specific problem (although the consistent tcp connections with potentially sparse usage it prefers may add knock on effects in this condition).

taywrobel 7y ago
So Memcached, Redis, and Postgres are all dangerous to use because they are written in C? Does your blanket statement apply to C++ and other C derivatives as well? If so, we lose MySQL, Oracle SQL, MS SQL. Basically every database written more than a decade ago. From what I can tell general consensus seems to be that all of those systems are pretty stable and not dangerous because of their language choice.
- KirinDave 7y ago
  > Memcached, Redis, and Postgres are all dangerous to use because they are written in C? Yes, actually. And in fact, both Redis and Memcached have been implicated in both security issues and their policy misconfigurarions have lead to widespread DDoS attacks. As for Postgres, I think most of the industry has finally stopped directly connecting postgres to the public internet. It took many years to get any of these projects as stable as they are, and all have had major security issues in that path. You should expect those problems if you start a new project in C, with roughly the same lifecycle. Even if you play it in fast forward (say, 25% faster) you're still in for years of major security and stability issues. This seems ill considered in 2019. > Does your blanket statement apply to C++ and other C derivatives as well? If so, we lose MySQL, Oracle SQL, MS SQL. Basically every database written more than a decade ago. No, although you really need to stick to the libraries to make C++ safe. Bare pointer handling and falling back on C-like semantics is dangerous. > From what I can tell general consensus seems to be that all of those systems are pretty stable and not dangerous because of their language choice. I'm not sure how we'd directly measure it. Most folks I know trust Memcached slightly more than Redis because its smaller, but consider both to be risky and best when not directly connected to the public internet, as is common with MySQL and Postgres.
  - esotericn 7y ago
    Is this fair? Pretty much _all_ backend software is 'dangerous' when connected to the public internet. It's fairly rare for anything other than say HTTP(S) and SSH to be exposed unless absolutely necessary. It's not like it's difficult to cock up authentication in Rust, for example.
    - KirinDave 7y ago
      > Pretty much _all_ backend software is 'dangerous' when connected to the public internet. Yes, software security is hard. That's why you shouldn't make it harder by using a language that has tons of undefined behavior unless you have to.
- sagichmal 7y ago
  On this KirinDave is absolutely correct. Those systems are stable in spite of the language choice; anyone seeking to do similar work today would be professionally negligent to choose C.

taywrobel 7y ago

So Memcached, Redis, and Postgres are all dangerous to use because they are written in C? Does your blanket statement apply to C++ and other C derivatives as well? If so, we lose MySQL, Oracle SQL, MS SQL. Basically every database written more than a decade ago. From what I can tell general consensus seems to be that all of those systems are pretty stable and not dangerous because of their language choice.

KirinDave 7y ago
> Memcached, Redis, and Postgres are all dangerous to use because they are written in C? Yes, actually. And in fact, both Redis and Memcached have been implicated in both security issues and their policy misconfigurarions have lead to widespread DDoS attacks. As for Postgres, I think most of the industry has finally stopped directly connecting postgres to the public internet. It took many years to get any of these projects as stable as they are, and all have had major security issues in that path. You should expect those problems if you start a new project in C, with roughly the same lifecycle. Even if you play it in fast forward (say, 25% faster) you're still in for years of major security and stability issues. This seems ill considered in 2019. > Does your blanket statement apply to C++ and other C derivatives as well? If so, we lose MySQL, Oracle SQL, MS SQL. Basically every database written more than a decade ago. No, although you really need to stick to the libraries to make C++ safe. Bare pointer handling and falling back on C-like semantics is dangerous. > From what I can tell general consensus seems to be that all of those systems are pretty stable and not dangerous because of their language choice. I'm not sure how we'd directly measure it. Most folks I know trust Memcached slightly more than Redis because its smaller, but consider both to be risky and best when not directly connected to the public internet, as is common with MySQL and Postgres.
- esotericn 7y ago
  Is this fair? Pretty much _all_ backend software is 'dangerous' when connected to the public internet. It's fairly rare for anything other than say HTTP(S) and SSH to be exposed unless absolutely necessary. It's not like it's difficult to cock up authentication in Rust, for example.
  - KirinDave 7y ago
    > Pretty much _all_ backend software is 'dangerous' when connected to the public internet. Yes, software security is hard. That's why you shouldn't make it harder by using a language that has tons of undefined behavior unless you have to.
sagichmal 7y ago
On this KirinDave is absolutely correct. Those systems are stable in spite of the language choice; anyone seeking to do similar work today would be professionally negligent to choose C.