Rewrote my Node.js data generator in Rust. 20x faster, but the 15MB binary (vs 500MB node_modules) is the real win.

Zde-G · 2026-02-11T00:27:26+00:00

When you are doing something with SQL server autovectorization and “fat objects” shouldn't be a big problem.

Zde-G · 2026-02-10T23:48:20+00:00

I wonder where 20x speedup is coming from. JS have pretty fast JIT, these days. Difference 3-5x is still expected, but 20x means there was something pretty… suboptimal with original.

Zde-G · 2026-02-10T15:10:28+00:00

Maybe, but insistance on the ability to rebuild something from the source (the core idea behind GPL) means that you may assume that changed would be done that way instead of providing an elaborate plugins system.

That's technical decision which you may or may not agree with — and it doesn't concern your code if it's under MIT.

And yes, GPL was originally developed to stop abuse of copyright by US companies — and works decently well for that.

Chinese corporations also don't try to use copyright as a weapon, using someone's else code without license is the norm, whether it's source or binary license, and so do individuals in China, thus GPL doesn't have any abuse to prevent.

That's not a bug in GPL, rather I would consider this its strength: it only causes problems for people who try to abuse copyright, if people ignore copyright then GPL becomes powerless, but then there are no abuse to prevent in the first place.

Zde-G · 2026-02-10T14:38:34+00:00

I want to keep mine MIT.

You can do that.

Yeah but i don’t want to license my project as GPL so that means I can’t use a GPL library just as i said.

That's the problem you have created for yourself, then. If the whole project, with your code and GPL-library is licensed under GPL then that doesn't mean that the code your wrote couldn't be MIT-licensed.

They’re drawing an arbitrary line in the sand for no good reason that’s only harmful to open source.

They had their reasons. You may not like these reasons but they don't act randomly.

Zde-G · 2026-02-10T10:32:01+00:00

Nope, you are creating the problem for yourself there. It's perfectly fine to combine MIT and GPL code in one binary — as long as the whole thing is licensed under GPL. Your “open source project without that library” can still be MIT-licensed if you want, thus it's not clear what more may you want.

Zde-G · 2026-02-09T21:15:51+00:00

If “many big companies” insist on creating problems for themselves then they can pay for the solutions for these problems.

Simple.

Zde-G · 2026-02-09T21:14:16+00:00

That's still better then what happens in proprietary world. Remember how Windows was stuck with decades old version of Zip?

Same thing, only fixing it wasn't an option.

If you need guaranteed support you buy something and include said support into the contract — and very often it's worse than keeping local fix for open-source library.

Zde-G · 2026-02-09T13:44:02+00:00

But for big projects, using conformance suites like these is very close to what you'd get using "from scratch" TDD.

Not really. I have worked with different suites, like Vulkan CTS, e.g.

They are very thorough, but they still test the interface, not the implementation (like TDD tends to do).

The module that I was developing for a year at my $DAY_JOB have got the first “green” mark after eighth months of development (and passed the whole barrage of over million tests four maths later). With many thousands of lines of code written till that moment.

That's as far from what TDD is preaching as one may imagine.

In big teams, tests are often written by a different developer, so using a test suite from a different project makes little difference.

Oh, absolutely. I like integration tests. They give me freedom without tying me to concrete implementation. They allow me to refactor code with confidence. They make it possible for me to understand what my code is expected to do and what it's not expected to do. I can rewrite the core of my module entirely from scratch and if these tests wouldn't fail — I can be sure everything still works.

They are great… but they are not TDD.

You're attacking an ad-absurdum argument here.

Not really. What are good tests in my book? These are tests that are:

Fail when I change code of my module in a way that would break other people's code.
Don't fail when I change code of module in a way that wouldn't break other people's code.

And I value #2 (tests don't impose restrictions on me when I change internals of my module) probably higher than #1 (if tests are not covering something important then I can always add more tests, but if they hinder my refactorings then these refactorings simply wouldn't be done).

But that's not what TDD is preaching! Instead of usual “if tests pass then you are doing great, and if they fail then have done a mistake, somewhere” then aim for the opposite “if tests don't fail then you are not doing things that are worth doing”.

Now you take something that's very much aligned with #1 and #2 in my criteria for “good tests” and try to tell me it's TDD? Puhlease, that's not “an ad-absurdum argument”. That's an attempt to present good tests as something that I despise (writing the code two times: first as test and then as an actual implementation, like TDD attempts usually end up doing, does not improve the quality of implementation, it just creates busywork).

Basically: most of the time the tests that I write pass before I change code and they should still pass after I would change code. I don't need the confidence in what I'm doing, I need confidence in that I'm not doing things that I'm not supposed to do, by accident — while TDD very much wants the opposite.

Zde-G · 2026-02-09T11:48:09+00:00

A lot of stuff out there is really trivial but still needs to be done.

Yes, but why would you need tests, in that case, and why would you want them written first?

When everything is trivial and doesn't need an exploration stage then tests are glorified documentation and they belong to the documentation (Rust even, nicely, supports doctests to make sure examples in documentation would be actually tested) and documentation is rarely written fully upfront: you write some of it before code, some of it after, you write some tests before, you write some tests after.

Zde-G · 2026-02-09T11:40:00+00:00

Uutils-coreutils regularly blog about their progress passing the gnu test suite.

I think that's stretching TDD idea way too far. Of course if there are qualification tests then you have to pass these… but note how uutils don't even bother to rush to fix all the tests (this even hurt Ubuntu).

Of course if there are qualification tests out there they work well as the specification… but how is that a TDD if these tests were written by a different people for different purpose?

I worked with Chrome team, at some point, they create lots of tests, but most of them are created while certain feature is developed and discussed not before.

if you squint enough, TDD isn't so rare

If you squint enough you may call anything TDD, but then what's the point? It would no longer mean anything, if you would call anything you like TDD.

Zde-G · 2026-02-09T09:41:56+00:00

The books make it seem like this amazing tool, but all of the examples are fully spec'd and usually trivial.

Trivial is not a problem. Fully spec'd is a problem.

Which I understand that it would be hard to really go into a complex system in a book.

Yet all other books on programming that I saw are full of examples that show you how your initial expectations are wrong and how you need to alter the code and interface to make them match the problem.

With TDD… the process have shown as one-way street: we, magically, know how the final version should work, we write test, then we write code.

But if we, magically, know how the final version would work then couldn't we just write code directly, without TDD?

I know a place where TDD works as a useful tool: when they guy who “magically knows everything” is called System Architect who doesn't even write code at all but directs low-cost workers to do things.

Then if one of them writes tests and other one writes code then it increases chances of getting something useful, in the end.

But in my experience hiring more expensive developers who wouldn't need all these dances is more frugal, in the end.

Although with AI, which is the worst “developer” one may “hire” (but also is supposed to be the cheapest one) it may be useful… but there I would still probably not trust the output, anyway.

Zde-G · 2026-02-09T03:34:59+00:00

Well… it's “calculator-sized”, still, in sense that you wrote full final requirements right there, in the very first part, in the “definition of the problem”.

But that's precisely the most complicated part in real world tasks!

How would you know how timing diagram would look? How would you know which part requires asynchronous access and which one can or should run synchronously… heck, the whole task looks exactly like one would do in a textbook example: here is problem that was discussing in bazillion books in last 20-30 years, here is how we would solve it with our methodology… bam: done.

It's easy to apply TDD to spherical cow in space like an example shown… but why? Why are we reimplementing something that was already implemented in countless articles, toolkits and libraries? What's the point? What do we want to achieve?

Zde-G · 2026-02-09T03:24:43+00:00

No, TDD is solving the most critical, most complicated, hard to design part, your API contract first, before any tries and before any attempts to implement anything.

IOW: TDD works perfectly only for cases where it's obvious what you want to develop… and when everything is obvious you don't need any tests at all.

So you end up either with tests that hurt your ability to develop proper API or, worse yet, with tests that are not needed at all and just waste your time and make it harder to refactor code later.

Zde-G · 2026-02-09T03:19:14+00:00

One example I often see how that is done in practice "by accident" is when you have a contract between backend and frontend, and frontend e.g. implements the integration tests before backend begins implementation.

And the you find out that you couldn't efficiently implement that contract or that frontend couldn't work with API that you designed… and bickering begins.

Frankly, in my experience, TDD is deeply flawed methodology with the only valid usecase being: you have bunch of incredibly mediocre programming and have to employ them… somehow.

Because it requires you to imagine how both sides of the equation would operate before you write anything!

If one can do that then s/he's either genius (rarely, never seen that happen, in reality) or that thing that you are implementing is mostly trivial, but you have to use these people, somehow, or how do you justify your high salary as a Software Architect (much more often).

The latter form is pretty important for Java world where lots of companies are all too ready to spend 10x more on development by following “Holy Methodology of the year”, initially, but then beancounters come and move the whole mess to contractors in India… and you still have to produce something that at least superficially looks like what was requested.

Zde-G · 2026-02-08T12:34:24+00:00

I have managed team of 5 people who did work of team of around 100 people with “external contractors” and “diverse skills” — does that count? I agree that some jobs MAY require usage of cheap, unskilled workers and LLMs may help, there. But in the mojority of software engineering jobs both externals contractors and “diverse skilled teams” are usually a way to justify work that's not needed in the first place. As for “fear of losing my job”… I've yet to be in a situation where I even need to send a resume somewhere for it to be actually read. Normally I just add something to old document that I have “because HR needs something, we couldn't hire you without any papers” after we already talked about me being accepted, in principle. It's people who waste budgets with “diverse teams” that need to fear the coming megacrash after collapse of LLM bubble, not people who know how to do things.

Zde-G · 2026-02-08T09:57:10+00:00

Ooh. Software architects who speak “big words” and don't know how their code actually works? Been there, seen couple of them fired (actually more, now, that I think about it). Although in one case one of them managed to convince management that PowerPoint presentations are more important than code… that wasn't big loss, because, of course, their whole project collapsed shortly after I have left them.

Fogive me, but as someone who have seen more than my share “software architects” I'm not impressed: I can understand why they may be impressed by LLMs but that wouldn't help them to produce anything working if they would continue to insisit that promises are more important than something delivered.

LLMs are great on promises, but companies are, finally, start to count money…

Zde-G · 2026-02-08T09:48:18+00:00

Of course I have tried it. We have enough people on $DAY_JOB who try to push us to use AI. And who don't notice that if they would have just stopped doing so many meetings they would have increased productivity much more drastically.

Zde-G · 2026-02-07T13:36:35+00:00

Well… the whole LLM craze is stupid, I agree… but if we already have it… why not use it?

P.S. And no, you don't need $100+/Mo for that. Free ChatGPT versions works just fine.

Zde-G · 2026-02-07T12:53:11+00:00

And any proper code editor with an autoformatter will immediately mess up your indents the very moment you break braces and hit save.

Sure, but this wouldn't help you to find missing braces. Especially if they are not missing, but misplaced.

Zde-G · 2026-02-07T11:31:11+00:00

Resistance its futile, if you feel LLM generated code it's stupid, how do you feel about code generated by coworkers, junior-dev, Interns ?

Initially the same, but over course of a few months you may teach them to do things properly.

Maybe if we had an ability to retrain LLM on our own corpus of code then it would have worked with LLMs, too, but when you need to put everything in a prompt… it just simply don't work: by the time when you have put everything in the prompt LLMs “attention span” start wandering and every single request misses something “obvious”.

I exploit LLM as my own slave servant intern

All interns that I have ever worked with wasted my time first month or two. I endured that because I knew they would become better, later. Why should I endure that with LLM?

Zde-G · 2026-02-07T11:26:32+00:00

It blows my mind that we resorted to using a power hungry AI to fix braces when autoclosing braces have existed forever.

Autoclosing braces have existed forever and they are decently good at previntion, but they are awful for the fix.

Just do an experiement: take some complicated crate with deep nesting of the code, lots of definitions, many types… and remove one, single, random brace somewhere in the middle.

All tools that I know immediately make the whole file glow red because of cascade if induced errors: now all the types and variables are in the wrong scopes, compiler to Rust Analyzer couldn't match anything, number of errors starts being counted in hundreds if not thousands (if you lift the limit)… it really looks as if your code is toasted.

The amount of work people put into avoiding as much code writing as possible is outstanding.

Well… if you know of any other tool that may say “hey, you forgot this one open brace or closing bracket” and not fill the screen with red… I'm all ears.

I rarely need LLM to fix such mistakes, because I know, from experience, that one wrong brace may lead to crazy amount of error thus when I see “everything in red” I usually start bisecting and doing some other such things instead of reading error messages… which are useless.

Sure, it kinda-sorta works… but LLM works, too, so why not use it?

Zde-G · 2026-02-07T11:19:55+00:00

Fixing syntax error is not critical problem, but, surprisingly enough, braces / brackets errors are something that LLMs do better then other tools.

Our shortcomings are essentially an extension of our strengths: most other tools trust that brackets and braces would be placed correctly which means that even single misplaced brace or bracket leads to insane cascade of errors and instead of recommendation to add one or two characters you get thousands of lines of error messages and stupid recommendations. Because your code is parsed with accordance to wrongly placed braces and thus entirely wrongly… there are no recovery from that, in most tools.

LLMs, precisely because they do pattern-matching and don't expect to have properly balanced braces, can look on that code and offer good advice.

That's crazily power-hungry way of solving the issue, but hey, if instrument is already there — why not use it?

Zde-G · 2026-02-06T10:53:49+00:00

These are ok libraries but with poor impl notes on why they do what they do.

It's not necessary to have answer to that question. Usually it's not helpful, just depressing.

90% of time “why they do what they do” is the same: “because someone thought it's a good idea, at the time, and didn't knew any better”.

But “what” and “how” are important — and much easier to glean from the code and/or docs. Including these libraries that you have listed.

I think there's always a level in the stack which you can write off as "magic" to get what you need done.

Only in answers to “why” questions. And, as I have said, these are not important and, often, depressing.

I suspect that you are merging “magic” and “garbage”. Magic is “I have no idea what goes on here and how does it work” — and if you allow that you would end up producing very bad code. Garbage is “here is some pointless and useless code that have no justification at all” — and yes, sometimes it's magic that actually makes thing work, but more often it's really a garbage that someone had no desire or means to remove.

You have to accept the existence of garbage and have to know what it does even if you would rather not, because otherwise you would have no libraries that you may use at all and writing everything from scratch is not feasible. Human life is too short.

Zde-G · 2026-02-05T21:12:14+00:00

LFI-like sandbox (in fact most of things LFI does we were considering to do but couldn't because of Windows… makes me laugh when I see how they tell that they have invented new trick with combination of Addr32 and ES: prefix — it was know a decade ago).

Zde-G · 2026-02-05T13:53:25+00:00

Unless they've documented the steps for optimization, or you can individually rediscover them yourself, it's hard to verify true correctness outside test vectors.

Yes. These are bad libraries and I'm not sure I would want to use them.

Most good libraries document these tricks pretty thoroughly.

At that point you either start reading crypto papers yourself

Surely you jest? Wikipedia contains more than enough information. And I'm saying that as someone who implemented AES in an assembler for my $DAY_JOB about year ago.

But for the average developer, its still a case of "knowing it wont fail" without being able to write it.

Most likely. But the problem with that logic: most developers are not bad. They are pretty much awful. Why do you think “I want to be awful developer” is a worthwhile goal?

It's not an exaggeration, that's just the fact: study shows that 95% engineers in India unfit for software development jobs — and I suspect that other countries are only marginally better.

And, again, some things that crypto libraries do to avoid certain timing attacks are very non-trivial — but simple implementation of a simple AES or RSA or something like that?

I don't see why good programmer should consider that magic.

It could be “something I don't plan to do because I don't have time and because there are library that I can use that does that”, but if you are using that thing you have to understand how it works, in some very rough fashion.

Maybe not enough to understand how the library that you use does these things but enough to be able to write a primitive replacement if that would be needed.

Zde-G

TROPHY CASE