Hacker News Reader

Comment by bnastic | Hacker News Reader

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.

> there are now languages that can compete in terms of performance

Such as?

If Rust code is slower than equivalent C++, it's a bug. We track performance bugs, please file them :)

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.

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.

Last sentence is quotable :)

I agree haha.

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.

Type declarations in python have another name: unit tests.

I don't know why this is controversial, in Julia type annotations to expressions are basically asserts

Ummm, unit tests? The compiler offers a false sense of security. Type safety is not correctness.

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.

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.

My point is that there are tools and techniques that will solve these problems in ways that are more valuable than the compiler's type system.

If you seriously "refuse to review Python code" because you feel you need to visually check indentation, I think you might want to take a step back and evaluate your methods.

> At least with C++ you can reason that if a change compiles it has not made any dramatically stupid type errors.

And with Python you can reason that if code parses it isn't going to have undefined behavior (for example, segfaults randomly thousands of lines away from the actual problem due to heap corruption, or exploitable use-after-free vulnerabilities).

Type safety only has the benefits you describe if the language is actually type safe.

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.

Reply on news.ycombinator.com