518
You can pry pattern matching from my cold dead hands (europe.pub)
submitted 9 months ago by to c/programmer_humor@programming.dev
222 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 125 points 9 months ago (40 children)

Programming languages, much like the jackass in the middle, are tools. Different tools are for different things. The right tool for the job can make your day. The wrong tool can make you question your entire career.

  • permalink
  • fedilink
  • source
  • hideshow 40 child comments
    •
  • [–] 38 points 9 months ago (8 children)

    Funny how tools are useful. But a person who is a tool is not.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 16 points 9 months ago (6 children)

    A tool of a person is a fool who is being used by someone else. They might not be useful to you, but to who ever makes the koolaid they're drinking, they're a very good tool.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 9 months ago* (5 children)

    I think that's the basic idea, but in practice it's used for people who are just generally dumb as well.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 9 months ago (2 children)

    Eh, people misuse terms all the time. It shouldn't change what it's meant to mean.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 20 points 9 months ago (10 children)

    Exactly. And what is the best tool? The best tool for the job

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 13 points 9 months ago (4 children)

    That's just not terribly meaningful, though. Was JavaScript the "best tool" for client-side logic from the death of Flash until the advent of TypeScript? No, it was the only tool.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 12 points 9 months ago (3 children)

    So, lisp?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 10 points 9 months ago (7 children)

    I seem to remember hearing this story: Back in the 2000s, Google did all their back-end stuff in C++ to make sure it was performant, and when they acquired Youtube they found it was made in Python, slow to run, fast to develop.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 8 points 9 months ago (6 children)

    Did they change it after the acquisition? Or is python why it's still so freaking slow?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 8 points 9 months ago (3 children)

    Lol @ YouTube being slow

    Look at the amount of data that goes through their servers every millisecond. It's ridiculous. All things considered, YouTube is lightning fast.

    Maybe the UI isn't as snappy as it could be, but the blame there lies solely on throwing more and more javascript at it to add "features" that end users don't really want.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 6 points 9 months ago* (1 child)

    Things is you don't crunch numbers in Python code, you do that in libraries called from Python.

    It's a few statements of orchestration and any heavy lifting is encapsulated compiled code.

    You don't do tight loops on Python, or if you do you're using it wrong.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 points 9 months ago (6 children)

    Right... And the best tool for every job is of course Rust.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 5 points 9 months ago (5 children)

    Embedded? Rust!

    Web Frontend? Rust!

    Web Backend? Rust!

    idk what orher kinds of programming exist...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 9 months ago (1 child)

    That is, like, genuinely an advantage, though. At $ DAYJOB, we have a project that spans embedded, backend, web frontend and CLI, and for all of these, Rust is decent.

    Like, I can see why a frontend dev would want to use HTML+CSS+JS/TS (rather than HTML+CSS+Rust), mainly because the massive ecosystem of JS components makes you more productive.

    But you pretty much won't ever develop a web frontend without an accompanying backend, and then being able to use the same language-expertise, libraries, utility functions and model types, that is also a big boost to productivity, especially if you won't have a dedicated frontend dev anyways.

    Realizing that also made me understand why people subject themselves to NodeJS for their backend, which has the same advantage, just with the big ecosystem in the frontend and the small ecosystem in the backend.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 9 months ago

    because the massive ecosystem of JS components makes you more productive.

    Slightly less ironic: I question even this right now (as I have to suffer from endless "hot"-reloading and browser-crashes because of Next.js bloat).

    I think the massive ecosystem has fewer high quality libraries than Rust at this point. I use both JS/TS in frontend and Rust (either frontend more as a hobby and backend) extensively, and I very often check the dependencies-source, and even more often rewrite it (unfortunately not in Rust), because of low-quality. And it's sooo slow... the tooling and the frontend (albeit I think that has a very lot to do with next.js... and with how easy it is to make it slow for someone not that experienced or someone not being extremely careful).

    Frontend is not yet as matured as JS/TS (whatever matured is, but the count of frontend frameworks is at least a magnitude higher in JS/TS), but I think when I would start a new company I would default to Rust now as frontend indeed, the language itself is for me reason. And I think vanilla-js (or Rust?) is not that much worse (time/effort-wise, sanity etc.) for more complex applications than what the Next.js ecosystem has produced so far.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 9 months ago (2 children)

    Game dev? Just force Rust into it, despite being quite mediocre for the job, there's so many engines written in Rust. ECS is the answer to everything!

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 9 months ago (1 child)

    "Game dev... Just force Rust into it"

    What's wrong with Rust for game dev? It seems similar to C++, and C# which are the dominant languages.

    I can see arguments that the current projects have poor approaches, but not that the language itself is ill-suited.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 9 months ago

    Rust has constant by default, which many don't like in gamedev circles. Yes, compilers don't care and optimize - at the highest optimization setting, otherwise it's marginally slower, and each constant use will just add up.

    Other Functional Programming features of Rust makes writing transform functions quite good, until you need to get the results of those functions to be displayed.

    Some of the system-level allocation is quite hard with Rust, if not impossible.

    The borrow checker is hard to use with games, not to mention it has a big impact on performance.

    Object-Oriented Programming is possible through macros, but sometimes you need OOP instead of Entity Component System for more system-level stuff. Sure, ECS is really nice for game systems, but Bevy (an engine written in Rust) uses it for everything.

  • permalink
  • fedilink
  • source
  • parent