Some programmers will write more efficient code. At my $dayjob (one of the big tech companies) we're already planning a major goal next year of optimizing server code to reduce RAM requirements, and this is directly in response to the crunch.
In practice I expect most optimizations will come from "stop doing stupid stuff" and not "use fancy advanced algorithms." But that's a cynical perspective so don't be cynical like me.
Real, there are so many low hanging fruits for optimization but no one has time to do them. And they don’t incentivize spending your time on it either.
If the CEOs are to be believed, then 75% of all new code in Google is AI generated. 46% of GitHub internal code, and roughly 30% across all of Microsoft is AI. Meta expects at least 65%, and snap reported 65% is AI generated.
in aws, some of the core bedrock services have been replaced with the new serving architecture. that thing was written basically with LLMs.
mind you, guy's a distinguished engineer, his team was basically all principals, but you can do it and some of the new teams are copying the style (though with less success, due to lack of technical skill).
The key word here is “server”. Optimizing memory server-side directly translates to cost savings for companies. There is a lot less incentive to optimize memory for code that runs on the user’s computer.
> Optimizing memory server-side directly translates to cost savings for companies.
Only if those cost savings exceed the cost of development. Optimisation work is usually done by the most experienced, and hence most expensive engineers. It is also possible that the optimisation efforts will fail to produce meaningful results. In my career, I have seen more optimisation efforts fail than succeed.
That's a clever observation and is very true. Development time tho historically was also very expensive hence push for easy to work with dev stacks such as js
Totally agree. In these days of fast devs it's common to see PO's excitement reducing deadlines and assumimg a dev can deliver 5 feats in a day instead of trying to stabilize and fix bugs. Sad
> There's nothing more permanent than a temporary fix.
That should be one of those Tech culture “laws.”
I suspect that the dependapocalyse is a significant factor. When every part of an operation has multiple context rebuilds, and resources are not shared across module boundaries, you get inefficient behavior.
But I’m skeptical that there’s a will to rethink that.
Honestly, after years of seeing this play out, a lot of devs really lack the judgement to know when something is good enough to deliver and will endlessly delay projects to “ do the right thing”
Absolutely. It’s one of the defining characteristics of what makes someone a capable senior in the role IMO.
I have known a lot of extremely talented developers, some with more technical skill than me, that simply failed at their job because they couldn’t come to terms with the fact that their job isn’t to produce the most perfect code possible for the problem.
In my experience, I have only developed internal enterprise software for my entire career. Most of this stuff is gloried CRUD. Above all: Ship early and ship often. You don't get paid more for having less bugs. (Of course, don't ship crap, but you don't need perfection.) Also, often the specs (in my line of business) are unwritten, so you learn more by releasing quickly, then watching (internal) customers use the product and provide feedback.
LNT is the null hypothesis. No one disagrees a linear model fits the data very well in high doses. If you want to argue that model doesn't work in low doses, you need a model with more parameters and sufficient data to fit it. The issue is that, at these low doses we want to differentiate, we're also looking at effect sizes that are hard to separate from noise, and sampling biases that are hard to erase. There's still lively and ongoing debate.
No, you also need to calculate the voltage drop over your distance to show to minimum wire sizing, and the voltage and power levels at the ASHRAE minimum temperature, the current level at 156.25% over the wiring at the ASHRAE max temperature to compute the temperature adjusted resistance and show that your wiring meets minimum spec, etc.
It’s not too hard to actually do the computations. But there is a ton to learn. I installed my own 14.85 kW system last year, with batteries, and I spent hundreds of hours just researching everything. I know I went overkill, but the hardest part of the project was just getting up to speed on all the requirements to meet code.
Someday I’ll write up my entire experience and share my site plan I used for permitting in the hopes it will help someone else. But doing solar right is a nontrivial investment for a newbie (like me).
The most difficult part is acquiring the necessary domain specific knowledge, including what your AHJ changed from the national codes. But yes, once you know everything it’s all pretty straightforward stuff.
When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?
Most of the time "make something faster than anyone else has done" is just not worth doing? Good enough is good enough. Unless it's some super hot path and it's the speed that's the main goal, nothing else. Which is rarely the case.
If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?
No, I’m saying that it’s how I like to tinker. Others have their own ways of tinkering that are just as valid!
I personally think the optimization challenge is fun. I like digging in to low level stuff, reviewing the assembly dumps and processor pipeline architectures. I fail or give up most of the time, but I enjoy learning in the process.
I’m just trying to show how Zig fits my tinkering well, since you said you can’t see how Zig would ever be a good fit for tinkering. I’m not saying it’s a good fit for all forms of tinkering.
It allows you to fill in padding in a buffer. For example, all data in a buffer will be interpreted by a downstream system, and someone pre-calculated the size of that buffer. Rather than encode everything twice (once to figure out the exact size needed, and a second time to actually populate the buffer) the buffer size was calculated using foreknowledge of how many values would be written to that buffer and then just pessimistically assuming all of them are max-size so writing will never fail. Another situation is when you're rewriting part of an already-encoded file. If you want to change a bit of payload then using padding bytes gives you more flexibility so you can do that without having to do any memcpy into a new buffer.
It's uncommon but I've definitely seen it done (with media containers like Matroska, not actually LEB128) in extremely high-throughput systems that can't spare any cycles.
SQLite doesn’t depend on donations. They have a consortium, sell licenses (it is open source but some companies like the explicit CYA), sell support contracts, sell an aviation-grade test harness, and sell extensions.
Of course there is always the risk it goes out of business like any other company, but it’s not funded like your typical small open source project and doesn’t even allow open contributions (not necessarily a bad thing IMO but it’s just a totally different type of project).
Is there a reason why more OSS projects don't follow this model? It sounds like you are saying that there are clear advantages here that other OSS projects lack.
SQLite is arguably the most widely deployed database in the world. It also has its roots in government/defense contracting so it was built with navigating that kind of red tape in mind.
Most OSS projects simply don’t have that kind of weight or discipline to follow SQLite’s footsteps.
I suspect the government contract roots are what lead to it being placed in the public domain.
It did not have to, they could(and some would argue probably should) have gone the normal copyright with public use license route. But I suspect that because US government code by default is in the public domain(the US government has means other than copyright to protect it's IP) and this code was originally written for a cancelled US government project. That was their default mindset when they wanted to release it.
Note that I am using a sort of editorial they here, I think it was largely the effort of one person.
It is probably telling that with fossil, a supporting project to sqlite, they went the more normal route and released it under copyright with a BSD type license.
I like the idea of public domain(some things belong to us collectively), but it does raise an interesting question if a private individual can place something in the public domain. Are you allowed to give up your rights?
There are business models that work for the extraordinarily popular open source projects (Linux, SQLite, etc.) that don't work for the "well-used piece of infrastructure" projects, even though that category is very important in aggregate
pgbackrest also was part of an organization from what I understood from the post. The organization got acquired. I don't see how sqlite is shielded (or any project really). They could get acquired. They could not have enough customers. They could go the wrong directions and lose customers. They might have a few high profile bugs so that customers lose faith in them.
PGBackRest was sponsored by some specific organizations, but not owned by them, and PGBackRest was not their product.
SQLite is in a whole different league when it comes to funding, corporate support, etc. There are commercial contracts directly tied to its ongoing support and development. As far as I understand SQLite is Hwaci’s bread and butter.
I’ve done it multiple times without much effort. Or skill. Really it was a skill issue and I tried things that I thought would work but apparently don’t.
I screwed up jj a few times while picking it up, but jj’s undo command made that trivial to go back and try again. With git? I know a lot of things can be undone but I can never remember how to do it!
If you're already super comfortable in git, it's not. I'm saying this as someone who recently converted from git to jj and never wants to go back.
You also don't have to follow what the GP said. I never say `jj describe` before writing code. I write the code then just say `jj commit -m "Foo stuff"`, just like I would in git.
The bigger difference I've noticed is:
1. Switching between changesets just feels more natural than git ever did. If I just run `jj` it shows me my tree of commits (think of it like showing you git's branches + their commits), and if I want to edit the code in one of them I just say `jj edit xyz`, or if I want to create a new commit on top of another one and branch it off in a new direction, I just say `jj new xyz`. It took a little bit for my brain to "get" jj and how it works because I was so used to git's branches, but I'm really enjoying the mental model.
2. `jj undo`. This alone is enough to convert me. I screwed something up when trying to sync something and had a bunch of conflicts I really didn't want to resolve and I knew could have been avoided if I did things differently, but my screwup was several operations ago! So I ran `jj undo`. And ran it again. And again. And again. And then I was back to my clean state several stages ago before I screwed up, despite having made several changes and operations since then. With git? Yeah I could have gotten it fixed and gone back. But every time I've had to do something like that in git, I'm only 25% confident I'm doing it right and I'm not screwing things up further.
3. Rebasing. When I would try to sync git to an upstream GitHub repo that used rebasing for PRs, I would always get merge conflicts. This was because I stack my changes on top of each other, but only merge in one at a time. Resyncing means my PR got a new commit hash, even though none of the code changed, and now git couldn't figure out how to merge this new unknown commit with my tree, even though it was the same commit I had locally, just a different hash. With jj? I never get merge conflicts anymore from that.
Overall the developer experience is just more enjoyable for me. I can't say jj's flow is fundamentally and objectively better than git's flow with branches, but personally and subjectively, I like it better.
In practice I expect most optimizations will come from "stop doing stupid stuff" and not "use fancy advanced algorithms." But that's a cynical perspective so don't be cynical like me.
reply