5 ms·

It's sad that you need to justify using one of the most established and longest serving languages/platforms ever.

by bnastic 11y ago

sgeisenh 11y ago
I don't think it is sad. You explained why it is necessary, C++ has been around for a while, is/was great but there are now languages that can compete in terms of performance with fewer drawbacks in terms of security and undefined behavior. If you're starting from scratch, it is important to strongly consider which language and platform best suits your needs. Anecdotally, a lot of companies have found success using newer languages because they tend to attract a better proportion of talented people.
- n00b101 11y ago
  > there are now languages that can compete in terms of performance Such as?
  - steveklabnik 11y ago
    If Rust code is slower than equivalent C++, it's a bug. We track performance bugs, please file them :)
    - nickpsecurity 11y ago
      I like the quip but that's barely an answer given OP avoided Rust specifically. There's a difference between a high-performing language in development (and debugging) vs a high-performing language with over a decade of work into its tooling and support. The latter's strengths and weaknesses are known through and through with many implementation and library problems likely worked out long ago. So, if it was apples to apples, I'd probably cite Ada, Eiffel, Modula-3, or Component Pascal as the closest to C++ in terms of performance and key features while being safer and more readable. Each has had years of work, support from commercial sector (except Modula-3 now), and programs tend to work more than break after a compile. That said, your Rust work is exciting and I hope it gets in that same category. It's just so new and evolving that its not in C++'s class in terms of risk or predictability. Not yet.
      - steveklabnik 11y ago
        Absolutely. I was responding more to this conversation than the author; they specifically said "new" languages :) Your points are all legit. Unfortunately, the only way to get an old language is to start with a new one, and then let time pass.
        vram22 11y ago
        Last sentence is quotable :)
        nickpsecurity 11y ago
        I agree haha.
  - Shorel 11y ago
    D.
JustSomeNobody 11y ago
Indeed it is. It wouldn't be this way if most hiring companies hired for talent and not buzzwords/trends. As it stands, half of developers don't want to touch a language that won't help them get another job. The other half suck so they have to pad their resumes with the new hotness to even have a chance at getting a job.
thrownaway2424 11y ago
Indeed, the given strawman alternative languages (Ruby and Python) are far, far worse for productivity. Python changes are totally unreviewable since one cannot in any way reason about the correctness of a function call without reading the definition of the function itself, and all the functions to which it passes the arguments, all the way down, which of course takes forever. At least with C++ you can reason that if a change compiles it has not made any dramatically stupid type errors. You still need to think about whether any unnecessary temporaries or copies were made, or questionable assignments, but you need only think about that one level deep. Is seems to me far more dangerous to suggest writing new code in Python.
- mathgenius 11y ago
  Type declarations in python have another name: unit tests.
  - CyberDildonics 11y ago
    I don't know why this is controversial, in Julia type annotations to expressions are basically asserts
- hifier 11y ago
  Ummm, unit tests? The compiler offers a false sense of security. Type safety is not correctness.
  - avita1 11y ago
    Not to dredge up this debate for the umpteenth time, but the same can be said of unit tests: they are not a proof of correctness, and they often give you a false sense of security.
    - thrownaway2424 11y ago
      The Internet has, indeed, conducted this argument thousands of times. My point here is only about the difficulty of reviewing Python code. I find myself sometimes having to hold up a piece of paper to the screen to see if the indentation has been done right, in addition to the aforementioned function-body-reading chores. Of course my opinion is of no concern to people except those who work with me, from whom I refuse to review Python code. It's just not worth my time.

It's sad that you need to justify using one of the most established and longest serving languages/platforms ever.

by bnastic 11y ago

It's sad that you need to justify using one of the most established and longest serving languages/platforms ever.

I don't think it is sad. You explained why it is necessary, C++ has been around for a while, is/was great but there are now languages that can compete in terms of performance with fewer drawbacks in terms of security and undefined behavior. If you're starting from scratch, it is important to strongly consider which language and platform best suits your needs. Anecdotally, a lot of companies have found success using newer languages because they tend to attract a better proportion of talented people.

n00b101 11y ago
> there are now languages that can compete in terms of performance Such as?
- steveklabnik 11y ago
  If Rust code is slower than equivalent C++, it's a bug. We track performance bugs, please file them :)
  - nickpsecurity 11y ago
    I like the quip but that's barely an answer given OP avoided Rust specifically. There's a difference between a high-performing language in development (and debugging) vs a high-performing language with over a decade of work into its tooling and support. The latter's strengths and weaknesses are known through and through with many implementation and library problems likely worked out long ago. So, if it was apples to apples, I'd probably cite Ada, Eiffel, Modula-3, or Component Pascal as the closest to C++ in terms of performance and key features while being safer and more readable. Each has had years of work, support from commercial sector (except Modula-3 now), and programs tend to work more than break after a compile. That said, your Rust work is exciting and I hope it gets in that same category. It's just so new and evolving that its not in C++'s class in terms of risk or predictability. Not yet.
    - steveklabnik 11y ago
      Absolutely. I was responding more to this conversation than the author; they specifically said "new" languages :) Your points are all legit. Unfortunately, the only way to get an old language is to start with a new one, and then let time pass.
      - vram22 11y ago
        Last sentence is quotable :)
        nickpsecurity 11y ago
        I agree haha.
- Shorel 11y ago
  D.

JustSomeNobody 11y ago

Indeed it is. It wouldn't be this way if most hiring companies hired for talent and not buzzwords/trends. As it stands, half of developers don't want to touch a language that won't help them get another job. The other half suck so they have to pad their resumes with the new hotness to even have a chance at getting a job.

thrownaway2424 11y ago

Indeed, the given strawman alternative languages (Ruby and Python) are far, far worse for productivity. Python changes are totally unreviewable since one cannot in any way reason about the correctness of a function call without reading the definition of the function itself, and all the functions to which it passes the arguments, all the way down, which of course takes forever. At least with C++ you can reason that if a change compiles it has not made any dramatically stupid type errors. You still need to think about whether any unnecessary temporaries or copies were made, or questionable assignments, but you need only think about that one level deep. Is seems to me far more dangerous to suggest writing new code in Python.

mathgenius 11y ago
Type declarations in python have another name: unit tests.
- CyberDildonics 11y ago
  I don't know why this is controversial, in Julia type annotations to expressions are basically asserts
hifier 11y ago
Ummm, unit tests? The compiler offers a false sense of security. Type safety is not correctness.
- avita1 11y ago
  Not to dredge up this debate for the umpteenth time, but the same can be said of unit tests: they are not a proof of correctness, and they often give you a false sense of security.
  - thrownaway2424 11y ago
    The Internet has, indeed, conducted this argument thousands of times. My point here is only about the difficulty of reviewing Python code. I find myself sometimes having to hold up a piece of paper to the screen to see if the indentation has been done right, in addition to the aforementioned function-body-reading chores. Of course my opinion is of no concern to people except those who work with me, from whom I refuse to review Python code. It's just not worth my time.