5 ms·

I can see your point for small hobby projects. But enterprise web development in C++ is no fun at all. For example: "Google says that about 70% of all serious s

I can see your point for small hobby projects. But enterprise web development in C++ is no fun at all. For example: "Google says that about 70% of all serious security bugs in the Chrome codebase are related to memory management and safety." https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs... Developer time for fixing these bugs is in most cases more expensive, than to throw more hardware at your software written in a garbage collected language.

Perseids 6y ago
True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/ https://thume.ca/2020/05/17/pipes-kill-productivity/
- pas 6y ago
  I find that the big problems that k8s solve is the usual change management issues in production systems. What do we want to deploy, okay, stop monitoring/alerts, okay, flip the load balancer, install/copy/replace the image/binary, restart it, flip LB, do the other node(s), keep flipping monitoring/alerts, okay, do we need to do something else? Run DB schema change scripts? Oh fuck we forgot to do the backup before that! Also now we haven't started that dependent service, and so we have to rollback, fast, okay, screw the alerts, and the LB, just rollback all at once. And sure, all this can be scripted, run from a laptop. But k8s is basically that. ... And we get distributedness very fast, as soon as you have 2+ components that manage state you need to think about consistency. Even a simple cache is always problematic (as we all know how the cache invalidation joke). Sure, going all in on microservices just because is a bad idea. Similarly k8s is not for everyone, and running DBs on k8s isn't either. But, the state of the art is getting there. (eg the crunchydata postgresql operator for k8s.)
  - znpy 6y ago
    > I find that the big problems that k8s solve is the usual change management issues in production systems. This. I was in a company where devops was just a fancy marketing term, developers would shit out a new release and then it was our problem (we the system engineers / operations people) to make it work on customers' installations. I now work as a devops engineer in a company that does devops very well. I provide all the automation that developers need to run their services. They built it, they run it. I am of course available for consultation and support with that automation and kubernetes and very willing to help in general, but the people running the software are now the people most right for the job: those who built it. As I said in my other comment: it's really about fixing the abstractions and establishing a common lingo between developers and operations.
- fxtentacle 6y ago
  It depends. If you want to be a successful indie company, avoid cloud and distributed like the plague. If you want to advance in the big corp career ladder, user Kubernetes with as many tiny instances and micro-services as you can. "Oversaw deployment of 200 services on 1000 virtual servers" sounds way better than "started 1 monolithic high-performance server". But the resulting SaaS product might very well be the same.
  - fock 6y ago
    recently talked to a non-SV software developer friend: yeah, I killed two days making a window show up on top of all others on ubuntu with QT (under KDE, so, a supported business-configuration...). After telling him that this is a standard-feature of most X windows managers and asking, whether he used Wayland (didn't know), we went into functionality. "Yeah, you can enter a command and execute it on a remote machine" - "isn't that what ssh is for and you can do with a 20 line shell-script"" - "Yeah maybe, but some management type developed it, while he was still a grunt so we have to keep it...". I bet, said management type is still bragging about how he introduced convenient remote command execution by writing a QT app and his own server (or maybe he's using telnet...).
  - waheoo 6y ago
    I just tell people I use a mono repo to house all my single file microservices. Php under apache.
    - fxtentacle 6y ago
      Great description! I run a monolithic ensemble that abstracts away the concept of multiple processes to deliver a unified API. In short, it's multithreaded.
- pjmlp 6y ago
  Or .NET and Java. All this docker and k8s stuff just feels like reinventing application servers, just 10x more complex as means to sell consulting services.
toyg 6y ago
Rust and Go could help you there, and their deployment story is as excellent as C/C++: just compile and ship. However, their learning curve is pretty steep (particularly Rust) and most developers don’t enjoy having to worry about low-level issues, which makes recruitment and retention a problem. Whereas one can be reasonably proficient with Python/Ruby in a week, Java/C# is taught in school, and everyone has to know JS anyway (thanks for nothing, tweenager Eich), so it’s easy to pick up manpower for those.
- Perseids 6y ago
  Do those highly available developers have the same quality as the Rust developers you could get, though? (On average.) I'd wager there is a correlation between interest in deeper topics as required by Rust and good long term design and quality. I've seen how marvelously efficient a small team of very talented people can be be. To replace them with the average highly available developers you would need far more than doubly the people and some extra manager, just because communication scales so badly. The 10x developer is a myth, but I think the 5x development team is realistic in the right circumstances. Disclaimer: Neither do I claim to be a very good developer, nor do I think you, the reader, is only average. Just given that you are reading Hackernews is a strong indicator for your interest in reflection and self improvement, regardless of your favorite language.
  - deleted 6y ago
    [deleted]
  - fxtentacle 6y ago
    The problem might be that those people interested in learning new things, solving complicated issues and building good long-term architectures are usually not too interested in sitting in a cubicle without a window. So big companies might be forced to settle for less skilled developers, simply because the top tier is doing their own thing. I assume that's also why acqui-hiring is a thing.
    - Throwaway655249 6y ago
pwdisswordfish2 6y ago
That's why C++ is in brackets. :) I think the reason a hobbyist might be able to pull off something extraordinary is because he is not bound to the same ambition as a tech company. He can focus on performance, the 10K req/s part, and ignore the "requirement" of serving something large and complex that is likely full of bugs. "Developer time" is "hobby time". Done for the pleasure of it, not the money. Some of the most impressive software from a performance standpoint has been written by more or less "one man teams". I am glad I am not a tech worker. Even for someone who enjoys programming, it does not sound fun at all. No wonder there is so much cynicism.
roystonvassey 6y ago
Additionally, for larger eneterprises, the operational overhead quickly grows and slows down new app development, if one is tied to a traditional server approach. Within our teams, we’ve found we can do with an (even) higher level of abstraction by running apps directly on PaaS setups. We found this sufficient for most of our use-cases in data products.

Perseids 6y ago

True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/ https://thume.ca/2020/05/17/pipes-kill-productivity/

pas 6y ago
I find that the big problems that k8s solve is the usual change management issues in production systems. What do we want to deploy, okay, stop monitoring/alerts, okay, flip the load balancer, install/copy/replace the image/binary, restart it, flip LB, do the other node(s), keep flipping monitoring/alerts, okay, do we need to do something else? Run DB schema change scripts? Oh fuck we forgot to do the backup before that! Also now we haven't started that dependent service, and so we have to rollback, fast, okay, screw the alerts, and the LB, just rollback all at once. And sure, all this can be scripted, run from a laptop. But k8s is basically that. ... And we get distributedness very fast, as soon as you have 2+ components that manage state you need to think about consistency. Even a simple cache is always problematic (as we all know how the cache invalidation joke). Sure, going all in on microservices just because is a bad idea. Similarly k8s is not for everyone, and running DBs on k8s isn't either. But, the state of the art is getting there. (eg the crunchydata postgresql operator for k8s.)
- znpy 6y ago
  > I find that the big problems that k8s solve is the usual change management issues in production systems. This. I was in a company where devops was just a fancy marketing term, developers would shit out a new release and then it was our problem (we the system engineers / operations people) to make it work on customers' installations. I now work as a devops engineer in a company that does devops very well. I provide all the automation that developers need to run their services. They built it, they run it. I am of course available for consultation and support with that automation and kubernetes and very willing to help in general, but the people running the software are now the people most right for the job: those who built it. As I said in my other comment: it's really about fixing the abstractions and establishing a common lingo between developers and operations.
fxtentacle 6y ago
It depends. If you want to be a successful indie company, avoid cloud and distributed like the plague. If you want to advance in the big corp career ladder, user Kubernetes with as many tiny instances and micro-services as you can. "Oversaw deployment of 200 services on 1000 virtual servers" sounds way better than "started 1 monolithic high-performance server". But the resulting SaaS product might very well be the same.
- fock 6y ago
  recently talked to a non-SV software developer friend: yeah, I killed two days making a window show up on top of all others on ubuntu with QT (under KDE, so, a supported business-configuration...). After telling him that this is a standard-feature of most X windows managers and asking, whether he used Wayland (didn't know), we went into functionality. "Yeah, you can enter a command and execute it on a remote machine" - "isn't that what ssh is for and you can do with a 20 line shell-script"" - "Yeah maybe, but some management type developed it, while he was still a grunt so we have to keep it...". I bet, said management type is still bragging about how he introduced convenient remote command execution by writing a QT app and his own server (or maybe he's using telnet...).
- waheoo 6y ago
  I just tell people I use a mono repo to house all my single file microservices. Php under apache.
  - fxtentacle 6y ago
    Great description! I run a monolithic ensemble that abstracts away the concept of multiple processes to deliver a unified API. In short, it's multithreaded.
pjmlp 6y ago
Or .NET and Java. All this docker and k8s stuff just feels like reinventing application servers, just 10x more complex as means to sell consulting services.

toyg 6y ago

Rust and Go could help you there, and their deployment story is as excellent as C/C++: just compile and ship. However, their learning curve is pretty steep (particularly Rust) and most developers don’t enjoy having to worry about low-level issues, which makes recruitment and retention a problem. Whereas one can be reasonably proficient with Python/Ruby in a week, Java/C# is taught in school, and everyone has to know JS anyway (thanks for nothing, tweenager Eich), so it’s easy to pick up manpower for those.

Perseids 6y ago
Do those highly available developers have the same quality as the Rust developers you could get, though? (On average.) I'd wager there is a correlation between interest in deeper topics as required by Rust and good long term design and quality. I've seen how marvelously efficient a small team of very talented people can be be. To replace them with the average highly available developers you would need far more than doubly the people and some extra manager, just because communication scales so badly. The 10x developer is a myth, but I think the 5x development team is realistic in the right circumstances. Disclaimer: Neither do I claim to be a very good developer, nor do I think you, the reader, is only average. Just given that you are reading Hackernews is a strong indicator for your interest in reflection and self improvement, regardless of your favorite language.
- deleted 6y ago
  [deleted]
- fxtentacle 6y ago
  The problem might be that those people interested in learning new things, solving complicated issues and building good long-term architectures are usually not too interested in sitting in a cubicle without a window. So big companies might be forced to settle for less skilled developers, simply because the top tier is doing their own thing. I assume that's also why acqui-hiring is a thing.
  - Throwaway655249 6y ago

pwdisswordfish2 6y ago

That's why C++ is in brackets. :) I think the reason a hobbyist might be able to pull off something extraordinary is because he is not bound to the same ambition as a tech company. He can focus on performance, the 10K req/s part, and ignore the "requirement" of serving something large and complex that is likely full of bugs. "Developer time" is "hobby time". Done for the pleasure of it, not the money. Some of the most impressive software from a performance standpoint has been written by more or less "one man teams". I am glad I am not a tech worker. Even for someone who enjoys programming, it does not sound fun at all. No wonder there is so much cynicism.

roystonvassey 6y ago

Additionally, for larger eneterprises, the operational overhead quickly grows and slows down new app development, if one is tied to a traditional server approach. Within our teams, we’ve found we can do with an (even) higher level of abstraction by running apps directly on PaaS setups. We found this sufficient for most of our use-cases in data products.