squirrellous

Given the site where this is posted and the screenshot, is the author an engineer turned fiction writer? Kudos if true. Posting these must take a lot of courage.

As a former employee, the engineering culture at Google gives me old-school hacker vibes, so users are very much expected to “figure it out” and that’s somewhat accepted (and I say this with fond memories). It’s no surprise the company struggles with good UX.

LLMs are good at in-distribution programming, so inventing a new language just for them probably won’t work much better than languages they were already trained on.

If you could invent a language that is somehow tailored for vibe coding _and then_ produce a sufficient high quality corpus of it to train the AI on them, that would be something.

This is painfully clear once you’ve worked in a non-first-world country. Everybody is just working a job.

> The guy is a coder through and through.

I’d be proud if someone says that about me one day. Hope Mitchell will share the sentiment.

Some juniors do figure it out, but my experience has been that the bar for such juniors is a lot higher than pre-AI junior positions, so there is less opportunity for junior engineers overall.

It’s possible to build this around protobuf. Google has a rich internal protobuf ecosystem that does this and supports querying large amounts of protobuf data without specifying schemas. They are only selectively open sourced. Have a look at riegeli if you are interested.

https://github.com/google/riegeli

I don’t understand this argument. It seems to originate from capnp’s marketing. Capnp is great, but the fact that protobuf can’t do zero copy should be more an academic issue than practical. Applications that want to use a schema always needs their own native types that serialize and deserialize from binary formats. For protobuf you either bring your own or use the generated type. For capnp you have to bring your own. So a fair comparison of serialization cost would compare:

native > pb binary > native

vs

native > capnp binary > native

If you benchmark this, the two formats are very close. Exact perf depends on payload. Additionally, one could write their own protobuf serializer with protoc they really need to.

I like this (paid) blog for its technical dives and HFT expertise, but the programing language opinions are a little click-baity and not worth the time.

Not giving up the address space feels like an anti feature. This would mean, among other things, that access to the DONTNEED memory is no longer a segfault but garbage values instead, which is not ideal.

Agree with the general point. I’d maybe add that a lot of times it’s the scale of the profit that makes something a net negative for humanity, not the percentage based margin. A lot big tech started small and in the early stages created a ton of positive value, sometimes with a respectable margin, but once they are at billions of market capitalization and starts chasing profits for investors, the positive societal value gets eroded.

And another party for people who sign their emails with 3-letter usernames? :)

I think the reason going into music is that way because the industry is already hyper competitive as is, and the “selection” process for talent shifts earlier. Perhaps CS will go that way eventually.

Anyway, when I made the comment, I was thinking it should be an elective and intended for people who either aren’t that familiar with Linux or want to become even more comfortable with it. There are certainly plenty of such students in my experience, myself included when I was in college.

Also just to be clear, this shouldn’t be just about “being able to run Linux at home” level of material, but things like writing non trivial applications using Linux subsystems and being able to troubleshoot them.

There should be a course on Linux. Not your typical operating systems course where you write a toy OS and teach a bunch of theory, but rather a deep dive into various Linux subsystems, syscalls, tooling, etc.

I probably should’ve qualified the “best medium” with something more specific. But I’ll submit two reasons why email is best for me and maybe some others:

- Email is the one thing that isn’t tied to any platform and ~always works, so it’s worth it to put in some effort into managing subscriptions / filters / labels / etc knowing that they will pay off indefinitely.

- It’s nice to consume content in the original format intended by the author, so I prefer receiving an article link in the email with a preview, and clicking through to read it. A dedicated reader invariably has problems rendering non-text content and doesn’t have all the features of a browser.

Not a user (yet) but just want to say I concur that email is the best medium for RSS feeds, so kudos.

I think the article glossed over a bit about how to interpret the table and the formula. The formula is only correct if you take into account the memory hierarchy, and think of N as the working set size of an algorithm. So if your working set fits into L1 cache, then you get L1 cache latency, if your working set is very large and spills into RAM, then you get RAM latency, etc.

One of the mentioned examples sounds like the compressor is taking advantage of the SDDL by treating row-oriented data as stripes of column-oriented data, and then compressing that. This makes me curious - for data that’s already column-oriented like Parquet, what’s the advantage of OpenZL over zstd?

Rust won’t even succeed at replacing C++. There are technical and cultural issues at play. C++ has evolved a lot and still does some things better than Rust (dynamic linking, for example). Rust will be another popular systems programming language. There will be better ones. People will take their picks.

Title feels a bit too click-baity. The article first says multi-consumer queues break global ordering (but preserves per-consumer ordering), and then proposes a data structure that completely abandons any ordering, without explaining why that’s ok. It’d be good to at least acknowledge that queues have their uses.

Also if this is really about bags, why not open with that?

Great idea and execution!

Some of the example links visibly takes me through 4 redirects. I’m wondering if it’d be useful to actually store the redirect results and jump directly to the resolved page. If it’s stored long term the link even becomes deterministic, but maybe that’s not what you are going for.

Is there anything C# _doesn’t_ have? :-)

It feels like C# has an answer to every problem I’ve ever had with other languages - dynamic loading, ADTs with pattern matching, functional programming, whatever this expression tree is, reflection, etc etc. Yet somehow it’s still a niche language that isn't widely used (outside of particular ecosystems).

Between mold and this, the linker space appears to be going through a renaissance.

Does anyone know if it’s reasonably easy to use elf2 as a standalone linker in a c/c++ toolchain? Or is it specially built just for Zig?

As usual the real struggle is getting everyone to agree on a configuration language :-)

We use protobuf as schemas for json config. Protobuf has builtin json support and works across languages. It’s great for multi-language projects.

Even new projects have good reasons to use c++. Maybe the ecosystem is built around it. Maybe competent c++ programmers are easier to find than rust ones. Maybe you need lots of dynamic loading. Maybe you want drop-in interop with C. Maybe you’re just more comfortable with c++.

I agree with the discipline aspect. C++ has a lot going against it. But despite everything it will continue to be mainstream for a long time, and by the looks of it not in the way of COBOL but more like C.

Thinking back, the issue I had with multi-threaded code was two-fold:

- Things like "continue", "step" are no longer a faithful reproduction of what the program does in real time, so it's more difficult to understand the program's behavior. Some timing-related bugs simplify disappear under a debugger.

- There's usually some background thread that's logging things to console, which reduces to problem 2 in my comment.

I haven't used Go that much. I imagine since goroutines are such a cornerstone of the language, the go debugger must have some nifty features to support multi-(green)-threaded debugging?

IME console-based debuggers work great for single-threaded code without a lot of console output. They don't work that well otherwise. GUI-based debuggers can probably fix both of those issues. I just haven't really tried them as much.

pdb is great for python, though.

This might be an unpopular opinion - I think const by-value parameters in C++ shouldn’t exist. Const reference and mutable values are enough for 99% cases, and the other 1% is r-value refs.

Regarding const by-value parameters, they should never appear in function declarations (without definition) since that doesn’t enforce anything. In function definitions, you can use const refs (which have lifetime extension) to achieve the same const-correctness, and const refs are better for large types.

Admittedly this further proves the point that c++ is needlessly complicated for users, and I agree with that.

Cool! Thanks for the example. The aforementioned work thing requires MAP_SHARED as well which IIRC is the reason it would fail when used together with files and huge pages, but private mappings work as you show.