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

131–140 of 319 posts

Re: A Rust shaped hole

#131

Post by WD-42 »

rich_sasha wrote: post #57
tialaramex wrote: post #46

Earlier quoted context omitted.

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++'s complexity is coming from how eager it is to let you shoot yourself in the foot. Rust will make you sweat blood to prove the bird in the sky you're shooting at is really not your own foot.

You sure it doesn’t come from, for example, needing a macro just to get the length of an array?

Re: A Rust shaped hole

#132

Post by uecker »

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…

No, I wrote that Rust is too complex. And I responded to a comment that claims that C is hard to refactor, and this does not match my experience.

Re: A Rust shaped hole

#133

Post by uecker »

antonvs wrote: post #129
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.

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…

I am not criticizing anyone for preferring Rust. I reject the idea that its complexity needs to imposed on everybody because of "safety"

Re: A Rust shaped hole

#134

Post by outside1234 »

Rust is an amazing language once you get over the initial mental hurdle. An important thing to go in with: 99% of programs should not require you to manage lifetimes (‘a notation) If you find yourself doing this and aren’t writing a inner loop high performance library, back up and find another way. Usually this entails using a Mutex or Arc (or other alternatives based on the scenario) to provide interior mutability or multiple references. This statement might not make sense now but write it down for when it will.

I use Rust now for everything from CLIs to APIs and feel more productive in it end to end than python even.

Re: A Rust shaped hole

#135

Post by uecker »

anon-3988 wrote: post #127
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…

> 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…

I guess it depends on what the problem is. If the problem is being productive and being able to program without pain "changing the original problem to a much simpler one" is a very good thing. And "crash and die" can be a completely acceptable way to deal with it. Rust's "let it panic" is not at all different in this respect.

But in the end, you can write Option just fine it C. I agree though that C sometimes can not express things perfectly in the type system. But I do not agree that this is crucial for solving these problems. And then, also Rust can not express everything in the type system. (And finally, there are things C can express but Rust can't).

Re: A Rust shaped hole

#136

Post by fn-mote »

bryanlarsen wrote: post #86
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…

Reading between the lines, the author is a Haskell fan. Haskell is another "complicated" language, but the complexity feels much different than the C++ complexity. Perhaps I would describe it as "complexity that improves expressiveness". If you like Haskell for its expressiveness but dislike C++ for it's complexity, I suspect Rust is a language you're going to like.

My impression was the opposite. I wondered how well the author knew Haskell. They mention:

(1) The "intimidating syntax". Hey, you do not even need to be using never mind the rest of those operators. Perl and Haskell can be baroque, but stay away from that part of the language until it is useful.

(2) "Changes are not localized". I'm not sure what this means. Haskell's use of functions is very similar to other languages. I would instead suggest referring to the difficulty of predicting the (time|space) complexity due to the default lazy evaluation.

FTA:

> In contrast, Haskell is not a simple language. The non-simplicity is at play both in the language itself, as evidenced by its intimidating syntax, but also in the source code artifacts written in it. Changes are not localized, the entire Haskell program is one whole — a giant equation that will spit out the answer you want, unlike a C program which is asked to plod there step by step.

Edited to make the critique more objective.

Re: A Rust shaped hole

#137

Post by Expurple »

shmerl wrote: post #115
Expurple wrote: post #41

> If someone posts a patch or submits a PR to a codebase written in C, it is easier to review than any other mainstream language. There is no spooky at a distance. [..] Changes are local. Lol, wut? 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? Sadly, C's e…

Yeah, and C can get unreadable fast. Obfuscated C contest is a great example: https://www.ioccc.org But that doesn't mean it's a good idea to use such style for PRs, lol.

That's a really weird example to give. You can write unreadable code in any language if you're determined enough

Re: A Rust shaped hole

#138

Post by peppingdore »

shmerl wrote: post #115
Expurple wrote: post #41

> If someone posts a patch or submits a PR to a codebase written in C, it is easier to review than any other mainstream language. There is no spooky at a distance. [..] Changes are local. Lol, wut? 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? Sadly, C's e…

Yeah, and C can get unreadable fast. Obfuscated C contest is a great example: https://www.ioccc.org But that doesn't mean it's a good idea to use such style for PRs, lol.

Rust is unreadable by default

Re: A Rust shaped hole

#139

Post by Sophistifunk »

Expurple wrote: post #116
Sophistifunk wrote: post #106

Sounds like a Zig-shaped hole to me ;-)

They complain that Go is too low-level for their needs. Zig, with its explicit allocators, is definitely even lower-level. Rust seems low-level too, but it isn't the same. It allows building powerful high-level interfaces that hide the complexity from you. E.g., RAII eliminates the need for explicit `defer` that can be forgotten

True, but I think the "low-level" complaint against Go in the article was just referring to all the stupid repetitive ceremony required for error handling, which Zig mostly skips over.

Re: A Rust shaped hole

#140

Post by uecker »

rstuart4133 wrote: post #76
uecker wrote: post #64

Earlier quoted context omitted.

I am wondering about this. In C the nice thing is that you usually change things locally. A line of code does not depend on a million other things. I can't quite see how this works in Rust... At least in C++, template, overloading, etc. can make a single line depend on a lot of things.

> I can't quite see how this works in Rust... You won't understand it unless refactor some Rust programs. Bunny summed it up rather well. He said in most languages, when pull on some thread, you end disappearing into a knot and you're changes are just creating a bigger knot. In Rust, when pull on a thread, the language tells you where it leads. Creating a bigger knot generally leads to compile errors. Actually he did…

I only have limited experience with Rust (only playing around a bit). But it seems the language forces you to structure the code in a specific way (and you seem to agree). This is good, because it prevents you from making a mess (at some level at least). But what others report (and it matches my limited experience) is that it makes the structure of the code very rigid. So I do not quite see how this does not limit refactoring? What some of you describe in this thread is type-directed refactoring (i.e. you change a type and the compiler tells what you need to change), but is this not limited to relatively basic changes?

In C, you can make partial changes and accept a temporary inconsistency. This gives you a lot of flexibility that I find helpful.

Post reply on HN