4 ms·
> Those who think C is inherently good can’t be convinced otherwise opposite is also true "those who think C is inherently not good [...]" > Any data backed s
by peoplefromibiza 4y ago
> Those who think C is inherently good can’t be convinced otherwise
opposite is also true "those who think C is inherently not good [...]"
> Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers.
They aren't being dismissed, but criticized when used to promote other languages.
Those studies are partial and about a different topic.
They are are about bugs in millions lines of code bloated products, written in C++. Not counting the actual implementation "bugs", like the browser X leaking details about users to make fingerprinting easier and then sell ads.
You know why those companies are worried about memory safety and nothing else?
Because it's the way people can circumvent the so called "features" and "protections" they implement.
Here we are talking about Ruby extensions in C, which is a completely different domain, involving completely different tradeoffs.
The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices.
Just think about the fact that the Ruby interpreter itself is written in C.
Think about the fact that a bug in path traversal or input sanitization is at least an order of magnitude easier to exploit and usually more dangerous than a double free.
> If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD
as a non believer, that is the least problematic issue about Christianity.
dates are conventions, we are not actually leaving in 2022, would you change your calendar because dating is completely made up?
also: Jesus does not exists nor can do anything for you, C does.
- nindalf 4y agoOh, is that so?
- peoplefromibiza 4y agoyes.
- jeltz 4y agoAs a C programmer I am baffled by your attitude. Do you feel so threatened by people creating new programming languages? Personally I love that people are working on projects like Zig which try to be a better C. Rust is also an interesting project which has had a lot of positive effects on programming and programming language design, but it is not a perfect replacement for C and more of a better C++. While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. > The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices. He used Zig, not Rust.
- peoplefromibiza 4y ago> Do you feel so threatened by people creating new programming languages? that's a lot of assumptions. I never even said I write C code. It feels to me that you are projecting your doubts on me to validate your choices. I have absolutely no problem at all with programming languages, in fact I always try all the new ones I can, I can actually write code, with very different degrees of competence, in more than 30 of them, including Rust, my new language of choice to write NIF extensions for Erlang/Elixir. Thanks to rustler crate which is awesome. > While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. Never said the opposite though. Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++" > He used Zig, not Rust. I was referring to this sentence he wrote Other options were not great as well. I can use Rust, but I have never been on good terms with Rust
- masklinn 4y ago> Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++" True. It's, if anything, worse: the users of the extension might not even know it's native, will definitely assume it's fully safe, and will absolutely feed it attacker-controlled data without a thought. And the extension author won't have the engineering review and tooling that a Google has in place either.
- peoplefromibiza 4y ago> True. It's, if anything, worse: Ruby extensions in C (or any other language) are mostly - 100% of the time for non-trivial stuff - a thin layer wrapping a native library. The attack surface is minimal and it's almost entirely in the realm of the library code, which usually the extension developer has no control over. it is also much easier to sandbox a ruby process in a server than Chrome on the user's computer. > the engineering review and tooling that a Google has in place either hardly, I would argue that something that is hundreds of thousand times smaller in scope and number of lines of code is much easier to write, review, test and debug. Chrome seats at 7 million LoC, the average Ruby extension is ~100 LoC. The fact that writing a wrapper is trivial compared to writing a browser, also helps a lot. Many people can write a bug free correct wrapper in any language using only their brain. No one can write Google Chrome on their own, let alone a bug free correct implementation of it. Premature optimization is the root of all evil. “Omnia venenum sunt: nec sine veneno quicquam existit. Dosis sola facit, ut venenum non fit.”