Machines are cheap. Developers are not. I would rather optimise for the latter.
Edit: since when having ADTs are so taxing for the machines? I did a quick search and I found no source saying they are expensive to implement.
Edit: since when having ADTs are so taxing for the machines? I did a quick search and I found no source saying they are expensive to implement.
Developer time is often more expensive, but it's always a one-off cost. Machine costs are ongoing. Machines can also impose hard limits on scalability.
In the real world, software optimisation is often necessary. Ever play a computer game? Those have pretty hard limits on much time they can spend processing. You can't just throw hardware at the problem to make it go away when you don't control the client.
"Just add more hardware" is also an ecologically unsound and unsustainable approach. Ever wondered about the carbon footprint of the average data centre?
Maybe one day we'll have optimising compilers so good that thinking about machine-level data structures won't be necessary. They've come a long way in the last 20 years, but aren't quite there yet. In the meantime, if you ever find yourself actually needing to make something run within some hard limits on CPU time, RAM, etc., listen to people like Rob Pike: he know's what he's talking about, even if you don't like what he's saying.
In the meantime if you're working on an MVP, by all means optimise for developer time. In that context it's almost always the right decision.
I hope I don't prove to be too detrimental to your health.
"Developer time is often more expensive, but it's always a one-off cost. Machine costs are ongoing. Machines can also impose hard limits on scalability."
A one off cost? I have never seen a codebase which gained consciousness, became self operating, fixed the bugs in itself and implemented new features, I hope I will, that's gonna be a truly glorious moment for humanity.
"Ever play a computer game?"
I did, but Go is rarely used for creating games. Typical use case: backend server services.
"In the meantime if you're working on an MVP, by all means optimise for developer time. In that context it's almost always the right decision."
Yes! On this site most people are working on some startup which will fail in 2 years. Performance is barely an issue.
No, but I've seen lots of projects who were completed, shrink wrapped, and shipped, with the team disbanded or moving on to other projects (sometimes with a few people left behind for bug fixing).
Especially most large scale enterprise /government / organisational projects are mostly one off, fire and forget affairs. A large team is assembled to create them, and then the support is offloaded to smaller team for fixes (and some tacked-on new features), and they run for decades on end.
>I did, but Go is rarely used for creating games. Typical use case: backend server services.
Which is bedide the point. The discussion was about those "programming principles" Rob Pike put forward, and the costs of developer vs machine etc -- not about Go in the least.
Machine time eventually translates to user time. Slow code leads to poor user experience and if your product is successful, wasting the time of millions of people.
Bear in mind that opportunity cost is an unrecoverable loss. Game programming where you press a DVD is an exception, but in the majority of areas the greater cost is actually in maintenance.
There are many problems that require some efficiency to solve effectively, especially in pike's field of systems.
PS: Coding go is my day job.
Go was designed as a system's language, I think it just eventually went in a different direction when people realized it would never match C++ or even Java in performance.
BTW, if you want to gain an understanding of this stuff, the difference it can make and why, I'd recommend reading basically anything by Michael Abrash.
No compiler optimization is going to get you a 100 to 1 improvement with a conventional language, but choosing the right data structure and algorithm for a task certainly can.
Now scale this to a situation where solving the problem requires ten thousand machines for each developer working on code, and where each minute of time spent writing code translates into two days of machine time running that code, and the numbers start to look different.
Meanwhile I just want to deliver the features for my product owner as quickly as possible! So we can both go home to our families in time and still deliver tons of business value.