• 5 Posts
  • 989 Comments
Joined 6 years ago
cake
Cake day: May 31st, 2020

help-circle
  • Yeah, particularly the broadcasting really irks me.
    That is an opinion you can hold for yourself and then make compromises as you encounter reality. I do expect programmers to hold strong opinions.

    But when you broadcast it, you strip yourself of the option to make compromises. You’re just saying something which is going to be wrong in one way or another in most situations. I do expect programmers to be smarter than that.




  • Large shared codebases never reflect a single design, but are always in some intermediate state between different software designs. How the codebase will hang together after an individual change is thus way more important than what ideal “north star” you’re driving towards.

    Yeah, learned this the hard way. Came up with an architecture to strive for 1½ years ago. We shipped the last remaining refactorings two weeks ago. It has been a ride. Mostly a ride of perpetually being low-priority, because refactorings always are.

    In retrospect, it would’ve likely been better to go for a half-assed architecture that requires less of a diff, while still enabling us to ship similar features. It’s not like the new architecture is a flawless fit either, after 1½ years of evolving requirements.

    And ultimately, architecture needs to serve the team. What does not serve the team is 1½ years of architectural limbo.



  • I mean, don’t get me wrong, I also find startup time important, particularly with CLIs. But high memory usage slows down your application in other ways, too (not just other applications on the system). You will have more L1, L2 etc. cache misses. And the OS is more likely to page/swap out more of your memory onto the hard drive.

    Of course, I don’t either sit in front of an application and can tell that it was a non-local NUMA memory access that caused a particular slowness, so I can understand not really being able to care for iterative improvements. But yeah, that is also why I quite like using an efficient stack outright. It just makes computers feel as fast as they should be, without me having to worry about it.


    Side-note

    I heavily considered ending this comment with this dumbass meme:

    Rust fast (aroused unga bunga)

    Then I realized, I’m responding to someone called “Caveman”. Might’ve been subconscious influence there. 😅






  • This isn’t Reddit. You don’t need to talk in absolutes.

    Similar to WittyShizard, my experience is very different. Said Rust application uses 1200 dependencies and I think around 50 MB RAM. We had a Kotlin application beforehand, which used around 300 dependencies and 1 GB RAM, I believe. I would expect a JavaScript application of similar complexity to use a similar amount or more RAM.

    And more efficient languages do have an effect on RAM usage, for example:

    • Not using garbage collection means objects generally get cleared from RAM quicker.
    • Iterating over substrings or list elements is likely to be implement more efficiently, for example Rust has string slices and explicit .iter() + .collect().
    • People in the ecosystem will want to use the language for use-cases where efficiency is important and then help optimize libraries.
    • You’ve even got stupid shit, for example in garbage-collected languages, it has traditionally been considered best practice, that if you’re doing async, you should use immutable data types and then always create a copy of them when you want to update them. That uses a ton of RAM for stupid reasons.

  • Yeah, gonna be interesting. Software companies working on consumer software often don’t need to care, because:

    • They don’t need to buy the RAM that they’re filling up.
    • They’re not the only culprit on your PC.
    • Consumers don’t understand how RAM works nearly as well as they understand fuel.
    • And even when consumers understand that an application is using too much, they may not be able to switch to an alternative either way, see for example the many chat applications written in Electron, none of which are interoperable.

    I can see somewhat of a shift happening for software that companies develop for themselves, though. At $DAYJOB, we have an application written in Rust and you can practically see the dollar signs lighting up in the eyes of management when you tell them “just get the cheapest device to run it on” and “it’s hardly going to incur cloud hosting costs”.
    Obviously this alone rarely leads to management deciding to rewrite an application/service in a more efficient language, but it certainly makes them more open to devs wanting to use these languages. Well, and who knows what happens, if the prices for Raspberry Pis and cloud hosting and such end up skyrocketing similarly.







  • Ephera@lemmy.mltoProgrammer Humor@programming.devfoss
    link
    fedilink
    English
    arrow-up
    6
    ·
    4 days ago

    To be fair, you can also somewhat steer whether it will take off as a dev, by how you promote it and how much time you take to make it easily usable by others. Many devs really don’t care to have their passion projects take off, because it means you’ll likely spend less time doing your passion thing, more time doing user support.



  • Ephera@lemmy.mltomemes@lemmy.worldI appreciate our community
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    5 days ago

    Yeah, I get called a tankie on the regular now, just because my user account is on .ml and I still don’t actually know what it’s supposed to mean. Apparently, I’m supposed to have political opinions on topics that I’m significantly more ignorant on than the people who call me that.