deckarep

If I were to have taken this advice when I first heard it...I wouldn’t have had the pleasure of working with the intricacies, ins and outs of a threaded model.

This is what I’ve heard through my career: don’t use threads, don’t use locks, don’t use pointers, don’t use languages with manual memory management. The list goes on: don’t use unsafe code, don’t use pointer arithmetic...

The bottom line is that these concepts can be used successfully if you understand the traps. Yes a sufficiently large codebase will eventually suffer from things like data races, memory leaks, etc but if you always take this advice and avoid the dark side of software development you’ll never develop an aptitude for how to deal with such code when you see it the wild.

Instead of saying don’t use threads I would say. Learn the good and bad of a threading model. Know your limits, and study the traps so you can possibly avoid them. Still there are no guarantees but all languages have warts if you look deep enough even high-level languages.

Take Go for example, it has a threaded model with m x n goroutines scheduled over threads. Guess what? Go can easily have data races if you aren’t careful.

It’s still a great language! Still worth learning.

How much of the book is directly applicable to Cassandra? I understand that Apache Cassandra is regarded as the “open-source” version of DynamoDB?

My microservice that returns “Hello World” via HTTP has been running solid for 5+ years now with zero downtime.

Not quite, the difference here is that instead of storing live objects on the heap you would need to serialize them into a byte slice. You then hand that to the cache library and it would find a place to copy those bytes and store them on your behalf. This means your object now just becomes data belonging to the cache and sits somewhere on the libraries internal data-structure.

I have not used this package but there is another one for Go called freecache that offers a similar solution. The primary benefit of such solutions is that if you have a Go service where you want to rely on the local caching of data, using a package like this can significantly reduce GC scan pressure removing the work that Go needs to do when analyzing pointer data sitting on the heap.

Why does this help? Instead of keeping millions upon millions of items alive on the heap (leading to Go having to scan all such data) you can instead serialize/deserialize the data in a solution like this with usually minimal overhead. Storing your cached data in a solution like this suddenly gets rid of the need to have live pointers of data on the heap. This is because your data is now stored as []byte slice somewhere in the Cache data structure that this code uses. Finally, since packages like BigCache/Freecache are built with only a very small handful of heap objects the Go runtime performance can now go back to what it does best which is spending most of its time in your application logic.

If anyone has any doubts of this approach try it out...we saw dramatic differences with using a package like this vs a naive map of pointer based data or vs something like Hashicorps LRU datastructure.

The last service we applied this model changed CPU profile from running at around 900% to 400%. That was a big win in my book and practically cut our cluster size in half.

I actually read this as: ”overwhELMingly“...

Haha Big ISPs...there’s absolutely no reason why regular HTTP requests/responses should be TLS encrypted while DNS queries should not...they go hand in hand for maintaining end-user privacy and YOUR integrity.

This is true of releasing code in general. Changes that accumulate over time actually increase risk whether it be desktop or server-side.

Somehow my daughter gets to carry both her Chromebook and her heavy books. :/

I was just telling me wife a few weeks back about Microsoft Encarta. Turns out she had a copy too back in the day.

My best memory is getting a copy shortly after CD-ROM drives were still new territory. I loaded the disc and the first thing I searched for was either rap or hip/hop. To my delight an audio clip played of Grandmaster Flash & The Furious Five - The Message...keep in mind this was at a time when Multimedia was new and the idea that CD-ROMs could hold enough data to make a richer experience was ground-breaking!

What a respectable comment. It’s so easy to just gripe about downtime. Stripe is one of those comments that does take uptime seriously but alas as long as humans are at the helm there’s always room for mistakes. As long as we learn from them.

This quote is powerful and resonates: “The cost-cutting culture is the opposite of a culture built on productivity, innovation, safety or quality”

I know investors must see a profit and business must keep moving but honoring the careful balance of these two ideas is a must or what are you really left with?

About 6 or 7 years ago I was searching for a language that had great concurrency built in and a sane enough model of concurrency that would allow me to get things done.

Eventually I found and fell in love with gevent because I could write fairly straightforward code in a synchronous fashion and reason about the code a lot easier than other models. But then I found some warts with gevent: what about good community support? What about exploiting parallelism? Monkey patching 3rd party libs is a bit ugly and not 100% without faults.

So imagine how I felt when I found that Go offers this model of concurrency CSP with support for parallelism due to the M to N threading model. Also a not quite but close enough Python looking syntax and at that point I never looked back.

Sure there other models of concurrency and other languages that are also proving to be useful. But Go has been a good bet...at least for now.

And I know this is controversial...but Go’s time is running out...other languages are getting there with more advanced support for asynchronous programming...so I imagine in due time I’ll be onto the next thing.

It’s not a joke see Pony’s front-page. I’ve also heard that other languages are considering moving to this provable compile time model such as Swift.

I’d be happy to offload such mental hoops to the compiler.

After being fully invested in Go for close to 6 years and working at primarily Go based shops...I want to disagree with this headline.

Folks new and old to Go still write data-race riddled code unless they put in the extreme mental effort and care into avoiding data-races. Also, if they write good unit tests that help them spin through the code they can often double-down on ensuring their code is correct by using the race-detector.

Even if you do all of this...sorry but there’s no guarantees.

In my opinion this is why we are seeing languages like Rust invest heavily in something like the borrow checker...to prove at compile time when you have racy code.

If Go had a compile time ability to do this it would be really amazing.

Yes, this all my experience and opinion.

Oh good I’ve been needing to talk to my psychologist again. His name is Dr. Sbaitso...

https://books.google.com/books?id=fpQP3e54P-gC&pg=PT80&dq=sb...

I’ve always found that if you stare at something long enough you can eventually understand it, and break it down into its core components. If your business depends on it, don’t be so quick to just rewrite it and abandon because it likely will have a ton of hardened edge cases that are baked into it that the business relies upon.

You must study the code and document what you can. Reverse engineering it is sometimes the only option in your quest to understand it. Then you’ll need to make decisions about how to move forward given the constraints of the business whether it be time, resources, other priorities. There is no one size fits all answer but don’t be shy about vocalizing the risks and making sure the business knows the pain points. Sometimes you have to sell the problem you now have and get buy-in to really do something to fix the mess.

One thing I’ve realized is that when people don’t take the time to document and write clean code sometimes it boils down to their idea of job security.

Other times it turns out the problem is there is no single owner of this code base and it’s been hacked to death.

Lastly when something is ugly, enough and messy enough...then you can just call it proprietary technology...I kid I kid.

I think there’s going to be an API for everything renissance and this is just another example. As a coder being able to automate all the things and create new businesses, processes, workflows it’s a great time to be a coder.

Aka reaching beyond the cloud.

Check out the Prisma app which has been doing this style of image processing using machine-learning for awhile now. The results of Prisma can sometimes yield mind-blowingly fantastic results.

Interesting comment...considering concurrency in Rust is significantly safer to do.

This is the whole point of the borrow checker which is to ensure data-race free code.

The story with concurrency is still being worked out with async server-side applications which is coming together swimmingly!

How does synchronization or the lack of it carry over and translate to WASM based threading?

I’m assumming all the typical threading problems are inherited by design such as the potential for deadlocks, memory corruption, priority inversion...etc?

Also I’m assumming these threads will allow true parallelism to occur?

Yep that looks like a legit clone of it. Thanks for the link.

Does anyone remember some installs shipped with a game called gorilla.bas? A fun little game where you had two gorillas across a cityscape and the whole idea was to take turns throwing bananas at each other to see who can get a critical hit.

What made it hard is you had to enter both an angle and speed and hope you calculated the right combination to hit the other player.

Eventually I wrote my own version of the game in flash/actionscript....but it’s long gone.

Yes I agree with those points as well...because Rust is now able to statically have such guarantees, this additional knowledge allows for some great optimizations under the good.

Yes there is much more mental load you pay upfront during development but once you get code working and satisfy the borrow checker you now have significantly stronger runtime guarantees about your application in terms of safe and proper concurrency.

This is the trade off.

Does this new classic+ environment now supersede the Flex environment?

I’m curious because now it’s seems like there are 3 solutions. Although I really like the simplicity of this solution and the modernizing from the constraints of true classic mode.

I think this is the first time in history a robot has twerked. A great milestone.

I didn’t know he passed. What a remarkable person. Thanks for the update.

For anyone wanting to see a master example of echolocation see this short video: https://youtu.be/TeFRkAYb1uk

When picking preemptive machines for this demo project is the intention here to simply save money for a pet project?

I guess my main question is would anybody actually use preemptive for k8s knowing that if a worker node gets reaped k8s will magically route only to healthy nodes while the preempted instance replacement is standing up?