lllr_finger

I'm sorry you're being downvoted - it seems to be a question in good faith, there isn't a singular, obvious answer, and I think you'll get some good answers.

For me, I use it for things that I want to be simple or unencumbered from licensing. Any sort of storage server in my house gets FreeBSD almost automatically. OpenBSD, I keep around mainly as a learning experience - it's really a simple, well-documented operating system, and it works flawlessly on a number of different Thinkpads. There are also plenty of opportunities to participate in the development of the OS itself or its packages.

T450s worked flawlessly. Any of the Thinkpads that you see on eBay being retired by corporations and refurbished for $200-$500USD would be great candidates.

Once you start talking hundreds-to-thousands requests/second, 500ms is an incredibly long time and you're well past simple tweaks to GC. Tuning GC to a high degree is non-deterministic black magic, which is not what you're looking for at that point.

Simple tweaks can go a long way for a lot of developers, but GC performance has been a problem at the last 3 organizations I've been at - and I'm not in the valley or at a FAANG - so it isn't exactly an uncommon scenario for developers.

LMAX also spent a ton of time doing non-standard things with data structures to optimize cache and prevent heap allocation: https://martinfowler.com/articles/lmax.html

Unnecessary allocations will be your bottle neck at some point when shutting data around.

One of my favorite things with Rust is how other things are starting to use it. Just yesterday I started playing with Deno and was anticipating a severe lack of database bindings. Some people used the built-in Typescript->Rust message passing to make a tiny shim around the Rust bindings for things like MongoDB: https://github.com/manyuanrong/deno_mongo

Now is a great time to learn it, because there's nothing huge on the horizon that will make your life easier or harder.

I started learning just as the async/await and futures features started causing churn and confusion in the ecosystem - it was slightly irritating at the time, but in hindsight, I'm still glad I started learning then.

You're not wrong that the distinction isn't terribly important for this story, however that term absolutely has meaning in the world of fintech and places reporting on financial news - near/soft real-time are very distinct from real-time.

It's been 5 years since I've worked in that industry, but I still view the use of "real-time" the same way and can understand some people's issue with the term in this case.

I agree with you, but I find some value in people using that term - it signals to me that I should consider the the architecture was prematurely split-up and could suffer from the various pitfalls associated with microservices.

Because that's (roughly) the Lifted Condensation Level: https://en.wikipedia.org/wiki/Lifted_condensation_level

Water vapor around the LCL starts condensing and turning from a gas into liquid cloud droplets. This process happens considerably faster once it begins for a variety of reasons, so once you can have cloud droplets, you get a ton of cloud droplets - not a gradual transition from water vapor to cloud. It's almost like a light switch.

Most air masses are relatively homogenous anyways, so unless there are underlying processes causing things like undulatus asperatus, it will certainly appear very, very flat over a large area.

Most of these points are debated in Brendan Gregg's "Solaris to Linux Migration" blog post from 2017: http://www.brendangregg.com/blog/2017-09-05/solaris-to-linux...

The only point of Brendan's that I don't agree with is ZFS as it really doesn't have a strong competitor (yet). Thankfully, it also doesn't need to be on every machine - my desktops/laptops/deployed servers are treated like cattle not pets.

I love FreeBSD/OpenBSD's simplicity and principled design, but I've sadly relegated them to specific purpose servers at work and at home because I kept hitting enough speedbumps that IMO preclude them from being used in a more general sense.

Putting thought into design patterns and a storage engine that accents that choice, it's sometimes possible to eschew caching and distributed storage altogether - saving you from a whole host of complexity.

It can also be challenging to accurately assess a database's performance and correctness. I've been using C/Rust bindings when possible for the former, and Aphyr's Jepsen test results for the latter. Unfortunately there's no silver bullet on these topics - you pretty much have to test all your use cases.

Postgres use always reminds me of this presentation: http://boringtechnology.club/

I self-admittedly love esoteric databases and storage engines to a fault. I'll try to shoehorn things like RocksDB into whatever personal project I'm working on.

At work however, the motto I spread to the teams I work on is "use Postgres until it hurts". And for many, many teams - Postgres will never hurt. I'm very happy for its continued existence because its been a solid workhorse on various projects I've worked on over the years.

There are apps/plugins/filters that claim to recreate it, but like many other analog/digital comparisons, if you're rather used to looking at film grain with your naked eye or with a loupe, you will notice the difference.

An otherwise healthy thirtysomething in Minnesota is in critical condition right now - it's not time to panic but you probably want to avoid getting this if you can.

Normally, I'd agree with you - however, my org just had some minor drama over someone attempting to classify a certain piece of tech as "dead". The people who were invested in that tech were riled up.

It's difficult to know with certainty the motivations and emotional attachments people on either side of a debate will have, so it's sometimes easier to avoid some of the more "loaded" words.

I didn't, but I will now. Thanks!

My anecdotal evidence after searching for the "perfect" laptop OS across 2 laptops and various BSDs, a dozen Linux distros, etc.: the best power tuning you can do will still only get you around 85-90% of what you can in Windows (with no tweaks).

My Fedora and FreeBSD laptops have been solid workhorses for years - I'm on my third MBP at work and I loathe the thing. It's hard to say how much of that is the new keyboard and all the corporate spyware it's saddled with, but it has been decidedly less stable for me.

As much as I like FP and Kotlin, we ended up removing Arrow and hand rolling the few things we really wanted, like a Result sum type. It's an impressive project, however adding FP to an intentionally multi-paradigm language can lead to rough ergonomics in some places.

I would tout sealed classes as well, although I think Java has a proposal that's getting traction.

For back-end service/API type things in an enterprise setting, Kotlin is a good value proposition. There's also probably some truth to the idea that one reason modern Java is adding these things is because of Kotlin's existence.

DID is an extremely important concept that is alien to a lot of developers: Deploy for 1.5X, Implement for 3X, Design for 10X (your numbers may vary slightly)

The goals of Rust are stated boldly right on the official website - "Performance" is one of them. In Discord's case, the hit in productivity was worth avoiding the GC issues in Go. I read the article and didn't come to the same conclusion, so I'm curious which passages led you to believe this was done to "adopt a trendy language"?

Most exceptions, at least in the JVM where this is commonly debated, will incur a penalty of building up the exception and unwinding the call stack. What aspect of performance are you using as an example?

It's been awhile since I've been in C#, but in other static languages like Rust and Kotlin with type inference, it would look more like:

public Result<SomethingGood, SomethingBad> PerformUpdate(int goodThingId, UpdateForm form) { ... return Err(error); ... return Ok(obj); }

which is considerably less boilerplate-y. When there are three cases you want to consider, that's no longer a sum type consisting of just success or failure - that's a different sum type. Maybe even represented as Result<ThreeCases, Error>.

That's awesome and I'm right there with you on wanting to do more.

Have you considered your next step, and do you have any suggestions? Purchasing green power is such a minor sacrifice for my household, I'm still looking for something more.

I was working on a pipeline that took data in, did a bunch of work concurrently, then decorated the original data and shuttled it off elsewhere.

I spent a whole sprint building out "the RAD" - a rooted acyclic digraph - that ensured all sorts of correct behavior and powerful options for working with the graph. It felt awesome building what I thought was this super elegant thing that, to me, made total sense since I had been working with it for 3 weeks.

The other devs were confused by it and we're afraid to touch the code. I admitted failure and worked with them to rewrite it. It ended up being an adjacency list (i.e. a graph) with breadth-first traversal, but as long as I didn't call it that, they understood it and liked it.

And in hindsight, we didn't need all the guarantees that it provided, so they were right.

Leaning on the type system for as many guarantees as possible. A few of my teams use Kotlin's sealed classes and extension methods to prevent a lot of goofy invalid state and improve composability (using a Result<T, E> sum type very similar to what Rust has built-in).

I liked this article I recently came across discussing the topic: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

I just saw my first local, non-blockchain Rust opportunity, but sadly had to pass on it due to other obligations. Everyone I know writing Rust these days is introducing it to their orgs - not waiting for an open position.

I've witnessed the same thing, however there is nothing mutually exclusive about having performant code running in Kubernetes. There's a trade-off between performance and productivity, and maintaining a sense of pragmatism is a good skill to have (that's directed towards those that use scaling up/out as a reason for being lax about performance).

That's not what cattle vs pets is. Treating your app as cattle means that it deploys, terminates, and re-deploys with minimal thought at the time of where and how. Your app shouldn't care which Kubernetes node it gets deployed to. There shouldn't be some stateful infrastructure that requires hand-holding (e.g. logging into a named instance to restart a specific service). Sometimes network partitions happen, a disk starts going bad, or some other funky state happens and you kill the Kubernetes pod and move on.

You should try to fix mem leaks and other issues like the one you described, and sometimes you truly do need pets. Many apps can benefit from being treated like cattle, however.

This article touched on the distinction and has plenty of associated links at the bottom: https://medium.com/@Joachim8675309/devops-concepts-pets-vs-c...