• sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    7
    ·
    9 months ago

    I just want to point out that interpreted languages don’t have to be slow. For example, LuaJIT is competitive with Java in terms of performance, and not that much slower than C. Likewise, PyPy is almost always consistently faster than CPython, and Python 3.13 will have a JIT. I’ve also used numba to improve performance in Python (got close enough to naive Rust to not be worth adding Rust to our pipeline).

    If you want scripting languages to be fast, there are options, so the decision should instead be made based on the benefits of each. For example:

    • scripting languages - generally better edit/reload experience, write once, run anywhere an interpreter exists
    • compiled languages - catch common errors before running, lots of fixes for various platforms

    I’m super interested in Rust because it catches way more common errors than most compiled languages, so you’re getting a lot more value for that compile step. My day job is Python + Javascript, though I have nearly 10 years with Go and most of my personal projects use Rust these days, so I feel like I’m fairly experienced here.

    just excuses and/or part of some dumb trend

    I agree. There are good reasons to prefer scripting languages to compiled languages and vice versa, but most people don’t seem to decide based on those reasons, they often decide based on what’s easier to hire for, what they’re familiar with, or what’s already being used.

    I’m super excited about Rust gaining traction because it’s basically the best case for a compiled language I’ve seen. Maybe it’ll revise the trend toward higher level languages and encourage a bit more provable correctness.