Hacker News Reader

Comment by Konohamaru | Hacker News Reader

I don't think there's a truly safe programming language. When I was an undergraduate talking to somebody at the C. S. department (I was not a C. S. student, but I talked with many C. S. students) somebody there said that the risk of segfaults in C and Java, when the program approaches hundreds of kloc, are about equal. It's only in small, ungeneralizable programs where Java's GC guarantees safety.

Some people know how to manage memory and others don't. If you know how to manage memory, even C is a safe language. If you don't, not even the most formally-verified garbage-collected language can save you.

View on HN

That's one of those misguided deep sounding statements that are based in a fundamental lack of knowledge. What you, or this guy at the CS department, said is completely bullshit, evidenced by simple statistics of memory safety in languages. There is a reason many big companies are adopting Rust, and it's not just because "they feel like it" or they lack coders that "can program in C". E.g. take a look at: https://security.googleblog.com/2022/12/memory-safe-language...

Rust works because the Rust type system and development environment are tutors. They train up the developer like magic nannies until they learn how to correctly manage memory.

So the power of Rust comes from the the cooperation of the developer with the compiler and development environment willing to work through their severe instruction.

Developers in general unwilling to learn how to manage memory walk away from Rust based devteams.

Ok, there's still Java, Kotlin, Go and other memory safe languages in the sense of that they are statistically way less likely to have any memory related bugs compared to C, C++ or similar low-level no GC, no reference counting languages and thus the original argument of "good developers" not doing memory related bugs as well as "Java is as unsafe as C after a certain size" is utter bullshit.

At Google, that’s definitely not true. Our C code crashes way more often than our Java code.

Memory management is harder than just remembering to free. It requires a deep understanding of ownership, lifetimes, and threading. That is hard at scale unless it is built into the language.

> I don't think there's a truly safe programming language.

This is correct, technically, but you can achieve really high assurances of safety. "safe" is not a binary, but a spectrum.

The rest of the comment is patently false. It's actually close to the opposite of reality. The stricter the type system, the smaller the risk of unexpected behavior. Very very smart people who "know how to manage memory" use C and introduce memory errors very often. It's actually only in small, ungeneralizable programs where weaker type systems don't matter.

It's not the GC that guarantees safety. It's the encapsulation of every memory access inside a safe interface in the language's semantics. All the GC does is to make it possible to create the most popular interfaces over a finite memory.

And yeah, any bug on the interface or its implementation will lead to unsafe memory usage.

But anyway, no, if you make an interface where it's impossible to get memory corruption, you won't get memory corruption. It doesn't matter if the most inapt programmer on the world uses it. And the idea that people can manually manage memory on programs that are hundreds of megabytes large and created by many developers (or a single one at many different times) is about as wrong as the first part.

Oh jezz, anecdotes from people from academy, please.

>Some people know how to manage memory and others don't. If you know how to manage memory, even C is a safe language. If you don't, not even the most formally-verified garbage-collected language can save you.

Who knows how to manage memory then?

Windows engineers? Chromium engineers? Linux engineers?

all of them have history of failing at this, stop with this mindset.

I'm a firmware engineer. The languages I use most frequently for professional purposes are C and Rust. C is less "safe" than Rust, in the sense that a larger share of C code is susceptible to subtle footguns. Sure, if you poke at edge cases and fill your code with unsafe blocks, Rust will do bad things too. To me, this seems like a reasonable way of thinking about safety: it's all relative, and it's all context-dependent.

The conversation about language "safety" always leads to a bunch of goalpost-moving. Is a language with a safe type system still safe if its runtime is buggy? What if the OS/kernel has a bug? What if the CPU has a bug? How about anomalies in I/O hardware? Keep going down the rabbit hole, and you'll eventually reach the conclusion that all software is extremely fragile and could explode into a million pieces if a single cosmic ray goes the wrong way. Thinking about safety in an absolute sense isn't productive.

As an aside, your CS buddies told you a bunch of nonsense.

I've never encountered a segfault in Python that wasn't caused by interacting with C code. Is that claim even true about Java? unless it's a bug in the JVM itself, I'd be really really surprised to see an actual memory-related error arise from user-written code in any popular GCed language.

I luv C and have shipped tons of it in the past successfully enough but... to be frank C was, in effect, literally designed to cause/allow/enable segfaults. as a by-product of the "wild west" power of its & and * operators.

Can confirm I've only gotten the jvm to segfault when writing jni code -- never when writing vanilla java. To be generous to the OP though, perhaps the person who made the original comment was trying to write system code in java with lots of jni to access syscalls, or perhaps earlier versions of the jvm were less stable. The first jvm I ever used was 6, so I can't personally speak to earlier version.

I've found two segfaults in a 10+ year Java (well, actually mostly Scala) career (both known JVM bugs). It's rare, but possible.

Are you referring to the programming language, or the compiler and runtime environment necessary to execute the code? The Java Language Specification doesn't provide any strong guarantees of "safety". For example, it's certainly possible to write Java code with heap memory leaks or stack overflows. And I have run into multiple defects with the Oracle JVM that caused segfaults when executing certain code (although to Oracle's credit, their JVM is generally one of the highest quality and most reliable pieces of large platform software ever created).

Reply on news.ycombinator.com