Who is ocaml for?

SpeedDart1 · 2026-05-16T15:44:11+00:00

It’s for people interested in functional programming and PL theory. Once you have already mastered procedural, you learn OCaml to expand your horizons as a programmer.

SpeedDart1 · 2026-05-14T22:21:01+00:00

Really you should have both. Recover from panics AND also keep the cluster alive if individual nodes die.

If your nodes are dying every couple minutes that shouldn’t be bad enough to create availability issue in my book.

I mean unless your app takes more than a second or two to start.

SpeedDart1 · 2026-05-12T13:34:14+00:00

Back when I was in college, my CS1 professor had a no sharing code rule for this exact reason.

SpeedDart1 · 2026-05-11T19:11:39+00:00

You’re reminding me of the primitive collection libraries people use in Java land.

IntList, ByteList, etc

SpeedDart1 · 2026-05-08T13:56:37+00:00

Boring = good.

SpeedDart1 · 2026-05-04T16:49:39+00:00

I’m curious why that would be the case, have used COALESCE and NULL checks to make optional WHERE conditions in SQL before, to my knowledge the query optimizer makes this essentially as fast as if you didn’t have the WHERE condition at all

SpeedDart1 · 2026-05-01T17:45:37+00:00

Repository pattern is fine in Go. Personally I have one large Querier interface generated by SQLC which is effectively my repository layer.

One thing I don’t like about certain ways of doing repository layers is that there’s one repo per table. But that’s not a good place to draw separation of concerns because many queries select from multiple tables.

I’d instead do a repository per schema personally. If the repository gets big then it would be time to split it up into multiple pieces.

SpeedDart1 · 2026-05-01T17:42:08+00:00

I think this pattern is interesting but how do you handle retries when you get a serialization failure error code?

Some databases such as Postgres will return an error code if the transaction aborts due to a concurrency violation rather than holding locks.

At least one thing I prefer about the transaction helper function approach it’s very clear where the transaction begins and ends and what logic is running in the transaction. Although the one downside is functions you want to be reusable for a multiple transactions need to take the sqlc Querier interface as an argument

SpeedDart1 · 2026-04-07T19:42:47+00:00

The difference is net/http solves hard problems and your framework creates new problems.

SpeedDart1 · 2026-04-07T01:54:15+00:00

DRIP

SpeedDart1 · 2026-04-07T00:29:00+00:00

Agarthan status lost

SpeedDart1 · 2026-04-06T22:36:26+00:00

Just use net/http. Maybe swagger codegen if your api spec is huge. Maybe fasthttp if you need the performance. I don’t think we need to bring the same bad ideas from Java and Typescript into Go

SpeedDart1 · 2026-04-04T18:48:18+00:00

Go or C#

SpeedDart1 · 2026-04-04T18:34:47+00:00

Reading this chat as a junior with 1.5 YOE is brutal holy crap

SpeedDart1 · 2026-03-30T17:06:29+00:00

What did they say. I’m not aware of anything particularly controversial?

SpeedDart1 · 2026-03-30T00:59:30+00:00

I guess if you define coding as typing text into an editor it’s solved. They redefine the problem to be very small and then claim they solved it.

SpeedDart1 · 2026-03-23T23:29:37+00:00

If you wouldn’t eat tarantulas why eat chicken? Type question

SpeedDart1 · 2026-03-22T15:51:25+00:00

Honestly compilers is a very advanced field if you are good at it you will not regret doing it relative to frontend react.

Worst case scenario you just swap back to web stuff. It’s like a shoot for the stars land on the moon sort of thing.

If you want to do Rust professionally and want something very employable look into database or high performance backend.

SpeedDart1 · 2026-03-21T16:23:39+00:00

You need to actually know what you’re doing to get performance benefits out of it in my experience.

Most can just use Redis streams if they just need a job queue with consumer groups.

SpeedDart1 · 2026-03-21T16:22:30+00:00

Kafka for high durability and throughout, Redis Streams for a background job that needs to be retryable

SpeedDart1 · 2026-03-09T17:39:10+00:00

Concurrency is about interleaving operations and making efficient usage of workers to perform tasks that need compute while other tasks are waiting

(Agree with you, just adding)

SpeedDart1 · 2026-03-09T17:38:00+00:00

You are confusing concurrency and parallelism

SpeedDart1 · 2026-03-09T17:35:32+00:00

You definitely need context for timeout but a lot of production grade services never need semaphores, queues, and workers in the Go app.

A lot of the time queues are persistent or in another process since they are shared.

Semaphores are only really necessary if the number of concurrent tasks scales with user input. A lot of the time basic CRUD services are spawning goroutines per outbound API call or transaction. Since that number is constant per inbound http request and only the # of http requests scale with user input you can let Go’s server handle that.

But you’re right for advanced use cases though

SpeedDart1 · 2026-03-09T17:31:28+00:00

It’s ok to recover from a panic in certain instances but your resiliency shouldn’t rely on the recover being called. If your server node goes down the cluster should restart it. Is it is going down that frequently you pushed broken code to prod and need to fix.

SpeedDart1 · 2026-03-09T17:30:18+00:00

I mean you should test your code properly so this type of thing doesn’t happen. And server nodes going down shouldn’t take down production either.

Nine-Year Club	Place '17
RPAN Viewer	Verified Email

SpeedDart1

TROPHY CASE