99% of managers claim that developers cost more than hardware, so it's perfectly fine if the code is slow, they can just buy more hardware.
The argument is rather the following: common knowledge is that it’s not worth optimizing the code and that programming languages don’t matter, because the IO is too slow anyway. This fizzbuzz shows just how bad we are at IO compared to the optimum. So if we were to improve the IO, then faster processing would also make a difference. In this case you get an improvement of 179x compared to Python, i.e. your laptop will do instead of multiple clusters in the cloud.
* Where do those terabytes of json live? In the example case, the data is not read from anywhere, but rather generated and written to the pipe. All else being equal, I suspect it would be hard to feed such a program at 55GB/s w/ real data from some storage somewhere - in the end you'd be limited by the disk read speed (or network recv speed).
* This example doesn't need much ram for processing. There's only a handful of variables that can be held nicely in registers. Even if you could get 55GB/s of input, there aren't a lot of cases of json processing that won't need to store variables in memory. At a minimum a lot of effort would be required to ensure cache friendliness for these variables to not thrash the cache - if it's possible at all.
* The code for the example is tiny - json parsing requires a lot more instructions. Even in the simplest case - pulling a fixed number of bytes from fixed size records in the input stream requires a similar number of adds and compares (etc) as the example case, and the output memory alignment machinery will be about the same. As the code grows to handle actual parsing of json and processing of data, the instruction count grows quickly to a size where the instruction cache may become a concern.
* speaking of instructions - parsing json has a lot of conditionals. I don't think it's possible to do it without any conditionals, or even without enough branch mispredictions and pipeline flushes to achieve such high throughput.
Of course all of this is assuming that the IO of writing to a pipe is the same as IO in the "get from network or disk etc" sense. They really aren't the same - io to a pipe is IPC, the data never leaves the l2 cache - it's only io to the process not to the CPU. Once you have disks and networks and RAM involved, things change dramatically - the signals have to travel an order of magnitude (or more) further, they have to leave the chip so you must synchronize with a different device, there's protocol overhead for storage and network, etc.
Point being - sure we can absolutely do better with software in a lot of cases, but this is not a good example to derive conclusions from.
Maybe? But given that we don't have a way to magically make IO go much faster, that seems pretty irrelevant to the real world. The processor can go faster than memory; sure, we knew that.
> In this case you get an improvement of 179x compared to Python, i.e. your laptop will do instead of multiple clusters in the cloud.
So a highly skilled programmer devoting months to what's typically a 10-minute interview problem (i.e. about 5000x as much programmer time - and the time investment would probably scale superlinearly with the complexity of the problem) was able to get... a measly two order of magnitude improvement. That's really not a good tradeoff most of the time.
If this task was the bottleneck in a large scale system then it would definitely get hand optimized after a proper analysis.
But if this is an occasionally run task or something otherwise not business critical that doesn’t bottleneck anything, spending orders of magnitude more time hyper-optimizing it would be a waste of time and money.
Match the solution to the job. Optimizing everything is one of the age-old mistakes in computer science.
If so, that's missing half the picture. "People don't care about performance" isn't why devs gravitate towards Electron. Devs and managers gravitate towards Electron because it means they don't have to hire extra people and do more work to get their native apps working on whatever operating systems they ship to and rewrite the whole app for the web. Yeah, it'd be nice not to have the performance penalty, but some teams have accurately calculated that the performance loss the customer realistically notices is worth the benefits of writing and maintaining the app.
They’re too willing to accept an adequate solution because it “works” rather than spending just a little bit more time to find a more appropriate solution.
That doesn't mean it's appropriate to replace your billing system with one. Even if it works.
It's probably not useful to reason about a whole field in such absolute terms as what's best or what works.
Expecting teams to do more than a master's for every desktop app?
You're not going to have businesses if you apply the standard of this post to everything. Respectfully, the attitude of "optimize the world and damn the consequences" feels like it usually comes from people who haven't tried to deal with the realities of making money with code, even at a level of just understanding why your manager is telling you that they're pushing the release forward against your suggestion.
If that were possible, I don't think it would be unreasonable. A Master's degree is two-ish years, so about two person-years of effort. Once you're looking at even a small team, a desktop app would often have far more effort put into it.
Instead of 'a desktop app', I think the better comparison is to note that this is a FizzBuzz program. By design, it doesn't do any useful or algorithmically complicated work. It's a canonical example of a trivial program.
If you imagine putting Master's thesis levels of effort into every trivial part of a desktop application, then you'd start to outline the full scope of the problem. Rather than a "Master's thesis" effort, you'd be looking at something like a full, crash research program like the Apollo project.
The internet is actually faster than you think if you minimise spurious network requests, but most applications don't do that, leading to seconds of delays.
I agree with the spirit of what you imply: what a waste. On the other hand we do not use titanium everywhere, only where needed. There is best for a specific usecase.
Some nuance and examples of traditional engineering (titanium as material) were given, if you want to rebuke them.
I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are.
Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem.
In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.
I usually agree. But laziness as the primary constraint should feel appalling to anyone who would willingly call themselves an engineer. Perhaps I actually mean to use a different word for engineer but I don't know what it should be
> I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are.
I think you are, indirectly or inadvertently, citing electron and arguing in defense of it as a reasonable choice/option does do that.
> Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem.
Laziness is a choice. There are known better options, but software engineers *DID* choose to make it slow. The common axiom good, fast, or cheap; pick two. If you choose ease of development over fast you chose to make it slow. The people who build in python over C because they can write python faster, chose to make runtime slow. I guess you could argue for ignorance as a reason, but once you realize your software is slow, and refuse to do the work needed to fix it. You've also made the choice for it to be slow.
> In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.
Good engineers are willing to make the right trade offs. and I still believe that laziness is a positive trait in software engineers. But great engineers find a way to have both/everything, and people acting ethically don't prioritize their comfort or convenience over what's in the best interest of users.
The problem isn't if we can or can't make it fast, or correct, or user friendly. 55GiB/s fizzbuzz proves if you care enough, anything can be fast. The problem is people don't care, and that others who also don't care throw up their hands and say good enough is acceptable. And sure by definition it is acceptable. But I'd argue everything is awful, on fire, trash, user hostile, bad because too many people go ehh good enough you can stop trying.
It seems the difference is what we each are including in the "universe" of the problem. To me, it looks like you start and end with the developer (maybe developer + user), and assign laziness to them (aka you turn it into a moral problem).
On my argument, I am including the company, the users, and the whole economy. In that context, it is not about what the developer wants, but about the economical incentives, and it is not a moral problem but an optimization one.
Not sure what I’m going with this except I know VS code is touted as some kind of counter example a lot. But I also know such care didn’t go into most Electron codebases.
Is there no chance that at least some of those code-bases would be inefficient in other frameworks too? And no chance that the projects would have taken longer to release, or wouldn't exist at all because it was deemed too much faf, if another framework were used?
Other than running separate node and chromium instances for every instance of an app, what does Electron do to encourage the inefficiency that is attributed to it?
And I remember how my jaw has almost dropped when in 2022 I saw an operator of a POS that used a 80x25 TUI coming from a dinosaur era coded probably with Borland TurboVision... Man, how fast that was! Some windows literally appeared on the screen for a fraction of a second (the operator obviously memorized the sequence of actions). The fact that I found it unusual, when in fact it should be a norm, also speaks something about the performance of today software.
At this point, I think the debate about slow apps is more ideological than reality.
I also think a lot of people are mistaking backend/network latency for front-end slowness. Slack isn’t going to load your scroll back history any faster if the backend is spending all of that time searching the database. People are too quick to blame the front end.
Either that, or some of these posters are running 10-year old hardware and wonder why it’s slow
All of our interns: "How do I use this with VS code?"
They ssh using it, everything. They don't know anything else. They don't know that they are using ssh, they have a VS code terminal window open. It's kind of sad.
Meanwhile, I'm trying VS code on my 5 year old Mac, and it's like a slideshow. Open a file...wait for syntax highlighting to fill in, the keyboard response is laggy. It's so terrible. Sublime Text is a Tesla Plaid in comparison.