I tried AI, and i never could/dared to actually push anything to prod. The code seems ok, but i always have a gut feeling somethings off.
I guess the most valuable thing you loose is the "what" and "how". You cant learn these things from just reading code, because the mental model just is not there.
Also i dislike code reviews, it feels "like a waste of time" because sure i can spot some things, but i never can give the real feedback, because the mental model is not there (i did not write this code).
Having said that, I still use AI for my own code review, AI can spot some one-offs, typos, or even a few edge cases i missed.
But i still write my own code, i want to own it, i want to have an intimate knowledge of it and really understand the whys and whats.
I do, but in this case some one else did the writing, not AI. I can always drop them a PM about how/why something is like it is. I cant do this with AI, and when trying you cant trust the real reason, and the answer will pretty much change depending on how you ask it.
Yeah, and it's awful working with someone you know is going to mess thing up, in major ways, has no self-reflection, and cannot be held accountable for anything, because they're management's best buddy.
It's actually really great for anything where you want to be more safe/correct, like banking... and the `TASK` construct makes it really nice for naturally multitasking situations. A couple of the people in the community are putting together gamedev tools/engine.
It was just a really good timing. The web 1.0 was just getting popular. And now 30 years later, we still suffer from this "timing". Luckily there is so many better alternatives in 2026.
Firefox incorporated parts of the Servo effort which were able to reach maturity. Stylo (Firefox's current CSS engine) and Webrender (the rendering engine) and a few other small components came from the Servo project.
Most other parts of Servo were not mature enough to integrate at the time Mozilla decided to end support for the project and didn't look like they would be mature enough any time soon. The DOM engine for example was in the early stages of being completely rewritten at the time because the original version had an architecture that made supporting the entire breadth of web standards challenging.
Keep in mind that you can continue adding Rust to Firefox without replacing whole components. It's not like Mozilla abandoned the idea of using more Rust in Firefox just because they stopped trying to rewrite whole components from the ground up.
Mozilla can't help it but be their own worst enemy. Ladybird may well never have happened if Mozilla just had kept working on Servo, and Ladybird is most definitely going to out compete Firefox when it reaches maturity, as Mozilla keeps on burning bridges with open source enthusiasts.
The problem with Mozilla is not just technical but cultural. The organization has been infected with managers. The managers want to keep their jobs more than they want Firefox to succeed. Clearly the solution is for the managers to fire themselves and allow the developers to run the show, but that was not going to happen.
Ladybird, by contrast, is a developer-lead open source project that has no such constraints. They also don't have a product yet but I'm sure the picture will be radically different in a few years.
> The problem with Mozilla is not just technical but cultural.
Not once in my career have I come across a problem that wasn't cultural. There are no purely technical problems in software. Everything can be achieved, everything can be worked around. All one need is a consensus. Enters cultural problems.
> The managers want to keep their jobs more than they want Firefox to succeed.
Coincidentally, also throughout my career, not once have I met an engineer that didn't put the entire blame on managers. Introspection really isn't our forte, is it? :)
To add to the other replies, Firefox was explicitly never going to consume all of Servo. It was always meant to be a test bed project where sub-projects could be migrated to Firefox. I suspect that the long term intent might have been for Servo to get to a point where it could become Firefox, but that wasn't the stated plan.
Complexity does not equal language features. Sometimes simple is good, but sometimes simple just simply means more bugs in your code.
As a prime example, Go unwillingness to add even the most simple enum kind of type. Having enums (ADTs) with exhaustive pattern matching is NOT complex in any sense or form. It just takes away so, so many bugs you would normally see in production code.
One other low hanging fruit is the fact that zero values are in 90% of all cases not what the dev intended. Sure, the mantra goes "make them useful" but thats hard. How to you know if a value (int) was zero initialised, or if the user did in fact input zero as value. No matter, you will need to validate every one of these "zero values" if you want some sort of robustness.
Adding `null` to C was very simple to add. It added a lot of complexity that the language designer did not see coming (hence the billion dollar mistake he made on that).
`NULL` was originally added to ALGOL back in 1965. C was not even a thing back then. It was obviously a bad choice to port NULL to C, one that ADTs would have perfectly modeled, without the billion dollar cost.
In fact C was built sometime around the early 70s, and at the same time the first MLs where also being developed. One added null, while the other added a better mechanism for "nothingness".
Bottom line is you cant compare "adding null" and adding a feature that is over 50 years old, one that is battle-tested thru generations, and still holds up.
> Go unwillingness to add even the most simple enum kind of type.
Go has enums, under the iota keyword. But I imagine you are really thinking of sum types. Technically Go has those too, but must always have a nil case, which violates what one really wants out of sum types in practice.
Trouble is that nobody has figured out how to implement sum types without a nil/zero case. That is why you haven't seen a more well-rounded construct for the feature yet. This is not an unwillingness from the Go team, it is more of a lack of expertise. Granted, it is an unwillingness from those like yourself who do have the expertise. What stops you from contributing?
> It just takes away so, so many bugs you would normally see in production code.
What bugs do you imagine are making it to production? Each pattern matched case has a behaviour that needs to be tested anyway, so if you missed a case your tests are going to blow up. The construct is useful enough that you don't need to oversell it on imagined hypotheticals.
For example if a have a type with 3 constuctors, and later one new dev adds one more case and forgets to handle it in every call site. No test will catch this 100%, but something like ocaml will just by compiling the program.
I know fo is not (i dont want it to be) like ocaml, bit any modern language should have some of the basic safety features baked in.
> later one new dev adds one more case and forgets to handle it in every call site
Okay, so you are dreaming of a situation where you allow a new developer who doesn't know anything about how to engineer software unfettered access to your codebase and he goes in and starts mucking about to where he ends up doing things that no sensible human would ever consider acceptable?
I accept you like to live dangerously and have no real care for the product you are building. But, still, you've only covered a limited subset of all the similar things this new developer who doesn't know the first thing about building software can make a mess of. Ocaml just isn't going to cut it.
To reach the full gamut you need, say, a proper dependent type system. But are you really going to throw all your Ocaml code away and start writing Rocq just to deal with this guy you should have never let touch your code in the first place? Probably not. So, what now? Your only practical option is to fire him and find someone who actually understands how to write software. And at that point your tests will catch such forgetfulness just fine.
> No test will catch this 100%
Testing cannot exhaust all cases where the search space is infinite as that requires infinite time to evaluate. In this case, you have exactly 4 states. That is evaluated on the order of nanoseconds. If your tests are not capturing every one of those four permutations, it seems clear that you need to stop letting any random Joe who has never done more than some quick vibe coding anywhere near your code. These are solved problems.
And, hell, even if you did switch to a language with a proper type system, like Rocq, so you could mathematically guarantee all aspects of your program, the shitty programmer will still fail to write theorems that are free of holes. So don't think that even lets you of the hook in hiring those who live by the vibes. There is simply no escaping the need for solid engineering.
When you have that, exhaustiveness checking still remains a useful tool, but you aren't going to forget something and ship broken code to production if you don't have it. This isn't a realistic scenario outside of the contrived. Again, The construct is useful enough that you don't need to oversell it on imagined hypotheticals.
> Okay, so you are dreaming of a situation where you allow a new developer who doesn't know anything about how to engineer software unfettered access to your codebase and he goes in and starts mucking about to where he ends up doing things that no sensible human would ever consider acceptable?
Tell me without telling me you have never worked on a large scale business app.
I did long enough to know that in large teams you won't find many accepting of usable type systems. For the same reason the blub developer cannot write good tests, if they can figure out how to write tests at all, they equally fail with types. Which makes sense — testing and types try to solve the exact same problem. The mindset required to grasp and be productive with both is identical. So your imagined hypothetical doesn't even work there. These large scale apps of which you are speak are simply built around constant failure in production. If it is good enough for GitHub...
The only place where the your contrived idea is in any way plausible is where you have a solo developer who thinks he is able to write code without making mistakes or needing to document anything, using a half-assed type system not failing as some kind of proof to himself of that. But in reading this he, unless the hubris is completely off the charts, will be reevaluating that stance.
> you won't find many accepting of usable type systems
I think its not about the "typesystem" but the fear of using something the dev is unfamiliar with. I know people who has written the same code, in the same language for 20+ years. "It worked then, and it will work now" is tattooed on their forehead. Its basic human behaviour, you see this in politics, business and life in general.
> testing and types try to solve the exact same problem
Sure, they overlap.
Tests are just a poor mans types,
Types are just a poor mans tests
But in my mind tests cover the how, and types the what. With both you need less of both. Its a win-win.
> These large scale apps of which you are speak are simply built around constant failure in production.
This is true. But im going to my grave trying to change that. Its an uphill battle.
I guess the most valuable thing you loose is the "what" and "how". You cant learn these things from just reading code, because the mental model just is not there.
Also i dislike code reviews, it feels "like a waste of time" because sure i can spot some things, but i never can give the real feedback, because the mental model is not there (i did not write this code).
Having said that, I still use AI for my own code review, AI can spot some one-offs, typos, or even a few edge cases i missed.
But i still write my own code, i want to own it, i want to have an intimate knowledge of it and really understand the whys and whats.
reply