poorlyknit

This is a cheap overgeneralization.

What can we do to make rent-seeking hurt society less? Imo we should start by decoupling money from power. Right now, people are forced to participate in the rent-seekers game because his wealth implies power over them.

A zipcode should be plenty and grocery websites do that already.

Very cool :) I got a good enough score in the basic scenario by playing around a bit but it would be cool if you could link some kind of tutorial (e.g. to a digital PID video or something like that).

The fact that it happens

    1) at/around powers of two
    2) regardless whether using GC or preallocating

makes me think its got to do with cache sizes. For example, the M2 macbook has around 16MiB of cache, which gives you approximately 2 million ~ 2^20 nodes where each node has a 64 bit number and a 64 bit pointer.

The jumps in your measurements could be related to the cache hierarchy. On Linux (probably macOS too) you should be able to run "perf stat ./mergesort" to show you the hitrate of your CPU's caches.

I'd be interested in a follow-up post :)

Elm comes to mind. Mentioned a bunch on HN but you probably wouldn't call it widely used...

Well no, obviously. Nix has not solved the rice theorem. But you'll have this problem whether you're using BuildKit or Nix. Difference is with Nix the final image only contains your explicitly stated dependencies. I.e. no apt, no Python, no Perl, no cacerts unless you explicitly include them.

Like it or not, team dynamics are a part of engineering.

Not OP, but I think it's a valid approach.

You gain: Model consistency guaranteed by the database, your backend basically only acts as an external API for the database.

You lose: Modularity, makes it harder to swap out databases. Also, you have to write SQL for business logic which many developers are bad at or dislike or both.

I've seen a system running on this approach for ten years and it survived three generations of developers programming against this API. There's Python wx frontends, web frontends, Rust software, Java software, C software, etc. They all use the same database procedures for manipulating the model so it stays consistent. Postgres is (kinda, not very) heavy for small projects but it scales for medium up to large-ish projects (where it still scales but not as trivially). One downside I've seen in this project is that some developers were afraid to change the SQL procedures so they started to work around them instead of adding new ones or changing the existing ones. So in addition to your regular work horse programming language you also have to be pretty good at SQL.

IMO the Python version provides more information about the final state of res than the Go version at a glance: It's a list, len(res) <= len(foo), every element is an element of foo and they appear in the same order.

The Go version may contain some typo or other that simply sets result to the empty list.

I'd argue that having idioms like list comprehension allows you to skim code faster, because you can skip over them (ah! we're simply shrinking foo a bit) instead of having to make sure that the loop doesn't do anything but append.

This even goes both ways: do-notation in Haskell can make code harder to skim because you have to consider what monad you're currently in as it reassigns the meaning of "<-" (I say this as a big Haskell fan).

At the same time I've seen too much Go code that does err != nil style checking and misses a break or return statement afterwards :(

Effect systems spring to mind but they're rather esoteric (in the Java world).

Try using it for concrete problems you have today, start small. I used it to write a small calorie counting web app and some other tiny projects and picked it up that way.

There's no null in Haskell to check for. Go check it out!

This would be even more palatable if it involved some more design patterns.

Does that change anything though?