Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Being fair about memory safety and performance

thecodedmessage.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Being fair about memory safety and performance

#31

Post by flykespice »

hutzlibu wrote: post #24
pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

It is the first time, I have heard of zig and I have to say, it indeed does sound nice. (But I haven't done low level programming in quite some time ..) Can you maybe summarize a bit more, why you prefer it over rust? The concept of rust, of beeing safe by default and only optimize critical parts sounds solid to me, but after a quick skimming, I have not seen such a feature for zig, too, possibly by design? " No hidd…

> No hidden control flow

Oh boy and I was just reading (https://news.ycombinator.com/item?id=30022022) about ISO C unsuitability for OS programming specially its implicit reordering of the control flow of the code, breaking parts that are sensitive to the machine code generated.

I wonder if that point was introduce as a response for this ISO C nuance, does this means the machine code generated by ziglang code will be explicitly what each statement does?

Re: Being fair about memory safety and performance

#32

Post by adgjlsfhk1 »

_vvhw wrote: post #20
saagarjha wrote: post #16

This article has a core point which is good: “in Rust the default is safe, and you have to opt-in to unsafety, but in C++ the default is unsafe, and you have to opt-in to safety”. I think it’s easy to argue for Rust using this construction, because, well, that’s the entire point why Rust was created. But, it really doesn’t take a very long post to talk about this. The remainder goes off the rails, talking about “C++…

> This article has a core point which is good: “in Rust the default is safe, and you have to opt-in to unsafety, but in C++ the default is unsafe, and you have to opt-in to safety”. On the subject of safe defaults, just to correct that Rust does not in fact have as much default memory safety with regards to buffer bleeds (e.g. variants of OpenSSL's Heartbleed) as it could [1], because it has unchecked arithmetic (int…

I don't think integer overflow is an especially common source of buffer overflow. This isn't based on any hard data, but I'm pretty sure that the 2 main types of buffer overflow come from

1. not doing the bounds check. 2. not storing the the bounds with the array.

Re: Being fair about memory safety and performance

#33

Post by eklavya »

pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

Every large project with years of code (legacy or well maintained) will be hardly ever re-written with complete success. It's not a property of programming language in my opinion. It's just economic sense. I doubt JDK will be rewritten in Rust/Zig, they did GraalVM in Java though.

Zig might be revolutionary but personally for me Rust is why I can dare write non gc code. I never thought I would ever be robotically precise with memory management on a large project in memory unsafe languages, that doesn't change with Zig. There are experts in C/C++, there will be experts in Zig and we will continue having memory safety CVEs because they don't make mistakes/they can use some other static analysis tool/they can test :)

I think people comfortable writing low level code under appreciate what Rust has done for bystanders or newcomers or a large team. It is definitely complex but choosing C/C++/Zig over it would make even less sense since lack of guardrails.

Re: Being fair about memory safety and performance

#34

Post by __s »

robalni wrote: post #25

I don't know what people mean when they talk about "safe" or "unsafe" code. Doing something like `int a[5]; a[2] = 100;` in C is perfectly safe because there is no bug in that code. The only thing that might be unsafe about that is if you change the code because then you might create a bug. Changing code is always unsafe because you can always create bugs in any language, even Rust. I don't think "safe" or "unsafe" c…

https://en.wikipedia.org/wiki/Memory_safety

Outside of your simple example C code, there exists C code which can only be memory safe if the compiler implements a heavy runtime: track pointer allocations, track where pointers source from, raise an error when the pointer is used in an undefined context. See how much work valgrind does to achieve a subset of this task

You could consider C code safe if you included a machine verifiable proof of memory safety with the code.. but that's ridiculously more effort than using Rust

In short, you're arguing semantics over the use of the word safe/unsafe when there's a clear definition Rust offers. You can argue that safe code still has bugs, but that's beside the point

Re: Being fair about memory safety and performance

#35

Post by robalni »

eklavya wrote: post #30
robalni wrote: post #25

I don't know what people mean when they talk about "safe" or "unsafe" code. Doing something like `int a[5]; a[2] = 100;` in C is perfectly safe because there is no bug in that code. The only thing that might be unsafe about that is if you change the code because then you might create a bug. Changing code is always unsafe because you can always create bugs in any language, even Rust. I don't think "safe" or "unsafe" c…

In my opinion it's pretty clear. Rust promises memory safety to me, so all code that is safe IS memory safe. I need to mark a block "unsafe" and have an understanding with the compiler that it can't ensure memory safety here and I am on my own. Makes perfect sense to me :)

If we say that "safe" code is "memory-safe" code, now the question is: what is memory-safe code? If memory-safe code is code that doesn't access the memory in unintended ways, then who knows what is unintended? Only the programmer does; it's impossible to write a compiler that knows what the programmer intends.

Like if you only want to access the data inside the bounds of the array, that's one intention that the compiler will help you to check. If you never intend to access the first element in the array, that's an intention that the compiler doesn't help you to check.

So, there is no memory-safe code or language. I think the only way you could define memory-safe code is that memory-safe code can't contain any code that breaks some rules that the compiler checks for. The problem with that is that those rules could be just about anything, so that definition is pretty useless.

Re: Being fair about memory safety and performance

#36

Post by patrick451 »

sundarurfriend wrote: post #14

The substance of the article is overshadowed by its unfortunate tone. > But wait! The C++ apologists are still talking! What are they saying? How have they not been completely flummoxed? is just one small sample. I came out of the article liking Rust a little bit less than when I went in (irrational, I know, but true). The quote from The Big Lebowski comes to mind: you're not wrong, author, ...

Yup. The rust evangelists have completely turned me off from rust.

Re: Being fair about memory safety and performance

#37

Post by robalni »

__s wrote: post #34
robalni wrote: post #25

I don't know what people mean when they talk about "safe" or "unsafe" code. Doing something like `int a[5]; a[2] = 100;` in C is perfectly safe because there is no bug in that code. The only thing that might be unsafe about that is if you change the code because then you might create a bug. Changing code is always unsafe because you can always create bugs in any language, even Rust. I don't think "safe" or "unsafe" c…

https://en.wikipedia.org/wiki/Memory_safety Outside of your simple example C code, there exists C code which can only be memory safe if the compiler implements a heavy runtime: track pointer allocations, track where pointers source from, raise an error when the pointer is used in an undefined context. See how much work valgrind does to achieve a subset of this task You could consider C code safe if you included a mac…

That wiki article seems to define memory-safe code as not containing an arbitrary list of bugs. This doesn't really make sense because even if you have code that doesn't contain those bugs, and even if you have a compiler that helps you to find those bugs, programming is always unsafe. You are not safe just because you don't use the "unsafe" keyword in Rust.

Re: Being fair about memory safety and performance

#38

Post by dralley »

hutzlibu wrote: post #24
pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

It is the first time, I have heard of zig and I have to say, it indeed does sound nice. (But I haven't done low level programming in quite some time ..) Can you maybe summarize a bit more, why you prefer it over rust? The concept of rust, of beeing safe by default and only optimize critical parts sounds solid to me, but after a quick skimming, I have not seen such a feature for zig, too, possibly by design? " No hidd…

I'm not OP, but the typical answer is that the language is small enough to be understood by any engineer with a few weeks of training, and is pretty easy for anyone familiar with C to grasp the concepts of almost immediately.

This is something that you definitely can't do with C++ and probably can't do with Rust.

For some people it's more comforting to be able to understand the entirety of the language and focus on the complexities of the problem and the implementation than to have a slightly higher level and larger language taking over the details. It's the same reason people tend to like C over C++ or Go over other languages.

This also generally translates into a couple of technical benefits as well, such as much much faster compilers relative to more complicated languages like C++ and Rust.

Personally I still find Rust much more comfortable to write code in generally but I really appreciate the elegance of the Zig approach.

Re: Being fair about memory safety and performance

#39

Post by eklavya »

robalni wrote: post #35
eklavya wrote: post #30

Earlier quoted context omitted.

In my opinion it's pretty clear. Rust promises memory safety to me, so all code that is safe IS memory safe. I need to mark a block "unsafe" and have an understanding with the compiler that it can't ensure memory safety here and I am on my own. Makes perfect sense to me :)

If we say that "safe" code is "memory-safe" code, now the question is: what is memory-safe code? If memory-safe code is code that doesn't access the memory in unintended ways, then who knows what is unintended? Only the programmer does; it's impossible to write a compiler that knows what the programmer intends. Like if you only want to access the data inside the bounds of the array, that's one intention that the comp…

On the contrary, that definition is the whole point and useful if both parties (compiler and programmer) agree what they mean. It's definitely useless for philosophical musings about words and meanings and what not :D

Re: Being fair about memory safety and performance

#40

Post by pron »

eklavya wrote: post #33
pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

Every large project with years of code (legacy or well maintained) will be hardly ever re-written with complete success. It's not a property of programming language in my opinion. It's just economic sense. I doubt JDK will be rewritten in Rust/Zig, they did GraalVM in Java though. Zig might be revolutionary but personally for me Rust is why I can dare write non gc code. I never thought I would ever be robotically pre…

Even if you look just at sound language guarantees, Zig is closer to Rust in terms of memory safety than to C or C++. That it doesn't make all of Rust's static guarantees doesn't put it in the same bucket as languages that make none. Once you reduce memory safety issues to below half of their current rate, there are different paths to achieving a good overall correctness story.
Post reply on HN