materielle

If anything, tech is still one of the better off fields in the university.

Look at history or literature programs for where this is heading. I’d imagine that most literature majors don’t even read at all these days. As recent as 50 years ago, the requirement involved hundreds of pages of reading per week, over a sustained 4 year period.

Honestly, just close down the university at this point, if all it wants to do is print out degree certificates for social signaling in the job market.

They didn’t do the best with what they had. Sure, some problems were caused by C backwards compatibility.

But so much of the complexity and silliness of the language was invented by the committee themselves.

I believe those two languages themselves self-host. So not saying it’s impossible. And I have no clue about the technical merits.

But if you look around programming forums, there’s this ideas that”Ocaml is one of the leading languages for compiler writers”, which seems to be a completely made up statistic.

Most people could afford to pay more for airline tickets. It’s just that they’ve done the math and they don’t want to.

I plan carefully and don’t have to rebook my flights. I pack my own food. I leave behind that second pair of shoes so that I only bring a carry on.

I’d rather do all of this so that I have an extra $100 to spend on a nice meal or experience at my destination.

If any of those things are important to you, then you can have them! You just have to pay for them.

I don’t see why the government needs to mandate that airlines provide certain services like checked bags (which would require increasing minimum ticket prices). Why not use price signals to allow each individual to tailor the experience for themselves?

I feel like everyone leaves out that last part. Everyone wants extras when you don’t have to pay for them. Are the people arguing for more regulation mentioning the tidbit that ticket prices will go up?

I know this is veering into the political, but I just don’t understand the ideology that most people seem to have. Which is that we need to use the power of the government to force people to buy things they don’t want.

Libraries are maintained by other humans, who stake their reputation on the quality of the library. If a library gets a reputation of having a lax maintainer, the community will react.

Essentially, a chain of responsibility, where each link in the chain has an incentive to behave well else they be replaced.

Who is accountable for the code that AI writes?

This doesn’t seem obvious to me. Trade happens because it mutually beneficial.

The counter factual to reducing trade isn’t that we would manufacture the equivalent amount of goods here and be just as rich.

It’s that we would be poorer. And certain goods would cease to exist, and all of us would have to learn to live with less because it’s simply infeasible to manufacture everything here.

Sure, maybe a committee way back in 1990 could have shaved off of some the warts and oopsies that Guido committed.

I’d imagine that said committee would have also shaved off some of the personality that made Python an enjoyable language to use in the first place.

People adopted Python because it was way nicer to use compared to the alternatives in say, 2000

Google has all sorts of great infra projects that simplify complex domains. Those are solved problems now, so nobody notices it.

The existence of incidental complexity isn’t evidence that the counter factual is less complexity.

We should bring back elevator operators. And station a traffic guard on every corner instead of traffic lights. Let’s bring back tool booth operators. And let’s delete Google calendar and bring back secretaries while we’re at it.

The issue is that Cursor tends to be demoed for incredibly small, green, and simple projects.

Most of us are working on codebases with at least over 10 million lines. I would love an AI agent that can massive infrastructure migrations with only a bit of oversight. Didn’t Shopify do something like that recently?

I think this is still an area that needs a lot of work.

Perhaps there were peaks and troughs in individual technologies. Late 2000s / early 2010s felt like a good time for operating systems, for instance.

But is everyone forgetting having to navigate through Flash websites and Java Applets using Internet Explorer, for instance?

Also, people are just forgetting. There’s nostalgia in this thread about the iTunes desktop app, for instance. That program has been a pile of trash for as long as I can remember back in the 2000s.

I used to work on distributed systems, and network partitions were a frequent enough occurrence that they weren’t considered an extraordinary event. By that, I mean that we wouldn’t page during network partitions because it was still considered normal system operation. Our design was designed from the ground up to consider network partitions as a frequent and normal operational state.

What we did do is watch SLAs. If the network partition continued for too long, then our data quality would degrade over time. So we would page based on data quality.

I don’t know the answer to the actual question you asked, I would be curious to know, too.

If you remove them, Ladybird is closer to 60% and Servo to 50%.

Still good, and the point still stands that they are making amazing progress. But probably more accurate because that last 10%-20% are going to get harder to chip away at.

For almost any functionality missing in the standard library, you could point to 2-3 popular crates that solve the problem in mutually exclusive ways, for different use cases.

Higher level languages like Go or Python can create “good enough” standard libraries, that are correct for 99% of users.

Rust is really no different than C or C++ in this regard. Sure, C++ has a bigger standard library. But half of it is “oh don’t use that because it has foot guns for this use case, everyone uses this other external library anyways”.

The one big exception here is probably async. The language needs a better way for library writers to code against a generic runtime implementation without forcing a specific runtime onto the consumer.

1) Built at least 100 years ago. De-facto relics of a government and society that no longer exists.

2) Things built by the people in spite, not because, of its public policy and government.

If anything, what interests me about NYC is “why isn’t worse?”. There is something amazing about NYC: how a city and civilization can be so successful in the face of government incompetence and public policy failures at every level.

There are two problems with automated testing. 1) tests take too long to run 2) difficult to root cause breakages.

Most devs solve this with making unit tests ever more granular with heavy use of mocks/fakes. This “solves” both problems in a narrow sense: the tests run faster and are obvious to root cause breakages.

But you didn’t actually solve the problem. Since the entire point of writing tests in the first place was to answer the question: “does my system work”? Granular and mocked unit tests don’t help much.

However, going back to the original question, we can actually reframe the problems as: 1) a work scheduling problem and 2) a signal processing problem.

Those are pretty well understood problems with good solutions. It’s just that this is a somewhat novel way of thinking of tests, so it hasn’t really been integrated into the open source tool chain.

You could imagine integration tests automatically be correlated to a micro service release. Some CI automation constantly running expensive tests over a range of commits and automatically bisecting on failure. Etc.

Put another way, automated tests don’t go far enough. We need yet another higher layer of abstraction. Computers are better at deciding what tests to run and when, and are also better at interpreting the results.

But let me offer a different perspective: Hyrum’s law is neither a technical contract nor a social contract. It’s an emergent technical property in a sufficiently used system.

How you respond to that emergent property depends on the social context.

If you are a FOSS maintainer, and an optimization speeds up 99.99% of users and requires 0.01% to either fix their code or upgrade to a new API, you ship it.

If you are working at a big tech company, you need both the optimization and breaking 0% of the company. So you will work across teams to find the sweet spot.

If you are an enterprise software company, and you change breaks 0.1% if users, but that user is one of the top 5 contracts, you don’t ship.

I remember that famous rant about how Go’s stdlib file api assumes Unix, and doesn’t handle Windows very well.

If you are against “worse is better” like the author, that’s a show stopping design flaw.

If you are for it, you would slap a windows if statement and add a unit test when your product crosses that bridge.

First off, the only way to express union types is with runtime reflection. You might as well be coding in Python (but without the convenient syntax sugar).

Second off, “if err != nil” is really terrible in parsers. I’m actually somewhat of a defender of Go’s error handling approach in servers. Sure, it could have used a more convenient syntax. But in servers, I almost never return an error without handling it or adding additional context. The same isn’t true in parser’s though. Almost half of my parser code was error checks that simply wouldn’t exist in other languages.

For Rust, I think the value proposition is if you are also writing a virtual machine or an interpreter, your compiler front end can be written in the same language as your backend. Your other alternatives are C and C++, but then you don’t have sum types. You could write the front end in Ocaml, but then you would have to write the backend and runtime in some other language anyways.

People see two pieces of duplicate, or even similar code in a monorepo, and they feel the urge create some sort of shared directory to de duplicate them. The problem, is this introduces more edges to your graph, which over time increases the monorepo complexity exponentially. And who is going to maintain that shared directory?

Even in a mono-repo, you should probably start off by copy and pasting code around, until you figure out how to design and find ownership for an actual well thought through public api. And maybe for some code, that never happens.

Also, like many things, people cargo cult big tech ideas without understanding why they work. In Google, the monorepo has two key features: 1) every directory has an owner by default 2) the owner can control build target visibility lists.

That means that the ownership team controls who depends on them. By default, everything is private.

Basically, every directory should either be a project, owned by a team. Or some common library code, owned by the library maintainers.

The other thing, is library maintainers need to be discerning with what APIs and code they support. Again, a common refrain I here is “when it doubt, it’s better to put it in the company’s common library to promote code reuse”. That’s the exact wrong way to think about it. Library teams should be very careful about what APIs they support because they will be on the hook maintaining them forever.

This is all to say, I can see how monorepos fail. Because people cherry-pick the ideas they like, but ignore the important things which make them work at Google: 1) default code owners 2) visibility lists that default to private 3) discerning library teams that aggressively reject code additions 4) don’t be too dry, if it can’t be exposed in a public api, just copy and paste, just like you would in a microservice.

I remember this being true 10 years ago. Java web servers I maintained had a huge problem with tail latency. Maybe if you were working on a 1 qps service it didn’t matter. But for those of us working on high qps systems, this was a huge problem.

But like I said, I know the Java people have put a ton of work in to try to close the gap with Go. So maybe this isn’t true anymore.

This tends to work well for most crud api servers, since you allocate “context, request, and response” data at the start of the handler function, and deallocate at the end. Most helper data can also be tied to the request lifecycle. And data is mainly isolated per-request. Meaning there isn’t much data sharing across multiple request.

This means that the borrow checker “just works”, and you probably won’t even need lifetime annotations or even any special instructions for the borrow checkers. It’s the idealized use case the borrow checker was designed for.

This is also the property which most GC languages like Java, Go, and C# exploit with generational garbage collectors. The reason it “works” in Java happens to be the same reason it works in Rust.

If your server does need some shared in-memory data, you can start by just handing out copies. If you truly need something more complicated, and we are talking about less than 10% of crud api servers here, then you need to know a thing or two about the borrow checker.

I’m not saying to rewrite web servers in Rust, or even advocating for it as a language. I’m just pointing out that a crud api server is the idealized use case for a borrow checker.

“Less languages features, but a better compiler” was originally the aspirational selling point of Go.

And even though there were some hiccups, at least 10 years ago, I remember that mainly being true for typical web servers. Go programs did tend to use less memory, have less GC pauses (in the context of a normal api web server), and faster startup time.

But I know Java has put a ton of work in to catch up to Go. So I wonder if that’s still true today?

The anticompetitive schemes they engage in are so complicated and require so much background context that it’s basically impossible to explain to even subject matter experts, much less the casual reader.

Not a leading question, I’m curious if there are any technical complications with fast-reload Go.

I think this is an important detail, because it’s way safer than in C, where you can just re-interpret memory accidentally and the compiler won’t stop you. Go will panic the thread. Ok, but we already knew that.

The subtle bit is that it’s even a bit safer than most dynamic languages like Python. Because the programmer has to explicitly handle the “unexpected type” case. And because of how verbose Go’s error handling is, every caller up the stack has to consider the error, enforced by the type system. This is different than in Python, where every variable is type any at compiler time, so every line can throw a time error and the callers probably don’t handle it. Even when using “any”, Go’s type system enforces that both the caller and callee consider the “unexpected variable type case”. Overall, it’s still way more of a controlled failure compared to dynamic languages.

It’s great that Go has generics now, to do away with some any hacks. And in general you should avoid any in Go. But when you need it, I think Go actually has a really great reflection API (especially with how it composes with other features like error handling). It’s a bit looked over I think because the difference is subtle at first glance.

The fact that they explicitly call out this practice is probably a sign that they lay off a larger percentage of new hires compared to the average company. Otherwise, why mention it?

I don’t think that article discusses the timeout issue. So all the issues mentioned in that article, plus the timeout issue.

The end result is you have to explain to every Go developer that they can’t use the http client as-is.

Start searching for http client usages in GitHub. You’ll probably find more incorrect usages than correct ones.

It’s a solvable problem, you write a wrapper http client once and tell everyone to use it. But it’s a nasty foot gun to have to explain all this.

The other half is hyrum’s law.

There’s a lot of situations in reasonable unordered map implementations where the elements, by chance, do happen to be ordered. Just due to arbitrary implementation decisions.

But the Go spec says that maps are unordered, and library writers want to reserve the right to change the implementation in the future.

So always ransoming the dict prevents code from accidentally depending on some specific map implementation detail.

The specific examples don’t ring true to me though.

Instead of named arguments, use the functional optional pattern.

An ordered map can be implemented as a slice with a get function. If you want to stamp out some code duplication, Go has generics and iterators these days.

What I really miss are enums. Specifically, the ability to map two value sets to each other and get a compile time error if the mapping becomes stale due to a new value.

And other assorted stuff. Like better nil handling, the weird time and http client libraries, nil interfaces and slices, and so on.