My negative views on Rust (2023) • Hacker News Board

Re: My negative views on Rust (2023)

#271

Post by School-Cotton » Thu, Oct 10, 2024, 7:39 PM UTC

tptacek wrote: post #180

hollerith wrote: post #177

Earlier quoted context omitted.

OK. Thanks. My guess was that since almost no one will pay more for a game's having fewer security vulns, there is less benefit to incurring the expense of Rust (takes longer to learn, development speed is slightly less)

When we talk about Rust being a reasonable choice for things like (say) a CRUD app, memory safety is already table stakes; every mainstream high-level language is memory-safe. Why would you ever pick Rust over Java? The answer to that question will be an even better answer to why you'd write a game in Rust.

Java may be memory safe but it is not data race safe (unlike Rust, the compiler does not enforce cross-thread synchronization). So there is still a safety-related reason to use Rust over Java.

That said, I don't really think Rust is a good choice for CRUD apps, because development velocity is more important than performance and they probably don't need to be multithreaded anyway.

But Rust would have been great for a lot of "systems" stuff that was historically written in Java, like Flink or Hadoop for example.

Re: My negative views on Rust (2023)

#272

Post by School-Cotton » Thu, Oct 10, 2024, 7:47 PM UTC

steveklabnik wrote: post #216

jcranmer wrote: post #154

Earlier quoted context omitted.

> I still don't know what people mean when they talk about "having to think about memory layout" The best example I'd give is the degree to which you have to ask yourself if you want to use String or if you want to use &str--is this struct, or this function, going to own the string or borrow it from somebody else? If you're borrowing it, who is owning it? Can you actually make that work (this is really salient for pa…

> the degree to which you have to ask yourself if you want to use String or if you want to use &str In practice, there isn’t a ton of thinking to do about this: if it’s a struct, you want String. If it’s a function parameter, you want &str, and if it’s a function’s return type, you want String. Doing that until you have a reason not to is the right call 95% of the time, and 4% of that last 5% is “if the return type i…

If you write Rust like this (insisting that structs always fulfill 'static) you will end up unnecessarily cloning memory way more than you would in a GC'ed language.

In GCed languages strings get allocated once when you need them, get referred to wherever you want, however many times you want (with no new calls to the allocation subsystem), and are freed once when you don't need them anymore, with minimal thought or intervention on the programmers part. Rust is absolutely not like this at all.

I agree with the overall idea that people exaggerate the difficulty of Rust, but come on, this is an exaggeration way too far in the other direction.

Re: My negative views on Rust (2023)

#273

Post by RandomThoughts3 » Thu, Oct 10, 2024, 7:52 PM UTC

rich_sasha wrote: post #67

I think to some extent Rust is a victim of its own unreasonable effectiveness. It is great at its narrow niche of memory safe low level programming, but frankly pretty good at lots of other things. But at these other applications some of its design principles get in the way - like the pedantic borrow checker. Languages not used outside their niches don't tend to collect such criticism. Python is a bit like that. It i…

I think Python is entirely different and a perfect exemple of why popularity trumps quality. I can’t think of any domains where Python would be the better choice. It’s actually pretty bad all things being considered but well the ecosystem is okay and plenty of people know it so why not. JS is another great exemple of that.

Re: My negative views on Rust (2023)

#274

Post by School-Cotton » Thu, Oct 10, 2024, 7:59 PM UTC

googh wrote: post #212

Ukv wrote: post #198

Earlier quoted context omitted.

I found their comment an interesting contribution to the discussion, pointing to a couple of specific pitfalls in C++. It's not just an empty "C/C++ bad, Rust good", and I don't see why it'd give the impression of an obnoxious community.

I just wrote that as an observation, and I did not mean to offend the parent. Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation. For example, C/C++…

> Now, let me explain why I felt that way. First and foremost, the phrase "undefined behavior" only applies to C and C++ because the specifications of those languages define it. The statement that Rust has no UB does not make sense because Rust has no specification, and all behavior is defined by the default implementation.

There are at least three classes of definedness of behavior:

1. The behavior of a program is defined by a spec.

2. The behavior of a program is not formally defined by a spec, either because the language has no spec or because it's imprecise, but it's defined in a sociological sense: that is, if a compiler doesn't follow the apparent meaning of the program, the people who develop the compiler will consider it a bug and you can report it to mailing lists or GitHub and probably get support.

3. The behavior is definitely undefined: a compiler can do anything in response to the program and the developers of the compiler will not consider it a bug.

C++ has a lot of 1, comparatively not a lot of 2, and a lot of 3.

Rust has none of 1, a lot of 2, and a lot of 3. But safe Rust has very little of 3.

Re: My negative views on Rust (2023)

#275

Post by School-Cotton » Thu, Oct 10, 2024, 8:01 PM UTC

mewpmewp2 wrote: post #167

Izkata wrote: post #91

Earlier quoted context omitted.

FYI this site doesn't use ``` for code blocks, it uses indentation (two spaces). https://news.ycombinator.com/formatdoc

A bit off topic, but how do people usually write code here or on Reddit, I always find it to be really cumbersome to make sure there's two spaces etc in front of everything? Is there some formatting tool that I'm not aware of that everyone else uses? Because in both forums I keep coming back to edits, and it takes forever to edit some of the things, manually. I feel like I'm being stupid or the UX of all of that is j…

I paste the code into an invocation of

  sed s/^/  /

Re: My negative views on Rust (2023)

#276

Post by School-Cotton » Thu, Oct 10, 2024, 8:05 PM UTC

bubaumba wrote: post #87

Const-me wrote: post #69

Earlier quoted context omitted.

> I just do not see why people seem to use "unsafe" so much Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code in the implementation to allocate heap memory. When you need efficient trees or graphs (I doubt any non-trivial software doesn’t need at least one of them), unsafe code is the only reasonable choice. C++ does pretty much the same under the hood, but th…

>> I just do not see why people seem to use "unsafe" so much >Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code Hmm.. wasn't memory safety the main selling point for rust? If not the only. Now mix of two languages looks even worst than one complex. Especially taking into account that it can be paired with safe language from long list. Don't know what rust fans…

> Hmm.. wasn't memory safety the main selling point for rust?

The vast majority of Rust programmers aren't spending their time re-implementing core data structures like Vec, so memory safety (and the fact that library authors can build safe abstractions on top of unsafe code, which is impossible in C or C++) still benefits them.

Re: My negative views on Rust (2023)

#277

Post by almostgotcaught » Thu, Oct 10, 2024, 8:08 PM UTC

neonsunset wrote: post #268

almostgotcaught wrote: post #254

Earlier quoted context omitted.

> Not completely but they are interchangeable ... I'll just ask you this extremely simple question: does C# compile/run/whatever-magic-you-think-it-does on targets that aren't in {x32, x86, ARM64}? Does it target RISC-V? Does it target PTX? Does it target AMDGPU? Are you getting the picture? Pre-empting the most low-brow dismissal: these are only niche targets if you've never heard of a company called NVIDIA.

> RISC-V The work is underway: https://github.com/dotnet/runtime/pulls?q=label%3Aarch-riscv > Nvidia's PTX, AMD https://ilgpu.net/ and even https://github.com/m4rs-mt/ILGPU/blob/c3af8f368445d8e6443f36... While not PTX, there's also this project: https://github.com/Sergio0694/ComputeSharp which partially overlaps with what ILGPU offers Arguably, even C++ itself - you are not using "full" C++ but a special subset that…

> you are not using "full" C++ but a special subset that works on top of specific abstraction to compile to GPUs

you're wrong - GPU offloading is just window dressing (#defines and CMake) around the compiler itself, which supports almost all of C++; see https://libc.llvm.org/gpu/ which builds libc (which is implemented using C++ in llvm) to amdgpu/ptx/etc.

> C# provides you the tools and a solution other languages in the class of Java, Go, TS

absolutely no one in their right mind would compare these languages to C++

> So you could reasonably replace a project written in C++ that requires assurances provided by C++ with C#

i think people that don't write C++ professionally just don't understand where/how/why C++ is used :shrug:

Re: My negative views on Rust (2023)

#278

Post by almostgotcaught » Thu, Oct 10, 2024, 8:12 PM UTC

Const-me wrote: post #263

almostgotcaught wrote: post #257

Earlier quoted context omitted.

> Not sure if it’s ready for production, but see that article: https://www.phoronix.com/news/Microsoft-dotNET-RISC-V > It's coming from a Samsung engineer, Dong-Heon Jung, who is involved with the .NET platform team and works on it as part of his role at Samsung. answer: no > According to nVidia, the answer is yes: https://developer.nvidia.com/blog/hybridizer-csharp/ > Dec 13, 2017 answer: no > Not sure, probably not…

> Dec 13, 2017 OK, here’s a newer project which does about the same thing i.e. compiles C# to PTX https://ilgpu.net/ BTW, it supports OpenCL backend in addition to CUDA.

> https://github.com/m4rs-mt/ILGPU/releases/tag/v1.5.1

> Sept 2023.

you guys just don't get it - there's a reason why CUDA is a dialect of C/C++ and not C# and it's not because the engineers at NVIDIA have just never heard of C#.

Re: My negative views on Rust (2023)

#279

Post by dartos » Thu, Oct 10, 2024, 8:26 PM UTC

pjmlp wrote: post #265

dartos wrote: post #239

Earlier quoted context omitted.

> Maybe not yet, but it is heading in that direction I have little doubt that Rust will end up being as complicated as C++ eventually, but a big difference is how explicit and well documented the discusson of new features are. The Rust RFCs provide a ton of context to almost every feature of the lagnuage. I find that historical context extremely helpful when trying to figure out why something is the way that it is. T…

ISO Rationales and papers.

Yeah I’m sure they exist, but googling “C++ ISO Rationales” doesn’t give me them.

Searching for “Rust RFCs” reveals a git repo with thousands of markdown files describing features and their motivations with links to discussions.

Re: My negative views on Rust (2023)

#280

Post by jltsiren » Thu, Oct 10, 2024, 8:26 PM UTC

Const-me wrote: post #235

jltsiren wrote: post #209

Earlier quoted context omitted.

I've been using std::vector with arrays that take up to tens of gigabytes for ~15 years without any real issues. Once the size of the allocation exceeds a few megabytes, any reasonable allocator is going to use an anonymous memory map anyway. And if the array doesn't need to grow, it takes effort to make a standard library vector worse than a manually optimized one. It's just a pointer and two integers, after all.

> it takes effort to make a standard library vector worse than a manually optimized one A simple use case is a 2D array where rows are padded to be multiples of 32 bytes (size of AVX SIMD vectors, saves a lot of implementation complexity because no need to handle remainders) or 64 bytes (saves a tiny bit of performance when parallelizing, guarantees cache lines aren’t shared between rows). When element size is not a…

It's obviously possible to find niche cases where the standard containers are not good enough. But the remaining 9999 cases out of 10000 are more interesting.

I also had one of those, in an application that created and deleted a large number of fixed-size arrays across many threads. A naive implementation using glibc malloc ended up with a massive memory leak caused by hundreds/thousands of fragmented arenas. A thread could usually not reuse the memory it had just freed, because it was using a different arena. And because the arena was not empty, it was not possible to unmap the memory.