4 ms·

Meanwhile 99% of developers claim that writing desktop apps with Electron is perfectly fine, speed of the language and runtime doesn't matter since you are goin

Meanwhile 99% of developers claim that writing desktop apps with Electron is perfectly fine, speed of the language and runtime doesn't matter since you are going to wait for I/O anyway and waiting a few seconds after launching an app to be able to use it, is perfectly fine even on most powerful hardware. 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.

sillysaurusx 3y ago
These two viewpoints aren’t mutually exclusive. If they needed to develop fizzbuzz at 55GB/s, they might conclude that electron won’t get them there.
wsve 3y ago
Is your point that we should prioritize app performance and spending more on larger teams of develops, over the ease of quickly writing apps in popular frameworks that work on any system and the web? 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.
- hk1337 3y ago
  I feel like a lot of devs take things like YAGNI and “move fast and break” things a bit too seriously and to great extreme. 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.
  - sokoloff 3y ago
    If it works (or even “works”) for the users and for the business, it’s probably appropriate.
    - xorcist 3y ago
      That's a slippery one. Spreadsheets in Excel works for the business. 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.
      - projektfu 3y ago
        Yet many small business billing systems are basically an excel sheet with a word doc or manual online invoice system like square invoices. You wouldn't replace a functioning billing system with this one, but you might not replace this one with an expensive custom system. As programmers, we often discount the value of our time to zero when we're writing software because it's kind of fun. But for a non programmer, 10-30 minutes of work each week invoicing isn't an issue if the system never gets into an unusable state.
      - bombolo 3y ago
        Excel works for the business, but see how much money is estimatedly lost yearly due to excel mistakes.
        sokoloff 3y ago
        Excel is the most widely used no-code/low-code environment by a wide margin. It's not surprising that something in such widespread use has a lot of bugs in aggregate. It's not the typical office automation written in <pick your favorite language> is bug-free either.
mejutoco 3y ago
I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. 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.
- grayhatter 3y ago
  It's what everyone else is using so it's fine. Isn't the convincing argument you might hope it is.
  - jabradoodle 3y ago
    It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).
  - mejutoco 3y ago
    My argument is: engineering is not about best in absolute terms, but about best given constraints. 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.
    - grayhatter 3y ago
      > My argument is: engineering is not about best in absolute terms, but about best given constraints. 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.
Pannoniae 3y ago
Yes, and the reason you are waiting on I/O is because you try to get everything from the internet instead of just computing it locally. 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.
lmm 3y ago
And they're right. 55 GiB/s FizzBuzz is cool, but it's no more useful than a normal-speed version, and if someone was paying you for your time then spending months implementing FizzBuzz would be outright irresponsible.
- eska 3y ago
  Of course this is just a toy example. But suppose you had a different task that is I/O bound, like processing terabytes of jsonlines files. 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.
  - sophacles 3y ago
    This isn't a very strong generalization. * 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.
dom96 3y ago
citation needed
NegativeK 3y ago
> I already have a master's thesis. This was harder. – ais523 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.
- Majromax 3y ago
  > Expecting teams to do more than a master's for every desktop app? 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.
- deleted 3y ago
  [deleted]

sillysaurusx 3y ago

These two viewpoints aren’t mutually exclusive. If they needed to develop fizzbuzz at 55GB/s, they might conclude that electron won’t get them there.

wsve 3y ago

Is your point that we should prioritize app performance and spending more on larger teams of develops, over the ease of quickly writing apps in popular frameworks that work on any system and the web? 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.

hk1337 3y ago
I feel like a lot of devs take things like YAGNI and “move fast and break” things a bit too seriously and to great extreme. 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.
- sokoloff 3y ago
  If it works (or even “works”) for the users and for the business, it’s probably appropriate.
  - xorcist 3y ago
    That's a slippery one. Spreadsheets in Excel works for the business. 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.
    - projektfu 3y ago
      Yet many small business billing systems are basically an excel sheet with a word doc or manual online invoice system like square invoices. You wouldn't replace a functioning billing system with this one, but you might not replace this one with an expensive custom system. As programmers, we often discount the value of our time to zero when we're writing software because it's kind of fun. But for a non programmer, 10-30 minutes of work each week invoicing isn't an issue if the system never gets into an unusable state.
    - bombolo 3y ago
      Excel works for the business, but see how much money is estimatedly lost yearly due to excel mistakes.
      - sokoloff 3y ago
        Excel is the most widely used no-code/low-code environment by a wide margin. It's not surprising that something in such widespread use has a lot of bugs in aggregate. It's not the typical office automation written in <pick your favorite language> is bug-free either.

mejutoco 3y ago

I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. 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.

grayhatter 3y ago
It's what everyone else is using so it's fine. Isn't the convincing argument you might hope it is.
- jabradoodle 3y ago
  It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).
- mejutoco 3y ago
  My argument is: engineering is not about best in absolute terms, but about best given constraints. 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.
  - grayhatter 3y ago
    > My argument is: engineering is not about best in absolute terms, but about best given constraints. 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.

Pannoniae 3y ago

Yes, and the reason you are waiting on I/O is because you try to get everything from the internet instead of just computing it locally. 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.

lmm 3y ago

And they're right. 55 GiB/s FizzBuzz is cool, but it's no more useful than a normal-speed version, and if someone was paying you for your time then spending months implementing FizzBuzz would be outright irresponsible.

eska 3y ago
Of course this is just a toy example. But suppose you had a different task that is I/O bound, like processing terabytes of jsonlines files. 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.
- sophacles 3y ago
  This isn't a very strong generalization. * 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.

dom96 3y ago

citation needed

NegativeK 3y ago

> I already have a master's thesis. This was harder. – ais523 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.

Majromax 3y ago
> Expecting teams to do more than a master's for every desktop app? 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.
deleted 3y ago
[deleted]