Hacker News Reader

broken_broken_on 8 months of OCaml after 8 years of Haskell in production (2023)

I wrote a Lox compiler and interpreter in OCaml a few years ago: https://github.com/gaultier/lox-ocaml

No idea how it holds up, it was my first try at a compiler, but it’s quite small. I was following the Crafting Interpreters book.

broken_broken_on Show HN: Retry a command with exponential backoff and jitter (+ Starlark exprs)

Hey, that’s funny, I wrote a blog post about the many ways you can implement such a program, and it was discussed on HN: https://news.ycombinator.com/item?id=42103200

broken_broken_on Way too many ways to wait on a child process with a timeout

Thanks for the suggestion, I have added a short section about threads.

broken_broken_on Way too many ways to wait on a child process with a timeout

Many thanks! I have added it to the article in due form now.

broken_broken_on You've just inherited a legacy C++ codebase, now what?

Author here, thanks! A second article will cover this, but the bottom line is that it entirely depends on the team and the constraints e.g. is a GC an option (then Go is a good option), is security the highest priority, etc.

I’d say that most C++ developers will generally have an easy time using Rust and will get equivalent performance.

But sometimes the project did not have a good reason to be in C++ in the first place and I’ve seen successful rewrites in Java for example.

Apple is rewriting some C++ code in Swift, etc. So, the language the team/company is comfortable with is a good rule of thumb.

broken_broken_on You've just inherited a legacy C++ codebase, now what?

Fair point!

broken_broken_on Gobs of data (2011)

The column type was bytea (basically blob) so it should be stored as is by the database. The profiling showed the hotspots in the gob package directly.

The docs explicitly mention that invalid input will make it panic and that can be confirmed by reading the code or fuzzing the input.

From my understanding, there is no compile time schema so everything is done with runtime reflection and that is bound to not be super fast. Granted, JSON is the same on paper, I would guess that the JSON package had more eyes on it and optimizations.

In our case, everything was using JSON except this one component due to some historical oddity so it was also a win in terms of simplifying.

broken_broken_on Gobs of data (2011)

Just finished removing this encoding in our production services.

It panics on malformed input which is a no go for us since high availability is really important for us, and it showed quite a lot in the performance and memory profiles (roughly 5 times the time and memory as doing the same with JSON).

The code was converting some data to gob, and storing it in the database for later.

We now just do the same but in json, it’s human readable and Postgres validates that the data is valid JSON.

And unmarshaling it does not panic.