Go syntax and the Go runtime would be the perfect combo for me. Oh well...
I love Rust for what it is, but for most of my projects, I can’t justify the added complexity. Sure, there are a bunch of things I miss from the Rust world when I’m working on large-scale distsys services in Go, but introducing Rust in that space would be a recipe for disaster.
I guess the Go team knows that if they start adding everyone’s favorite Rust features, the language would become unrecognizable. So we’re not getting terser error-handling syntax or enums. Having union types would be nice too.
But I work in platform engineering, so my needs are quite different from someone writing business logic in Go. I understand that having a more expressive syntax is nice when you’re writing complex business code, but in reality, that almost always comes with a complexity/fragility tradeoff. That’s part of the reason no one wants to use Rust to write their business logic, despite it being so much more expressive.
For distsys, programming ergonomics matter far less compared to robustness and introspectability. So the Go runtime with Go syntax is perfect for this. But of course, that’s not true for all use cases.
Sorry for the rant - completely uncalled for. This is a cool project nonetheless :)
This is great. But I’ve bookmarked at least 10 of these aggregators over the years, and I never revisit any of them. Partly because I don’t have the time to browse and discover new content.
I also don’t read the blog spam from prolific writers who pop up here every two days, especially the low-quality ones constantly yapping about AI. So the number of blogs I revisit is a handful, and I have a page on my site listing them [1]. Some of the blogs I’ve listed also have backlinks to my site. It’s super simple and works fairly well for me. Plus there’s rss.
Europe doesn’t do software better - not because it can’t, but because it can’t afford to drop the GDP of a country to build a single app like some of its US counterparts can.
It might feel performative to some people, but Europe just doesn’t trust the US, and arguably shouldn’t. So it’s not about demonstrating superiority in software, but rather showing that there are alternatives you can choose if you want to.
"Their experience is different from mine; therefore, they haven't worked in big tech" is a bit reductionist.
While it's true that in large companies you typically have much less agency than you think and sometimes have to work on things that don’t resonate with you, large companies also have many different teams you can switch to.
So saying this should be the norm is what people have a problem with. Plus, moving to a different workplace is always an option.
If you decide to collect the paycheck and do the work, that’s okay too. But touting it as the norm and saying everyone should do it is gaslighting.
Yeah it was a bit reductionist. I guess it was my reaction to the negativity.
I think his experience is
quite common in big tech, and even swapping teams doesn’t seem to help in my own experience. It’s the rare teams that have any agency, or even clear ownership over the code. It seems by design but as a craftsman it is very frustrating.
I haven’t read anyone put it in words quite as well as Sean’s posts. This really is the nihilistic side of big tech that is rarely written about.
So I think it’s a unique insight - hence why I’m kind of baffled at the reaction. I think if you can relate to what he’s saying (it hits really close to home for me), it’s easy to sympathise with.
IDK why these vacuous corpo tropes appear on the front page of HN every now and then. Sounds like exactly what a quasi-technical, management-leaning staff engineer would say.
Sure, in the end we work for these faceless, meat-grinding machines. But more or less, we all have some semblance of autonomy, and I absolutely can choose not to work on a product that people hate. I can switch teams before switching companies.
To some extent, I also just do what leadership asks, keep my mouth shut, and collect paychecks. But whenever that happens, I don’t gaslight myself by writing a post on why it's supposed to be this way.
To me, this seems like someone who is married to their paycheck and would do whatever necessary to protect that.
It's great that they are recreating much of the fundamental software stack using LLMs. But if you're going to 'vibeslop,' at least do it in a language other than JavaScript.
I struggle to understand why anyone would want to generate code in TypeScript - unless what you're building truly can't be done in Go, Rust, or Kotlin; anything but JS.
I’m not sure how much of an improvement it really is to rewrite something from PHP to TypeScript while claiming security benefits.
I dream of a SQL like engine for distributed systems where you can declaratively say "svc A uses the results of B & C where C depends on D."
Then the engine would find the best way to resolve the graph and fetch the results. You could still add your imperative logic on top of the fetched results, but you don't concern yourself with the minutiae of resilience patterns and how to traverse the dependency graph.
You could build something like this using Mangle datalog. The go implementation supports extension predicates that you can use for "federated querying", with filter pushdown. Or you could model your dependency graph and then query the paths and do something custom.
You could also build a fancier federated querying system that combines the two, taking a Mangle query and the analyzing and rewriting it. For that you're on your own though - I prefer developers hand-crafting something that fits their needs to a big convoluted framework that tries to be all things to all people.
I think SQL alone is great if you didn't drink the microservice kool-aid. You can model dependencies between pieces of data, and the engine will enforce them (and the resulting correct code will probably be faster than what you could do otherwise).
Then you can run A,B,C and D from a consistent snapshot of data and get correct results.
The only thing microservices allow you to do if scale stateless compute, which is (architecturally) trivial to scale without microservices.
I do not believe there has been any serious server app that has had a better solution to data consistency than SQL.
All these 'webscale' solutions I've seen basically throw out all the consistency guarantees of SQL for speed. But once you need to make sure that different pieces of data are actually consistent, then you're basicallly forced to reimplement transactions, joins, locks etc.
I follow this religiously. The process of posting is manual but it works fairly well if your intention is good and you're not blog spamming in different forums.
But I intentionally haven't added a comment section to my blog [1]. Mostly because I don't get paid to write there and addressing the comments - even the good ones - requires a ton of energy.
Also, scaling the comment section is a pain. I had disqus integrated into my Hugo site but it became a mess when people started having actual discussion and the section got longer and longer.
If the write ups are any useful, it generally appears here or reddit and I often link back those discussions in the articles. That's good enough for me.
On my TODO list is aggregating all the above into one static comment thread that I can render. Not sure it's worth the trouble beyond linking to each network as I'm currently doing, since there's rarely any cross-network conversations anyway.
Damn. I got a bunch of idea around atproto from this comment. Also found out your blog. I wish digging out human written blogs wasn't such a chore. I like the idea of blogs but their discoverability sucks big time.
I just use HN as my comment platform. I have a Hugo short code that (very respectfully!) grabs the comments on a full rebuild, but only if those comments are not already cached and if the post is less than 7 days old. The formatting looks quite good on my site. Feel free to check it out at the bottom of this post: https://mketab.org/blog/sqlite_kdbx
> If the write ups are any useful, it generally appears here or reddit and I often link back those discussions in the articles. That's good enough for me.
I love Rust for what it is, but for most of my projects, I can’t justify the added complexity. Sure, there are a bunch of things I miss from the Rust world when I’m working on large-scale distsys services in Go, but introducing Rust in that space would be a recipe for disaster.
I guess the Go team knows that if they start adding everyone’s favorite Rust features, the language would become unrecognizable. So we’re not getting terser error-handling syntax or enums. Having union types would be nice too.
But I work in platform engineering, so my needs are quite different from someone writing business logic in Go. I understand that having a more expressive syntax is nice when you’re writing complex business code, but in reality, that almost always comes with a complexity/fragility tradeoff. That’s part of the reason no one wants to use Rust to write their business logic, despite it being so much more expressive.
For distsys, programming ergonomics matter far less compared to robustness and introspectability. So the Go runtime with Go syntax is perfect for this. But of course, that’s not true for all use cases.
Sorry for the rant - completely uncalled for. This is a cool project nonetheless :)
reply