[wpietri]

> The entire codebase has been migrated from C to C++. In the process, we've removed thousands of lines of custom code and used standard C++ tools instead. The core's code has shrunk by 18%. The core codebase has been extensively refactored to be more testable and maintainable.

I love negative-LOC commits! They warm my heart. As do the people who take the time to make them.

[tincholio]

At my previous job, we re-did some Java stream processing stuff in Clojure. We added functionality, made it more stable and dropped 6K lines of code (out of 18K for that particular component) in the process. It felt like magic...

[capableweb]

That's not a fair comparison, rewriting anything in any lisp will dramatically reduce the amount of cruft, both lines of code and complexity.

[argiopetech]

It is still a LOC reduction produced via rewrite. I don't think we should hold it against them that they choose a great target language for the rewrite...

[kaba0]

Doubt. Plus, essential complexity is non-reducible.

[capableweb]

Essential complexity I agree, you cannot get rid of (hence the whole "essential" part). However, when you program, lots of non-essential complexity sneaks in. If you've only ever written code in one language, I bet you wouldn't even be able to notice what is essential vs non-essential.

[srcreigh]

A lot of those dropped lines of code is gonna be lines which only contain }.

[gottacodethem]

replaced by lines of )))))

[KronisLV]

> I love negative-LOC commits! They warm my heart. As do the people who take the time to make them.

Agreed, but only if there's adequate test coverage and it's pretty clear how everything should work.

Otherwise it's a very stressful experience, working with a seemingly brittle and puzzling codebase.

[makapuf]

One funny consequence is: refactor code only well covered by tests, decrease nb of lines of code => test coverage decreases. This is normal and test coverage is not itself a target, but that's funny.

[marginalia_nu]

Brittleness isn't really a property of having tests IMO, more about designing it to reduce unexpected dependencies and interaction-at-a-distance between components. (Part of it is also understanding how the system works. If you are new to a code base, virtually all dependencies are unexpected)

Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there.

[KronisLV]

> Tests can help reveal when those types of dependencies break, but even so, I would argue that is brittle code held together with cling wrap. The fundamental problem is still there.

Sure, however tests failing after refactoring or removing seemingly unused bits of code will be a great way to figure out when one's assumptions about how everything works are mistaken, or to discover bits of code that one wasn't even aware of.

Along the lines of: "Oh hey, our tests caught that removing this seemingly unused dependency from pom.xml will break PDF export logic, because for some reason it loads classes dynamically and needs that package" or maybe "The tests revealed that our latest refactoring breaks JSON serialization of dates, because while we should be able to use these annotations for our Dtos properly, the underlying framework gets confused because of our serialization library."

The worst cases are where you don't have the tests and things break in ways that might not be immediately obvious. Such codebases will make any attempts at refactoring unsafe and inherently stressful, that's what I meant with brittle - you'll never be able to change anything whilst having confidence that things won't break all over the place.

[marginalia_nu]

To be clear, I'm not saying you shouldn't have tests, but if you change your pom.xml and the code starts blowing up at runtime, your code is still brittle.

Code that isn't brittle wouldn't behave like that.

Tests allows you to catch it early, but with the platonic form of non-brittle code, you wouldn't need to run any other tests than the test that tests the module you just changed.

[KronisLV]

That's a fair point! I guess it's a matter of what's under the hood vs how it appears on the outside. Code that is brittle in obvious ways is still better than code that is brittle in subtle ways and will break later. Code that doesn't have those issues in the first place is the best, of course.

[1vuio0pswjnm7]

Program size has not shrunk though.

3.9M static binary for 2.84

9.0M static binary for 4.0.0

[wpietri]

My god, that's $0.00014 worth of disk space! Or $0.00063 on SSD! Do they think we're made of money?

[1vuio0pswjnm7]

NB. I compiled these myself on Linux with musl and gcc.

[mrtesthah]

It's a universal binary.

[ksec]

Assuming they share Graphics assets on Mac, it is still larger though.