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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

121–130 of 319 posts

Re: A Rust shaped hole

#121

Post by adastra22 »

tialaramex wrote: post #46
uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

C++ has editions too btw. C++11, C++14, C++17, etc. These are opt in and allowed to break compatibility, although that is very rarely done in practice.

Re: A Rust shaped hole

#122

Post by adastra22 »

bryanlarsen wrote: post #89
uecker wrote: post #45

Earlier quoted context omitted.

I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step. For C++ this is much more painful because all the tools invented to make the code look concise make it extremely hard to follow and change. From the feature set, I would say that Rust is the same (but I have no experience refactoring Rust code).

> but I have no experience refactoring Rust code But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible…

Also, although it was not designed with this in mind, the described process adopts VERY well to LLMs. You can make a refactoring change, then tell the LLM to "run cargo check and fix the errors." And it does a very good job of doing this.

Re: A Rust shaped hole

#123

Post by anon-3988 »

tines wrote: post #44
uecker wrote: post #43

Earlier quoted context omitted.

I would say that most of the complexity in both cases comes from overengineering.

Can you give some examples of Rust and C++ design that are over engineered?

For C++ specifically, constructors. Just have functions for gods sake.

Re: A Rust shaped hole

#124

Post by anon-3988 »

uecker wrote: post #45
dijit wrote: post #24

Earlier quoted context omitted.

You’re right that Rust is a ball of complication. I am a fan of Rust but it’s definitely a terse language. However there are definitely signs that they have thought about making it as readable as possible (by omitting implicit things unless they’re overwritten, like lifetimes). I’m reminded also about a passage in a programming book I once read about “the right level of abstraction”. The best level of abstraction is…

I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step. For C++ this is much more painful because all the tools invented to make the code look concise make it extremely hard to follow and change. From the feature set, I would say that Rust is the same (but I have no experience refactoring Rust code).

> I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step.

Really? How confident are you to change a data structure that uses an array with linear search lookup to a dictionary? Or a pointer that now is nullable (or is now never null)?

Unless you have rigorous test or the code is something trivial, this would be a project of its own.

I am pretty sure I can swap out the implementation of the dictionary in the rust compiler and by the time the compilation issues are worked out, the code would be correct by the end of it (even before running the tests)

Re: A Rust shaped hole

#125

Post by skybrian »

ashishb wrote: post #12
genshii wrote: post #8

This hits close to home. TypeScript is also my language of choice for 90% of the software I write. I agree with the author that TypeScript is very close to the perfect level of abstraction, and I haven't seen another language with a type system that's nearly as enjoyable to use. Of course, TS (any by extension JS) obviously has its issues/complications. Bun solves a lot of the runtime-related issues/annoyances though…

TypeScript is good as a language. You can't generate static binaries out of it (except Docker images) and that itself is a deal breaker.

You can’t? I haven’t used it, but what’s wrong with “deno compile?”

https://docs.deno.com/runtime/reference/cli/compile/

Re: A Rust shaped hole

#126

Post by adastra22 »

ignoramous wrote: post #84
JoelMcCracken wrote: post #55

Earlier quoted context omitted.

The author really doesn't want to do manual memory management. The table is there to summarize things discussed, but he never says he wants to do manual memory management. I just went back and checked. If you do find something that indicates that, I'd appreciate you pointing it out to me, because idgi

> The table is there to summarize things discussed, but he never says he wants to do manual memory management. But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me. The author wants the compiler to do memory management? How does Rust achieve this?

It is better to think of Rust having explicit memory management, rather than manual memory management. C/C++ has manual memory management: the burden is on you to do it correctly. If you fuck up, your program will have bugs. Rust requires that your code be explicit about memory issues, but the compiler works with you to achieve that. if your code compiles it is correct; if it doesn't compile, the error points out what needs to be fixed. When I write Rust it rarely feels like I am taking on that burden myself.

Re: A Rust shaped hole

#127

Post by anon-3988 »

uecker wrote: post #69
Expurple wrote: post #67

Earlier quoted context omitted.

> A line of code does not depend on a million other things. But it does! To qoute my top-level comment: > What about about race conditions, null pointers indirectly propagated into functions that don't expect null, aliased pointers indirectly propagated into `restrict` functions, and the other non-local UB causes? In other words: you set some pointer to NULL, this is OK in that part of your program, but then the valu…

This is true to some degree, but not really that much in practice. When refactoring you just add assertions for NULL (and the effect of derefencing a NULL in practice is a trap - that it UB in the spec is completely irrelevant. in fact it helps because it allows compilers to turn it a trap without requiring it on weak platforms). Restrict is certainly dangerous, but also rarely used and a clear warning sign, compare…

> This is true to some degree, but not really that much in practice. When refactoring you just add assertions for NULL (and the effect of derefencing a NULL in practice is a trap - that it UB in the spec is completely irrelevant.

This happens a lot in discussion about programming complexity. What you are doing is changing the original problem to a much simpler one.

Consider a parsing function parse(string) -> Option

This is the original problem, "Write a parsing function that may or may not return Object"

What a lot of people do is they sidetrack this problem and solve a much "simpler problem". They instead write parse(string) -> Object

Which "appears" to be simpler but when you probe further, they handwave the "Option" part to just, "well it just crashes and die".

This is the same problem with exceptions, a function "appears" to be simple: parse(string) -> Object but you don't see the myriads of exceptions that will get thrown by the function.

Re: A Rust shaped hole

#128

Post by uecker »

Expurple wrote: post #74
uecker wrote: post #73

Earlier quoted context omitted.

You are not wrong, but also not really right. In practice, I never had a problem with "restrict". And this is my point about Rust being overengineered. While it solves real problems, you need to exaggerate the practical problems in C to justify its complexity.

> In practice, I never had a problem with "restrict". That's exactly because it's too dangerous and the developers quickly learn to avoid it instead of using it where appropriate! Same with multithreading. C leaves a lot of optimization on the table by making the available tools too dangerous and forcing people to avoid them altogether. That's how you get stuff like memory-safe Rust PNG decoders being 1.5x faster tha…

Na, sorry. The "70%" is just nonsense. And cherry picking individual benchmarks too.

Re: A Rust shaped hole

#129

Post by antonvs »

uecker wrote: post #73
Expurple wrote: post #72

Earlier quoted context omitted.

I agree that in practice NULL checking is one of the easier problems. I used it because it's the most obvious and easy to understand. I can't claim which kinds of unsoundness in C code are more common and problematic in practice. But that's not even interesting, given that safe Rust (and other safe languages) solve every kind of unsoundness. > in fact it helps because it allows compilers to turn it a trap without req…

You are not wrong, but also not really right. In practice, I never had a problem with "restrict". And this is my point about Rust being overengineered. While it solves real problems, you need to exaggerate the practical problems in C to justify its complexity.

You're focusing purely on the problem-fixing aspects, but Rust's expressiveness is why I like it.

C can't match that. In C, you're basically acting as a human compiler, writing lots of code that could be generated if you used a more expressive language. Plus, as has been mentioned, it supports refactoring easily and safely better than any language outside of the Haskell/ML space.

The advantages of Rust are a package which includes safety, expressiveness, refactoring support. You don't need to exaggerate anything for that package to make sense.

Re: A Rust shaped hole

#130

Post by uecker »

nemothekid wrote: post #92
uecker wrote: post #69

Earlier quoted context omitted.

This is true to some degree, but not really that much in practice. When refactoring you just add assertions for NULL (and the effect of derefencing a NULL in practice is a trap - that it UB in the spec is completely irrelevant. in fact it helps because it allows compilers to turn it a trap without requiring it on weak platforms). Restrict is certainly dangerous, but also rarely used and a clear warning sign, compare…

> When refactoring you just add assertions for NULL This is a line of thinking I used to see commonly when dynamic typing was all the rage. I think the difference comes from people who view primarily work on projects where they are the sole engineer vs ones where they work n+1 other engineers. "just add assertions" only works if you can also sit on the shoulder of everyone else who is touching the code, otherwise all…

This was about refactoring a code base where a type is assumed to be non-null but it is not obvious. You can express also in C on interfaces that a pointer is non-null.
Post reply on HN