Hacker News Reader

The reason is that the money people don't want to pay for it. We absolutely have the coding talent to make efficient, maintainable code, what we don't have are the available payroll hours.

10x every project timeline and it's fixed, simple as.

Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long, that's like turning a quarter horse into a plough horse, it's not likely to happen quickly, if at all. You'd really need to start over with the kids who are in highschool now writing calculator apps in python by making them re-write them in C and grade them on how few lines they use.

ie, it's a pipe dream, and will continue to be until we run out of hardware capability, which has been "soon" for the last 30 years, so don't hold your breath.

> 10x every project timeline and it's fixed, simple as.

I'm skeptical. I've seen too many developers write poorly performing code purely out of indifference. If you gave them more time they'd have a lot more Reddit karma but I'd still be finding N+1 problems in every other code review.

Indifference... or lack of knowledge. I've conducted hundreds of interviews and it's interesting how many people know their O notation and how they can write code that theoretically is "efficient"... but performance is in the details and in knowing the stack top-to-bottom, and most people just don't know that. And the real problem is that they don't know what they don't know.

You'd say that code reviews is where this stuff should be caught, but unfortunately, code reviews are performative in most cases or the reviewers also don't know / care about these details either.

Most people don’t catch it in code reviews, and I don’t catch everything, but I catch a lot. I see knowledge transfer as the primary purpose of code reviews though.

The real reason is the industry. We don’t reward deep knowledge of a particular language anymore. Things change too quickly.

Imagine a really good Angular dev who’s been using it for 7+ years. Sure, their code might be fast, but everything’s moving to React now.

Even backend languages change quite a bit. .NET Core is a big winner in performance compared to .NET Framework, but you can still write lousy-performing code in it.

From an architecture perspective, people seem to have a hard-on for serverless lately. Which typically involves considerably more HTTP requests, which causes performance issues. On a simple test system things are fast enough, but once you scale the latency starts to add up.

Sorry to say, but it’s no different now than before in terms of skills and keeping up with “deep knowledge” to be successful in the way described above. Sure, things move quicker now… but pace of change was never the challenge for good vs. bad engineers. The good ones easily keep up now, and the bad ones still existed when pace of change was slower. In my experience it’s more about people’s willingness to invest in deep understanding. Bad engineers generally just don’t care to learn their stack deeply.

Or they'll write an engine so they don't ever have to write any boring code again.

When you have more time and budget for a project you can teach junior developers to optimize code better.

Is it really indifference or are employees responding to incentives? Few places reward code performance. Companies are getting exactly what they pay for and missing a deadline to improve efficiency is irrational under current comp strategies.

“Premature optimization…” we’re taught early on not to waste time on investigating performance.

> 10x every project timeline and it's fixed, simple as.

> Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long [...]

No, the big downside is that you have to tell your client it'll be 10x times as expensive because you want better performance.

Oh sure, I can justify this easy.

Labour productivity vs wages doubled since the 1970s and the trend seems to be continuing. It was about 150% in 2000 so we can use Excel as as the benchmark.

This means that an accountant today can wait for Excel to load for 2 whole hours of their 8 hour shift, and still be as productive as an accountant from 20 years ago!

Isn't that amazing! Technology is so cool, and our metrics for defining economic success are incredible.

Yeah, agreed ... but[1], in purely financial terms, we are leaving money on the table, right?

Just because an accountant can burn two hours a day waiting for the computer, doesn't mean that we should burn those two hours.

I think that most of the tech stack is there technology-wise, just not aesthetic wise.

If you are happy with how UI widgets looked an behaved on Windows 7, you can have sub-millisecond startup times now for many apps. Trouble is, people would rather wait and look at pretty things than have an uninterrupted workflow.

[1] You knew there was gonna be a "but", right? Why else would I respond?

I mean, we don't have to work 8 hours a day, we can work 10 right? 12? 18? We don't need to work 5 days a week we can work 6, maybe 6.5? It's pretty common in Japan to work 6 days a week. People like pocketing productivity bonuses and they become baked into labor expectations. It's how living standards rise.

> Just because an accountant can burn two hours a day waiting for the computer, doesn't mean that we should burn those two hours.

I think the problem is there is no economic incentive to hire people that would make excel take less than two hours. If good enough gets you the sale, then why spend money getting anything more.

And here we have a clear example for the downsides of a monopoly.

People give push back when I tell them they should drop PHP for Go or Python for Rust.

It doesn't matter that it would be better for everyone and the planet. It's a prisoners dilemma. I only get rewarded and promoted for shipping stuff and meeting deadlines even if the products are slow.

Thank God for open source. Programmers produce amazing libraries, frameworks, languages and systems when business demands and salary is out of the picture.

Meanwhile some people have been using C# and Java for decades which perform better than Go on many benchmarks and their software is still slow as shit.

Java and C# tend to be used for big, hairy, old projects. Thats far less common with Go.

I was a little skeptical of this claim, so I looked it up. C# winning happens in a handful of cases, but it's extremely rare. Go practically always wins on memory usage, even if it doesn't win the cpu benchmark.

See: https://programming-language-benchmarks.vercel.app/go-vs-csh...

I tried finding more, but most benchmarks I could find were of poor quality.

I spent years designing and implementing a new data management system where speed was its main advantage. I painstakingly wrote performant code that relied on efficient algorithms that could manage large amounts of data (structured or unstructured). I tried to take advantage of all the hardware capabilities (caching, multiple threads, etc.).

I mistakenly thought that people might flock to it once I was able to demonstrate that it was significantly faster than other systems. I couldn't have been more wrong. Even database queries that were several times faster than other systems got a big yawn by people who saw it demonstrated. No one seemed interested in why it was so fast.

But people will jump on the latest 'fashionable' application, platform, or framework often no matter how slow and inefficient it is.

I'm sorry I didn't get to see it.

Anyone can download it and try it out. https://www.Didgets.com

The wonderful thing is that the hardware performance is there if you just dare to toss the stack. One of my long-standing projects is to build a bare metal (at least as far as userspace is considered) programming language called Virgil. It can generate really tiny binaries and doesn't rely on hardly any other software (not even C!). As LLVM and V8 and even Go get piggier and piggier, it feels more magical every day.

Is LLVM piggy?

It may be big, but at the end of the day it will produce some fast binaries if fed the right thing.

Build it from source and estimate the number of CPU instructions that required.

Name software that does nearly as good of a job for significantly faster. I think there is a huge difference between software is slow but best and class and a calculator that takes 5s to open.

But build it with what?

LLVM?

Isn't LLVM being a piggy good? As in only pay a hefty computational time price once upfront to stuff as many optimizations as you can in your binary, and make it fast forever after.

It takes 21 minutes to build on a 32 core machine because it's so enormous. It's a that thing translates text into binary. I love compilers; I could go into a long, drawn-out technical explanation of what it does, but really, it's a monster of insane complexity than no one can grok anymore.

If it’s a monster of insane complexity… what’s GCC?

ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

from your page

    The most significant feature of Virgil that is not in other mainstream languages is the concept of initialization time. To avoid the need for a large runtime system that dynamically manages heap memory and performs garbage collection, Virgil does not allow applications to allocate memory from the heap at runtime. Instead, the Virgil compiler allows the application to run initialization routines at compilation time, while the program is being compiled. These initialization routines allow the program to pre-allocate and initialize all data structures that it will need at runtime

Is that basically Swift's ARC?

You pulled that from the UCLA site, which is the microcontroller version from 15 years ago. That version actually burned the entire heap into the binary and did not allow dynamic allocation. In that case, no GC, write barriers, allocation, etc was necessary.

Today's Virgil (on GitHub) does allow dynamic allocation, but you can still initialize an arbitrarily large heap at compile time. It's not really related to ARC.

Oh ok thanks, sorry I just google the name trying to answer my GC related question. Maybe I missed it when skimming the github page, couldn't see a mention of memory management.

I keep threatening to write a GUI IM app that has 90% of what people use slack for, and make every action (other than waiting on the network) instant.

Too many people are arguing that things like Slack and Linen are performing as well as could be expected due to the functionality they are providing.

It existed, a startup that went under, was fully macOS native. I think this was it, "quill".

https://9to5mac.com/2021/02/23/quill-chat-team-messaging-iph...

> It existed, a startup that went under, was fully macOS native. I think this was it, "quill".

I remember that. I wonder why it didn't take off ...

I wasn't intending to make an economically successful chat application. I just want something to point at whenever someone goes "Of course it has to be electron-like; how else are you going to make it cross-platform?"

I want to demonstrate that, yes, you can have fast cross-platform applications without much more effort than going with electron-type designs.

I want to show the source code for it, I want to have a reasonably easy to follow explanation of that source code, and I want it to be reasonably low-effort.

I'm with you on that one. I actually have a prototype full SwiftUI and Swift server as well (Vapor). Hit me up if you make progress!

I won't be doing it anytime soon (working on an MVP at the moment, in between gigs).

But, if you send me your email (lelanthran at gmail dort com), I'll put it into my notes so that when I have something to demonstrate you'll be the first to see it :-)

I'm sure you could do this in a browser if there was actually desire. A browser may be many levels of abstraction up from a native app but it is still fairly easy to make apps that respond instantly (except maybe startup time). It's amazing how much extra current apps are doing to slow it down.

Remember that you have to add JS integrations, emoji and gif support. It's useless without it.

> Most youngish users have never even experienced true performance

Most of them have never experienced the level of instability and insecurity of past computing either. Those improvements aren’t free. In the past, particularly with Windows (since this is what the videos recorded) it would be normal for my computer to freeze or crash every other hour. It happens much less today

The video is about Windows NT which did not crash or freeze every other hour.

It still did compared to Windows 10.

Not in my experience.

I have absolutely no idea what you are talking about "true performance" - maybe you are from an alternate reality? I don't think of the 2000s as "true performance" but rather crashes and bugs and incredibly slow loading times for tiny amounts of data.

I can grep through a gigabyte text file in seconds. I couldn't even do that at all back in 2000.

Nah, the smartest people in the world are working on ads. And ways to track you to serve more ads.