I ran up like a $5k bill over a couple weeks by having an application log in a hot loop when it got disconnected from another service in the same cluster. When I wrote that code, I expected the warnings to eventually get hooked up to page us to let us know that something was broken.
Turns out, disconnections happen regularly because ingress connections have like a 30 minute timeout by default. So it would time out, emit like 5 GB of logs before Kubernetes noticed the container was unhealthy and restarted it, rinse and repeat.
I know $5k is chump change at enterprise scale, but this was at a small scale startup during the initial development phase, so it was definitely noticed. Fortunately, the only thing that happened to me was some good-natured ribbing.
Years ago I was told that serverless would be cheaper than running your own servers. It seems like it’s not necessarily cheaper, but just a different way of designing a solution. Would you agree with that assessment? I have never used serverless. Every place I’ve worked needed tightly controlled data so on premises only.
Meanwhile I host my personal website on dirt cheap VPS.
The thing with serverless is you’re paying for iowait. In a regular server, like an EC2 or Fargate instance, when one thread is waiting for a reply from a disk or network operation the server can do something else. With serverless you only have one thread so you’re paying for this time even though it’s not actually using any CPU.
While you’re paying for that time you can bet that CPU thread is busy servicing some other customer and also charging them.
I like serverless for it’s general reliability, it’s one less thing to worry about, and it is cheap when you start out thanks to generous free tiers, at scale it’s a more complex answer as whether it is good value or not.
Therefore, would you agree that serverless is more about freeing up your mind as a developer and reducing your number of concerns where possible rather than necessarily cost savings or scaling?
In other words, is it less about better scaling and more about scaling isn’t your problem?
It’s cheaper if you don’t have constant load as you are only paying for resources you are actively using. Once you have constant load, you are paying a premium for flexibility you don’t need.
For example, I did a cost estimate of porting one of our high volume, high compute services to an event-driven, serverless architecture and it would be literally millions of dollars a month vs $10,000s a month rolling our own solution with EC2 or ECS instances.
Of course, self hosting in our own data center is even cheaper, where we can buy and run new hardware that we can run for years for a fraction of the cost of even the most cost-effective cloud solutions, as long as you have the people to maintain it.
It was $5k worth of training, and well worth it, since you still remember the lesson.
Reminds me of an issue while carrier-testing a to-be-released smartphone. The third party hired to do this testing would sideload an app to run the tests, but it would try to do something hinky in the background with logging, leading to an infinite retry loop for opening a nonexistent file, effectively doubling the device’s power consumption.
That’s because the new one is just the existing web app that loads inside an Edge instance so they were basically starting from scratch. I realized that when I discovered I couldn’t open the new version on my laptop that I had uninstalled Edge from.
I knew a kid in high school who’s family had spent some time living in a van. I guess the kid had an ongoing joke that they ended up in the van because his dad refused to learn java. Kinda funny, kinda sad. Couldn’t help but think of that when I saw this.
We had the teams update at work, with the endless notifications to let me know that a new version was coming, would I like to update early, on the 1st the update will be forced …
And the new Teams is not simply a replacement, no. It’s called “Teams (for work or school)” or something, while the old app is “Teams classic”. Both look the same and are the same sluggish mess. So why exactly did we do all that crap?
All I know is that one of them has a /v2/ subpath on its URL, and the other has nothing.
Oh, and calls work in Firefox one the /v2/ one. That’s an important difference.
What I really don’t know is why they kept pestering me for months to make sure my browser supports the new version (where they know what my browser is, and only published enough requirements to tell IE won’t work) while they only changed stuff that makes it work better on it.
Also the “we’re setting things up for you” or whatever user-dumb-hide-details crap the Teams PWA throws on your screen while launching is just… As if there was a live team of engineers carefully configuring your current Teams instance so that it starts up right. (A bit off-topic, but current trend of software “speaking to users in patronising manner” is annoying af. Unless it’s up to or exceeding HAL-3000 level, it should be abolished.)
This is such a perfect demonstration of how useless Microsoft’s ecosystem is. It’s better than being forced to work in an Apple exclusive environment but “we’re a windows shop” is one of the biggest red flags an employer can have.
As hard as it is and as much as I would like help, I am so happy to be the only Dev in my company capable of working on my projects and to have bosses who essentially give me carte blanch on how to code and deal with issues.
This graph cuts off early. Once you learn that pointers are a trap for noobs that you should avoid outside really specific circumstances the line crosses zero and goes back into normal land.
C++ is unironically my favorite language, especially coding in python feels so ambiguous and you need to take care of so many special cases that just wouldn’t even exist in C++.
You can absolutely read my code. The ability (similar to functional languages) to override operators like crazy can create extremely expressive code - making everything an operator is another noob trap… but using the feature sparingly is extremely powerful.
Typically, I can read an “average” open source programmers code. One of the issues I have with C++ is the standard library source seems to be completely incomprehensible.
I recently started learning rust, and the idea of being able to look at the standard library source to understand something without having to travel through 10 layers of abstraction was incredible to me.
I wonder what went into their minds when they decided on coding conventions for C++ standard library. Like, what’s up with that weird ass indentation scheme?
One of the issues I have with C++ is the standard library source seems to be completely incomprehensible.
AAAAAAhhh I once read a Stroustrup quote essentially going “if you understand vectors you understand C++”, thought about that for a second, coming to the conclusion “surely he didn’t mean using them, but implementing them”, then had a quick google, people said llvm’s libc++ was clean, had a look, and noped out of that abomination instantly. For comparison, Rust’s vectors. About the same LOC, yes, but the Rust is like 80% docs and comments.
I think some of those abominational constructs were for compile-time errors. Inline visibility macro is for reducing bynary size, allowing additional optimizations and improving performance and load time.
In my projects I set default visibility to hidden.
I’ve been using C++ almost daily for the past 7 years and I haven’t found a use for shared_ptr, unique_ptr, etc. At what point does one stop being a noob?
Given that you probably are using pointers, and occasionally you are allocating memory, smart pointers handle deallocation for you. And yes, you can do it yourself but it is prone to errors and maybe sometimes you forget a case and memory doesn’t get deallocated and suddenly there is a leak in the program.
When you’re there, shared_ptr is used when you want to store the pointer in multiple locations, unique_ptr when you only want to have one instance of the pointer (you can move it around though).
Smart pointers are really really nice, I do recommend getting used to them (and all other features from c++11 forward).
I would have said the same thing a few years ago, but after writing C++ professionally for a while I have to grudgingly admit that most of the new features are very useful for writing simpler code.
A few are still infuriating though, and I still consider the language an abomination. It has too many awful legacy problems that can never be fixed.
well, if I have an object on the heap and I want a lot of things to use it at the same time, a shared_ptr is the first thing I reach for. If I have an object on the heap and I want to enforce that no one else but the current scope can use it, I always reach for a unique_ptr. Of course, I know you know all of this, you have used it almost daily for 7 years.
In my vision, I could use a raw pointer, but I would have to worry about the lifetime of every object that uses it and make sure that it is safe. I would rather be safe that those bugs probably won’t happen, and focus my thinking time on fixing other bugs. Not to mention that when using raw pointers the code might get more confusing, when I rather explicitly specify what I want the object lifetime to be just by using a smart pointer.
Of course, I don’t really care how you code your stuff, if you are comfortable in it. Though I am interested in your point of view in this. I don’t think I’ve come across many people that actually prefer using raw pointer on modern C++.
Shared poibters are used while multithreading, imagine that you have a process controller that starts and manages several threads which then run their own processes.
Some workflows might demand that an object is instantiated from the controller and then shared with one or several processes, or one of the processes might create the object and then send it back via callback, which then might get sent to several other processes.
If you do this with a race pointer, you might end in in a race condition of when to free that pointer and you will end up creating some sort of controller or wrapper around the pointer to manage which process is us8ng the object and when is time to free it. That’s a shared pointer, they made the wrapper for you. It manages an internal counter for every instance of the pointer and when that instance goes out of scope the counter goes down, when it reaches zero it gets deleted.
A unique pointer is for when, for whatever reason, you want processes to have exclusive access to the object. You might be interested in having the security that only a single process is interacting with the object because it doesn’t process well being manipulated from several processes at once. With a raw pointer you would need to code a wrapper that ensures ownership of the pointer and ways to transfer it so that you know which process has access to it at every moment.
In the example project I mentioned we used both shared and unique pointers, and that was in the first year of the job where I worked with c++. How was your job for you not to see the point of smart pointers after 7 years? All single threaded programs? Maybe you use some framework that makes the abstractions for you like Qt?
I hope these examples and explanations helped you see valid use cases.
First year programming in the late 90s … segmentation fault? I put printfs everywhere. Heh. You’d still get faults before the prints happened, such a pain to debug while learning. Though we weren’t really taught your point of the comment at the time.
Least that was my experience on an AIX system not sure if that was general or not, the crash before a print I mean.
Yea, pointer arithmetic is cute but at this point the compiler can do it better - just type everything correctly and use []… and, whenever possible, pass by reference!
Your graph also cuts out early. Eventually you want to get performance gains with multi-threading and concurrency, and then the line drops all the way into hell.
I’m not saying you can’t do multi-threading or concurrency in C++. The problem is that it’s far too easy to get data races or deadlocks by making subtle syntactical mistakes that the compiler doesn’t catch. pthreads does nothing to help with that.
If you don’t need to share any data across threads then sure, everything is easy, but I’ve never seen such a simple use case in my entire professional career.
All these people talking about “C++ is easy, just don’t use pointers!” must be writing the easiest applications of all time and also producing code that’s so inefficient they’d probably get performance gains by switching to Python.
That’s the problem of most general-use languages out there, including “safe” ones like Java or Go. They all require manual synchronization for shared mutable state.
There’s a difference between “You have to decide when to synchronize your state” and “If you make any very small mistake that appears to be perfectly fine in the absence of extremely rigorous scrutiny then this code block will cause a crash or some other incomprehensible undefined behavior 1/10000 times that it gets run, leaving you with no indication of what went wrong or where the problem is.”
I use thread sanitizer and address sanitizer in my CI, and they have certainly helped in some cases, but they don’t catch everything. In fact it’s the cases that they miss which are by far the most subtle instances of undefined behavior of all.
They also slow down execution so severely that I can’t use them when trying to recreate issues that occur in production.
They caught lock inversion, that helped to fix obscure hangs, that I couldn’t reproduce on my machine, but were constantly happening on machine with more cores.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.