Hacker Newsnew | past | comments | ask | show | jobs | submit | vrnvu's commentslogin

My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.

I'm definitely in favor of not pessimizing code and assuming you can just hotspot optimize later, but I would say to avoid reusing objects and using sync.pool if it's really not necessary. Go doesn't provide any protections around this, so it does increase the chance of bugs, even if it's not too difficult to do right.

What are the options? Repeated allocations are a huge performance sink.

Sort of related. Jepsen and Antithesis recently released a glossary of common terms which is a fantastic reference.

https://jepsen.io/blog/2025-10-20-distsys-glossary


Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills.

If I'm not going to change something, I'd rather not talk or give opinions.

Related: https://strangestloop.io/essays/things-that-arent-doing-the-...


I’m in the situation the article is talking about where I’m both suggesting advice and willing to do the work. But it requires me to have some allotted time and the boss says we don’t have the resources even 1 hour a week.

It’s like we’re moving chopped wood from the forest to the village and I suggest building a wheelbarrow but the boss says what we don’t have time for that we gotta move all this chopped wood. It’s crushing to have a job that could be very interesting but the tooling and processes sap all of that out.


Aye, someone full of ideas for other people to take ownership of isn't actually being helpful (unless that's explicitly their job)

You can’t know if you are going to change something. So, just talk and let there be a chance of being heard.

This is a better way to say it.

Talking at the right place at the right time on the right topic is.


>> Why is it not more popular?

Property, fuzzy, snapshot testing. Great tools that make software more correct and reliable.

The challenge for most developers is that they need to change how they design code and think about testing.

I’ve always said the hardest part of programming isn’t learning, it’s unlearning what you already know…


> Any time you are making decisions based on information that you know at compile time, you could apply this technique

I’d go further. Most business requirements are known at compile time.

Take the simplest example, dispatching a function based on a condition. If A then do_X, if B then do_Y.

People often reach for elaborate design patterns, dependency injection, or polymorphism here. But why? If the decision logic is static, don’t turn it into a runtime problem.

Inline the code. Move the ifs up. Write clear, specific functions that match your domain knowledge instead of abstracting too early…

Don’t make compile time problems runtime ones.


> when you can't tell what's blocking and what isn't.

Isn't that exactly why they're making IO explicit in functions? So you can trace it up the call chain.


Shocking to hear this news. I used to watch Danya's videos a lot... RIP


I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.


I've been applying a lot of principles and suggestions from TigerBeetle style lately, mainly in Rust and Go and I can’t recommend it enough.

- single entry point, near-zero deps

- ci locally and tested, one command to runs tests, coverage, lint etc

- property/snapshot/swarm testing, I love writing simulations now and letting the assertions crash

- fast/slow split + everything is deterministic with a seed

- explicit upper bounds + pool of resources. I still dynamically allocate but it makes code simpler to reason about

Thanks to the TB team for the videos and docs they been putting out lately.


Such a pleasure to read this, that TigerStyle is making a difference for you. Appreciate the kind words!


Mailing list yes, RSS yes....

Old, boring, simple, works.

No ads.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: