The bachelor's degree has become this strange hybrid of outdated prestige signaling and a vague promise of employability, but without delivering on either in a consistent way.
When you put it like that it really is a bad product.
Readit Newsjeremycarter commented on Has the decline of knowledge work begun? nytimes.com/2025/03/25/bu... · Posted by u/pseudolus
jeremycarter commented on MongoDB acquires Voyage AI investors.mongodb.com/new... · Posted by u/marc__1
a) MongoDB has built-in, supported, proven scalability and high availability features. PostgreSQL does not. If it wasn't for cloud offerings like AWS Aurora providing them no company would even bother with PostgreSQL at all. It's 2025 these features are not-negotiable for most use cases.
b) MongoDB does one thing well. JSON documents. If your domain model is built around that then nothing is faster. Seriously nothing. You can do tuple updates on complex structures at speeds that cripple PostgreSQL in seconds.
c) Nobody who is architecting systems ever thinks this way. It is never MongoDB or PostgreSQL. They specialise in different things and have different strengths. It is far more common to see both deployed.
Great response. All arguments are valid and fair.
jeremycarter commented on WASM will replace containers creston.blog/wasm-will-re... · Posted by u/hpincket
And a nice centralized authority that judges the trustworthiness of a given application by staring at a binary extensively?
Sounds good!
jeremycarter commented on Software development topics I've changed my mind on chriskiehl.com/article/th... · Posted by u/belter
> Monoliths remain pretty good
> It's very hard to beat decades of RDBMS research and improvements
> Micro-services require justification (they've increasingly just become assumed)
That is so true. I am still deploying good old .war files to full blown Java app servers backed by simple SQL databases (all clustered and stuff) with some handwritten cli tools and a Jenkins server. Shit is fast, shit scales, shit just works. It is a pleasure to work with
98% of teams I've worked on did not need microservices.
jeremycarter commented on Show HN: Watch 3 AIs compete in real-time stock trading trading.snagra.com... · Posted by u/sunnynagra
Going to follow along to see how the results look in the months to come.
I've been working on the same concept for the past 2y now and have our performance results here: https://trend.fi/performance
What's the technology behind this. I'm working on something myself, using a distributed actor model (setup like a graph) to create a living reactive model.
I view actors like I view "object orientation" in general. In fact they're not even all that dissimilar, being respectively "store and manipulate state attached to a single runtime context" (be it "thread" or "green thread" or async context or whatever) and "store and manipulate state attached to a single highly-structured value". (They go together pretty well, actually.) The primary value comes from the idea, and it can and should be managed and manipulated for the local context.
Many people will come along and insist that you need every last thing according to some particular definition (e.g., in OO, "you need multiple inheritance and all of public, private, and protected, and you need virtual methods and you need and you need and you need OR YOU DON'T HAVE TRUE OBJECT ORIENTATION AND EVERYTHING WILL FALL APART"), and will insist that everything at every layer of your program will need to be structured in this paradigm OR YOU DON'T HAVE TRUE WHATEVER AND EVERYTHING WILL FALL APART, but both claims are observably false.
I use actors in nearly every program I write, in almost any language I write in anymore if there's any concurrency at all. But they are a wonderful tool to drop in somewhere, and encapsulate some particularly tricky bit of concurrent logic, like an in-memory concurrent cache, without having to restructure everything to be All Actors All The Time. I spent a lot of years in Erlang and still sort of consider this a mistake, up there with Java trying to "force" everything into OO by forcing everything to be in a class, even if it has no business being there. You don't need to go down someone's check list and dot every i and cross every t "or you don't have true actors". It's very much an 90/10 situation where the vast bulk of the benefit is obtained as soon as you have anything even actor-ish, and the additional marginal benefit of going all the way down to some very precise definition can be marginal and may even be negative if it requires you to contort your code in some unnatural way just to fit into some framework that isn't benefiting you on this particular task (e.g., Erlang has a lot of nice tools but if you're building a purely-local command-line app with it for whatever reason you probably don't have a great need for clustering support or OTP in general).
My sentiments exactly - well said. The big mistake is forcing OOP onto everything. It's why I really have an affinity with the virtual actor, it has just enough OOP for me to have classes, methods and internal state - I don't need inheritance, polymorphism, etc - just naive little classifications of things we call objects.
I also don't have to think of my system in a hierarchical supervised manner like earlier actor models. I just need cloud native distributed little objects.
You can see some modern products coming out that are just that:
1. Cloudflare Durable Objects - https://developers.cloudflare.com/durable-objects/
2. Restate Virtual Objects - https://restate.dev/
Some actor frameworks (Erlang, Orleans) would interpret each order being an actor instance, and each order line being an actor instance. To make that clearer: each order row would _logically_ have an actor running somewhere in your cluster. This would mean that an order actor would, by nature, have a "add order line" receiver (i.e. method). Each is in charge of how its data is stored. In reality, you'd _probably_ only do this stuff on the command end: query would hit tables+joins+whatever directly.
If you work this back to DDD, then the Order entity would have an AddOrderLine method. The central service would be responsible for handing out Order entities and saving them once modified.
Up until a few years ago (prior to my previous job) I was a hypothetical believer in DDD and actors as two equally viable alternatives. I am now strongly against DDD, but still agree with the article on a hypothetical basis about actors.
I agree. I'm not advocating doing a purist DDD solution but rather using similar modelling techniques and just making naive actors.
is this AI generated? I flagged because seemed very low on substance and just generic bullet points
It's just part 1. I have just published part 2 which goes into more detail.
It's not clear from the article whether actors offer significant benefits (or disadvantages) for data modeling versus the traditional OO paradigm. The article reads more like an introduction that describes the problem and teases a solution rather a complete article that offers a solution and evaluation of it.
That's fair feedback. I wanted to post it in 3 parts, but I see now I probably should have just made one large post.
The article seems to be smashing together two (seemingly) unrelated topics and doesn't offer much in the way of a solution. What alternative design does the author propose? Is it possible to solve the problem with traditional object-oriented design techniques? It's not clear that the issues presented require or substantially benefit from the actor model without seeing a best in-class OO example.
As I mentioned there's nothing novel in this post, especially for a senior. This is more about getting some context out of the way so that I can show some techniques in a future post.