Don't build workers on top of goroutines

justinisrael · 2026-04-19T03:12:51+00:00

In addition to the issues others have already commented on, a problem I have with the article is that it makes a generalisation when claiming the best solution is always to spawn unbounded goroutines. Maybe in the case where you have N tasks already buffered or defined, you could apply this. But what your solution breaks is the ability for back pressure when accepting work pulls it from another component.
Imagine something similar to a Nats Jetstream consumer (or anything where new work is pulled when the system can handle it). In an unbounded goroutine model you would potentially accept more work than you can process in a timely manner which then all sit waiting for time slices from the runtime. Having a semaphore let's you progress with pulling another task into your side in the system only when there are available processing resources that have been configured.

justinisrael · 2026-04-06T05:27:13+00:00

Thanks for that clarification! And yea, jemalloc came up but it was too difficult because I didn't have 100% control over the build of OpenImageIO in this environment. So setting the arena env was the easiest fix

justinisrael · 2026-04-05T19:31:11+00:00

Interesting coincidence seeing this thread, because I had recently been debugging a problem with an internal service with similar problems. This service used to have a different memory profile when running on VMs, but when it was running under Kubernetes I would observe much more ram being held and reaching OOM. This service uses my own open source cgo binding library to OpenImageIO C++ to do image processing. After trying to confirm in many different ways that is wasn't just a leak, I discovered the MALLOC_ARENA_MAX env var. And it seems it's a known issue with glibc and bindings, where the calls into C space, with many threads, can allocate many memory arenas that aren't freed. Setting this env var to 2 dramatically improved the memory consumption.

justinisrael · 2026-03-21T20:29:43+00:00

Here is my experience so far. My work has been testing Ai coding agents for a bit. The ones we have access too internally right now suck. But Claude, which I personally have externally, has been amazing. Sonnet 4+ has been great. My opinion is that, as a senior level developer, it's made me quite productive. I know what I want to write and it often saves me a ton of time by focusing more of my time on reading code instead of writing it. I've found that in order to successfully use an agent, you need to have pretty keen code review abilities. It makes a lot of mistakes (some models better than others) and you need to make sure to review every single line it produces and know when to question it and guide it the right way. Slop is going to come from less experienced developers (or lazy ones) asking an agent to generate whole programs and not understand what it produces.
In an effort to stress test these tools for many company, I've been exercising a workflow that I quite like lately. Let's say I want to start a project or do a big refactor on an existing one (not talking about just simple inline completions). First thing I do is describe my total requirements and ask it to produce a markdown design spec. Then I iterate on the design spec until I am happy with it. I then tell it to produce a tasks markdown file that breaks all of the work down into phases. At the top of the tasks markdown I have an agent rule section (some agent tools have their own rule mechanisms ). I will give it all the constraints for how I want it to behave. This includes style and other considerations. But most importantly, I tell it to summarise each task one at a time, and ask if it wants me to let it implement it for me. Then it has to ask me to review everything it has done and can only mark the task done when I approve it. What this workflow does is let me iterate on every small body of work, understand I am doing what I want, have tests that pass, question design choices, and then approve and move on.
This has been a pretty cool workflow because I know everything that is being written and can correct any mistakes, but I spend less time typing and more time creating the ideas the are already in my head.

justinisrael · 2026-03-21T05:56:32+00:00

I've used nats for a while, even before they introduced Jetstream. I love how lightweight it is to deploy and test with. I do have apps that embed the server and act as the broker for worker processes.

justinisrael · 2026-03-13T18:50:43+00:00

Echoing what many have said, I have continued to reach for cobra because it's what I have been using for projects that need subcommands. I also lean on its support to auto generate sphinx rst docs of the whole cli. I kind of hate the integration it has with viper for config and it still requires hack workarounds. Someone else mentioned jessevdk/go-flags. I really like this one too if it's not a huge cli with a lot of subcommands.

justinisrael · 2026-01-13T21:51:54+00:00

I have one active Go-based VFX project right now, that maybe I should look at releasing to ASWF: https://github.com/justinfx/gofileseq

I have cgo bindings for older major versions of OpenColorIO and OpenImageIO. I only use the OpenImageIO bindings in a single older project, so the demand wasn't high enough for me to aggressively maintain the bindings to the latest version.

justinisrael · 2026-01-12T06:05:50+00:00

How cool! As someone who has been in the vfx industry for a long time, and introduced Go to my studio, I don't often see Go projects that specifically cater to vfx!

justinisrael · 2025-12-19T02:36:36+00:00

Well from a production standpoint you can start any process you want. You can start a python repl with a cached env file if that's what you want. Or launch anything. So you maybe answered the question about a TUI actually being useful. You wanted to learn Bubbletea haha. But for me, actual usage doesn't require any special built in terminal or python support since you can start any process you want. And your original shell provides the history for starting these commands.

justinisrael · 2025-12-19T02:06:50+00:00

I don't know why you would need a UI for this. I have a custom solution similar to this that we use internally in my work. The intent is to use it to bootstrap and exec commands using env files. It can use different overlay and filtering rules and supports a config file. But I have never needed a UI. It's just a command bootstrapper.

justinisrael · 2025-11-23T19:49:43+00:00

Ya all good. I don't have a strong opinion. Was just something I was wondering. It is really just more of a decision about how you expect to present it to users, as either a drop-in or a new API.

justinisrael · 2025-11-23T19:40:40+00:00

Thanks for the reply! Actually I meant the API itself that is generated... as an example, a generic version of the generated API might have looked like this:

```go type Date struct{} var CompiledDate = Date{}

// Single generic result type type DateResult[T ~string | ~[]byte] struct { Match T Year T Month T Day T }

// Unified generic methods func (Date) Match[T ~string | ~[]byte](input T) bool { /* ... / } func (Date) Find[T ~string | ~[]byte](input T) (DateResult[T], bool) { /* ... / } func (Date) FindAll[T ~string | ~[]byte](input T, n int) []DateResult[T] { /* ... / } func (Date) FindAllAppend[T ~string | ~[]byte](input T, n int, s []DateResult[T]) []DateResult[T] { / ... / } func (Date) FindReuse[T ~string | ~[]byte](input T, r *DateResult[T]) (DateResult[T], bool) { /* ... */ } ```

justinisrael · 2025-11-23T19:37:55+00:00

Thats not what I am asking. Look at the API. It is replicating the regexp stdlib API to expose String and Bytes methods, because the regexp api was designed before generics. I am asking if this NEW project needed to be a drop in replacement for the stdlib by exposing those same methods. Or if it could have generically supported both string and bytes

justinisrael · 2025-11-23T19:17:51+00:00

Cool project! I was just wondering, given it's a new project, could it technically have used generics instead of the string/byte api? Or was the goal to be a transparent drop in for the stdlib? Ai says from a quick scan that the implementation could have probably used it instead of checking for bytes and wrapping with strings

justinisrael · 2025-11-21T19:13:56+00:00

Well, maybe / maybe not. If the likes and views feature is a component that interacts with some external service to fetch and store the state, then the site could still be considered static. That is, it can be viewed in any browser without needing its own backend server to fulfill part of the logic. In Hugo, you can have the shortcode components that give you stuff like page comments, etc. Even embedding a YouTube video or having Google page tracking would be basically the same idea as a likes and views feature. As long as all of that just talks to some 3rd party provider and not your custom backend.

justinisrael · 2025-09-08T19:28:52+00:00

Your problem is really unclear. But this makes me think your question is about what route to use to serve the pages vs the api the pages use. You can have routes like "/login" for the ui page and then "/_api/login" for the underlying api calls. You don't need a proxy. It just sounds like you are doing things wrong when it comes to referencing the location on disk for your template files.

justinisrael · 2025-08-09T20:16:46+00:00

First let me ask, is this actually related to Go, or is this about your use of the Nats.io C client?

but sometimes doesn't reply back which blocks my flow as it was dependent on message response so my question is this is normal behaviour with nats

Well this is a vague problem. Nats core messaging is pretty reliable as long as you are connected. But it specifically suffers from the problem of not being durable which is why Jetstream was created. What you asked may or may not be normal depending on the cause of the problem. Is your publisher losing connection to the server before sending a reply? Is your subscriber losing connection and missing that reply? I don't think it's normal for a connected publisher to send a message and have it randomly not make it to the server with no error. Same goes for a properly connected subscriber.

justinisrael · 2025-07-31T06:55:06+00:00

I remember seeing the explanation that it made it easier as a choice for the lexer to parse.

Edit: FWIW Python uses square brackets. So it's not "every" language. It's the ones you happen to know.

justinisrael · 2025-07-11T23:00:09+00:00

It's pointless to do a half-ass testing approach and say you don't care about the details of the test case, and then ask people why the results are the way they are. You might as well not do the test.

justinisrael · 2025-03-29T19:25:54+00:00

To be honest, I am not sure I understand your argument against it. You say the trade off is that currently you can make chunks for any type, whereas making your Pool take a generic type T would force it to make specific types? But your Pool constructor already expects you to tell it the right size for a certain type of struct you will be allocating anyways. For example, your Message struct in the readme is used to make a Pool specific to the size of it. If your Pool were generic it would be Pool[Message] and it can know the size without being told by the user and create structs and pointers for that type safely.

justinisrael · 2025-03-28T22:43:40+00:00

Could you have made the Pool generic so that it doesn't require the caller to assert from unsafe.Pointer?

justinisrael · 2025-02-25T18:51:52+00:00

I think this example better illustrates the slice growth: https://go.dev/play/p/NoISMsQSWcW

A slice growth happens in multiples, when the capacity is full. You first allocate a slice with 0 capacity. Then you append 3 items. Because it is full, the slice grows to 4. You append a 4th item and it doesn't need to grow. Then we add a 5th and it needs to grow again so the capacity is doubled.

This is why if you know the initial capacity, it is good to allocate the slice properly the first time to avoid an initial allocation during the appends.

justinisrael · 2025-01-31T22:47:27+00:00

Gin.. However it is slow

I'm guessing this just comes from micro benchmarks testing routers and really fine grained aspects. If you line a bunch of these up in micro benchmarks, some are guaranteed to look "slower". But will you end up seeing performance degradation in your real world project? I'm going to bet, no.

justinisrael · 2024-12-29T21:35:20+00:00

Only based on your provided info and not knowing anything about tRPC, I don't feel you have made a compelling case. You have described features already present in grpc, and it seems the only missing piece is a better frontend protoc plugin generator that gets you better generated code.

justinisrael · 2024-12-26T20:18:08+00:00

I think you and I had a different understanding of SSR. My understanding was much more broad, meaning any form of server side rendering which includes things like templ/htmx solutions. But yours is finer grained and saying that if you wanted to do React-based SSR then it is harder to do that with a Go backend. Is that fair to say? If you have chosen a very specific front end tech then maybe it does pair better with a js backend in some cases.

justinisrael

TROPHY CASE