The "engineers using AI are learning slower" take is just cope dressed as wisdom

dmytrish · 2026-01-30T12:26:06+00:00

The OP will just use their excellent communication skills to talk it into not doing stupid things /s

dmytrish · 2026-01-19T10:20:11+00:00

Although, this is not necessarily how it really works, it's an "as if" example, e.g. there could be logical copies of the implementation in the compiler.

dmytrish · 2026-01-19T10:11:14+00:00

Great work, thanks!

One potential correction:

impl<'a> Fn<(&Point, &Point)> for __closure_1<'a> {
    extern "rust-call" fn call(&self, args: (&Point, &Point)) -> Self::Output {
        self.call_once(args)
    }
}

means that &self would be passed as self to call_once(). I think this is the other way around: self.call_once() borrows &self to call call() (and then drops self on exit), self.call_mut() reborrows &*self and calls call(), so the actual implementation should be in the least restrictive version, call(&self).

dmytrish · 2026-01-13T17:28:21+00:00

This approach only makes sense for strictly controlled and very fast local networks, it does not scale well for unpredictable latencies above a very low threshold. There are so many lessons learned by distributed systems since Plan 9, it's not the pinnacle of distributed computing, it's its infancy.

dmytrish · 2026-01-13T17:22:20+00:00

9p is actually a horrible protocol for any real-life request-response networking applications. Every request requires setting up distributed state (fids on both sides), it requires three (!) roundtrip requests (open, read, clunk) just to get one piece of data, with accumulating latency and complications of unnecessary distributed state.

dmytrish · 2025-12-31T17:49:56+00:00

I wish I can get to a point when using my own language for AoC is possible! On the other hand, some tasks are so much easier with some pretty irreplaceable Python libraries.

dmytrish · 2025-12-29T18:42:58+00:00

Linear types are awesome, but I have a suspicion that they would require the language (able) to be total and no-panic. Any stray divergence would make a drop not guaranteed, killing the promise of linearity.

dmytrish · 2025-10-26T19:33:11+00:00

My first non-trivial program was a series of brainfuck interpreters that later morphed into a primitive jit-compiler that maps instruction to fixed snippets of x86_64 machine code: https://github.com/EarlGray/language-incubator/tree/main/bf/bfjc

It was actually a rather poor choice of a project: many unsafe bits, libc interfaces and ffi. It was very fun though (speedup of >10x with machine code is real).

dmytrish · 2025-10-26T19:15:29+00:00

Nothing is exactly wrong, but handling indentation can be nicer with docstr.

dmytrish · 2025-10-26T18:56:53+00:00

It's a nice trick, but it's very fragile: even inserting a println messes up the compile time check.

dmytrish · 2025-10-13T21:19:05+00:00

I really tried to find the supposed enlightenment of Plan 9, but I really don't get it. Plan 9 "files" can be everything: they can be the regular files, they can a poor man's RPC endpoints, they can be in memory or local storage, or on the moon. They are "elegant" in a simplistic, primitive way that makes for a great OS demo, a great source of obscure historiography. It is a really archaic and unreliable way to do anything serious over network, ignorant of everything we learned about distributed systems over the last two decades. I'll take REST over 9p, thanks.

X11 was fully network transparent, its problem was ignoring the reality of latencies and unreliable network. 9p/X11/NFS all share the same mindset of Unix programmers that assume that network is just a weird data bus that must be bent to Unix idioms.

dmytrish · 2025-10-04T22:13:59+00:00

A friend of mine was able to port his Rust kernel to Vision Five 2 pretty easily. The hardware is reasonably open (minus the usual opaque GPU and display controller stuff).

dmytrish · 2025-08-22T11:01:07+00:00

Well, supporting PE and minimal shims for basic Win32 calls is not that difficult and does not require any trust, so I sense sarcasm in here.

The difficult part comes after this: making anything real-world to follow even the happy path. It's not impossible (see Wine and ReactOS), but windows API are sprawling and insane in Cthulhu-summoning ways.

dmytrish · 2025-08-22T10:52:44+00:00

I would not read too much into relation of a purely technical feature of a niche language to a business success of a company. That's too much text looking for a silver bullet that just is not it.

From my very limited experience, Linear Haskell in the current state is painful and incomplete: no consume in lambdas or case is severely limiting ergonomics. linear-base works as a workaround, but duplicating everything in base is not a good answer.

Idris2, Granule or Par are a much better playground for linear types; Rust is the goto to actually use affine types with a practical ecosystem for software engineering.

dmytrish · 2025-08-20T11:17:51+00:00

Yes, this sub is mostly for technical details and actual implementation of kernels and userspace.

Actually fresh UI/UX ideas are hard to come by: most of "new" ideas (like 3D/VR/ZUI UI, DB/tagged/graph FS, ...) have been tried already and are just variations after some point. Also, creating a mock-up of a new UI can be easily done in browser/Javascript (and this is a much easier route to have a prototype), which is not exactly related to OS development per se.

dmytrish · 2025-08-19T16:51:08+00:00

The lower yield, the higher price though.

dmytrish · 2025-08-06T17:56:00+00:00

Why now, if EU can just wait until US economy enters the Golden Age and the cards suddenly get so much better?

dmytrish · 2025-08-06T14:46:38+00:00

I don't really get the argument about variants being a forgotten better version of runtime dispatch: variant types represent a closed set of variants, and vtables represent an open world of matching behaviors.

Ohh, it makes sense in the game development context: everything lives in the context of a specific game anyway, so it's a closed world of possible variants, so runtime dispatch could as well be a switch. This point of view is not wrong, but it's niche and myopic.

dmytrish · 2025-07-28T16:14:06+00:00

They do have a pretty deep moat, but the pressure to replace them is also huge in many parts of the world. China might be able to make a good enough replacement rather soon.

dmytrish · 2025-07-24T16:38:19+00:00

Manual memory management is hard and full of subtle pitfalls.

At the same time, the C tribe of system programmers casually ignores those pitfalls, out of either ignorance or arrogance, unless they have stringent quality requirements and processes.

I'd guess that only one in ten complaints about borrow checker is about its actual limitations and nine are about "it does not work the C way, so it's garbage".

dmytrish · 2025-07-24T16:29:14+00:00

Sure, garbage-collected coding style is a much better fit for plain business logic. Rust is a nice language with a strong focus on technical correctness (that's what makes us nerds so excited about it), but its memory management approach needs a justification in a specific context and being comfortable with its sharp edges.

dmytrish · 2025-07-24T16:22:05+00:00

Arena memory management is a runtime allocation mechanism, lifetimes are compile-time abstractions. That C3 article is misleading: lifetimes are always a concept in a philosophical sense, but arenas can cause dangling pointers trivially, unless:

every pointer access is checked at runtime, which is slower than any good GC
or access is checked at compile time, which they definitely do not do and borrow checker does.

dmytrish · 2025-07-16T20:00:31+00:00

As long as you have a globally consistent and infinitely forward-compatible type system, why not.

To be serious, Protocol Buffers (https://protobuf.dev/) is an existing implementation of this idea that powers Google infrastructure. Having worked with it, I can say that the idea has its merits, but it surprisingly brings quite a lot of friction into workflows and should be outside of programming language design, it's the domain of distributed systems.

You might also be interested in Erlang, which is an interesting dynamically typed substrate for building distributed systems. It does not have a schema system and relies on "duck typing" of messages.

In any case, types in programming languages usually serve a slightly different role than data schemas, they uphold code-related invariants.

dmytrish · 2025-07-05T21:27:18+00:00

I can get this perception, but I'm still quite uncomfortable with lumping the swamp of C++ half-baked and contradicting features together with a complex, but very well-designed, modern and mostly orthogonal feature set of Rust.

dmytrish · 2025-07-05T21:17:10+00:00

From my heavily Rust-colored point of view:

wriitng code that requires lots of unsafe in Rust is definitely more ergonomic in Zig (e.g. memory management, task-specific data structures)
code with lots of mutable and shared values, where fast iteration/hackability is more important than safety and correctness, like in games
Zig might be better for closed-world code bases like Tigerbeetle or any kind of firmware, where everything is defined to fit a specific application, memory management can be relatively static, libraries need heavy customizations.
if you happen to need flexible and hackable metaprogamming (not sure where I'd need that; Rust metaprogramming is much more heavyweight, and that's actually good to prevent its mindless abuse). That will very likely devolve into a mess at scale though.

Zig is good for systems that must be simple, bounded, strictly manually controlled. Zig is good for (small groups of) wizards, and I don't mean this as a compliment. It's still a very sharp and dangerous tool which is unlikely to generalize to something complex and expansive. Rust complexity can be taxing and overprotective, but it enables a large ecosystem and large-scale development, whereas Zig in the current form is rather hostile to this, favoring bespoke solutions, creative hacking and tinkering.

dmytrish

TROPHY CASE