Principal Engineer for Accumulate

  • 0 Posts
  • 55 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle


  • I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.







  • Ethan@programming.devtoProgrammer Humor@programming.devGo vs Rust learning
    link
    fedilink
    English
    arrow-up
    10
    arrow-down
    7
    ·
    2 months ago

    Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.

    I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.

    *I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.



  • For references within a scope, you’re probably right. For references that cross scope boundaries (i.e. function parameters), they necessarily must consume memory (or a register). Passing a parameter to a function call consumes memory or a register by definition. If a function call is inlined, that means its instructions are copy-pasted to the call location so there’s no actual call in the compiled code.




  • Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.

    It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.





  • Programming languages are tools. I couldn’t care less about learning a new tool just for the sake of learning. My interest in learning tools is exclusively practical - if they help me do my work better.

    I find functional languages interesting, but that’s because I find the underlying theory interesting and worth learning for its own sake, not because I actually care about the specific language it’s written in. Even then these days I’d rather learn about woodworking (which is currently my main hobby) than a programming paradigm I’m probably never going to use.