Hacker News Reader

Comment by pdimitar | Hacker News Reader

Well, in that case your statement of "If only people were so excited about making OpenSSL not a flaming hot bag of shit" is severely misplaced. I have no influence over Linux governance. 99.9999% of us out there don't have that influence. So what was your point exactly?

Rants are fine and we all do them but I will strongly disagree with any responsibility or guilt transferred to me because I am excited about Rust and not about OpenSSL. As you yourself pointed out, alternatives exist but aren't adopted so the problem is political and not technical. Right?

> The rest of your statement is just making my point for me.

Not sure what you mean but okay. ¯\_(ツ)_/¯

View on HN

> Furthermore, do consider that some of us were programming C and C++ and found them sub-optimal. But here we would likely venture into language wars because there are a lot of programmers like myself out there who will never subscribe under the notion of "C is fine, you are just doing it wrong".

> Not sure what you mean but okay. ¯\_(ツ)_/¯

Blame the carpenter, not the tools.

C or C++ isn't a real business problem domain that anyone has. Nobody's committing their budget to fix that. That's the kind of problem only held by ideologues and other unreasonable people.

My point was that people who care about fixing problems in the security domain will look to fix the biggest problems they can in the security domain. They won't look at it and say "no, I can't fix this because C/C++ is unacceptable to me."

That's someone who cares more about the tools than the problem domain. Whethor or not you think C/C++ are suitable to the problem domain of writing secure software, software will be written in C/C++ and must be secured.

Turn down work all you want though. More for the rest of us.

> My point was that people who care about fixing problems in the security domain will look to fix the biggest problems they can in the security domain. They won't look at it and say "no, I can't fix this because C/C++ is unacceptable to me."

Sometimes that's true, sometimes it isn't. It's a cost-benefit analysis like almost anything else.

Everyone is free to disagree on this -- or like you, misinterpret my motivation as "caring more about the tools than the problem domain". Quite the contrary, I want the problems solved but I also put deadlines and energy budgets on trying to solve problem X with tool Y and if it doesn't cut it within the deadline and/or the budget then it's out. Sure, that means more C/C++ work for you. I am OK with that.

But let's not pretend that OpenSSL can only be written in C or C++ now. We all know that's not true.

> Blame the carpenter, not the tools.

It's no accident that professional craftsmen utilize innovation in their tooling as well, like Sushi chefs using ceramic knives for some fish and steel knives for others. Ceramic knives weren't that popular some mere decades ago.

Your black and white philosophy makes no favours to your argument.

It seems you take an issue with the rising popularity of Rust. But let me ask you this: if you are so confident in C/C++'s superiority, why are you bothered?

> It seems you take an issue with the rising popularity of Rust. But let me ask you this: if you are so confident in C/C++'s superiority, why are you bothered?

I don't have a problem with Rust at all. It's a fine tool and I'd be happy to use it (and have), just like any other. I work on interesting problems and am tools-agnostic (aside from certain languages being suited or not to specific domains).

I have a problem with people who lose their objectivity as a result of their enthusiasm for Rust and go around shouting in every project like it's the most important thing to happen in the last 30 years of Computer Science. It wouldn't be such a meme if people didn't actually friggin' do this.

> I have a problem with people who lose their objectivity as a result of their enthusiasm for Rust and go around shouting in every project like it's the most important thing to happen in the last 30 years of Computer Science. It's an annoying trend the last 4-5 years.

I hear this a lot and I've never witnessed it once. ;)

It's all filter bubbles, dude. Chill. The world is not ending.

As an example: the comments from both Linus/Greg and the Rust community that relate to the OP are quite balanced and nobody is shouting for revolutions.

---

...That being said, I wouldn't make grandiose claims about Rust myself even if it solved a lot of problems for me, but still: Rust is an important innovation regardless. It seems a lot of the software area has chased its own tail before we had some languages step forward and solve various problems that people kept trying to fix themselves on an ad-hoc basis (and kept failing at it).

Rust is one example, Erlang/Elixir are another, and when OCaml finally gains parallel abilities, it will be an additional (and very fine) example as well. Surely other examples exist.

If we're now discussing just the point you quoted me on -- I on my side take issue with the people who are way too liberal and love to pretend that it doesn't matter what language is being used regardless of the business and technical problems. Because oh my god yes, yes it does matter. A lot.

All new languages are extremely important innovations until they age a bit and get severe warts. Rust is already getting them. See: https://theta.eu.org/2021/03/08/async-rust-2.html

Rust is already getting foot-guns like C++ did.

Modern C++ (>C++17) with RAII and neat libraries is already an elegant, high performance and high-productivity language with good IDE/editor support.

And its not like C++ is standing still. You have standardised concepts, modules and co-routines out this year. Modules will fix several of C++'s shortcomings wrt build tooling and setup. I am personally looking forward to C++ 20 co-routine support in all the major compilers - will enable one to develop graceful-async, portable and stable libraries without all that Rust churn needing re-writes all the time.

Competition is good, but its best to take the Rust blinkers off a bit.

Don't get me wrong -- I agree Rust has some footguns. And I had high hopes for the 2021 Edition to introduce some terser syntax here and there but alas, not happening.

I am not fangirling for Rust at all.

I am saying that it's much easier to make costly mistakes in C and legacy C++. I am aware of the modern efforts in C++ but they don't help with the literal mountains of legacy code that has to be maintained out there...

You have to blame both the carpenter and the tools. Since there is no such a thing as a perfect carpenter, mistake will happen, that why a tool that can prevent a whole category of mistakes is a good thing. It's no mistake good carpenter don't use crappy tools. To be the most efficient, you need the good carpenter with the good tools.

Of course you have to care about the problem domain first, but it's absolutely wrong that nobody commit their budget to fix C++ safety problems. There is a massive amount of static and dynamic tooling to mitigate its problems and a substantial part of the C++ evolution these last years was to improve safety. Rust was able to go further than C++ in this area since it is not yet constrained by decades of history.

> Blame the carpenter, not the tools.

That's a weird way to put it. I would blame the carpenter for picking the wrong tools.

Reply on news.ycombinator.com