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

161–170 of 319 posts

Re: A Rust shaped hole

#161

Post by lelanthran »

rahkiin wrote: post #151
whytevuhuni wrote: post #144

Earlier quoted context omitted.

If anything I'd like an even lower-level Rust. There's so many good high-level languages to choose from, but when you need to go low-level, there's essentially only C, C++, Rust. Maybe Zig once it reaches 1.0. What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns.

It would be an interesting excercise just to see how such a language would look. Would modules be needed or can preprocessing work still. How more advanced will the type system need to be. And how will pointers chanhe to fix all footguns and allow static borrow checking.

> It would be an interesting excercise just to see how such a language would look.

I started designing one (C-with-borrow-checker) way back in 2018; never got around to finishing the design or making a MVP, but I believe you can solve maybe 90% of memory problems (use after free/double free, data racing, leaking, etc) with nothing more than some additional syntax[1] to type declarations and support for only fat arrays.

IIRC, I thought that the above (coupled with an escape hatch for self-referential and/or unsafe values) was all that was needed to prevent 90% of memory errors.

Somewhere along the way scope-creep (objects would be nice, can't leave out generics, operator overloads necessary for expressing vector math, etc) turned what would have been a small project into a very large one.

-------------------------------

[1] By additional syntax, I mean using `&` and `&&` in type declarations as a qualifier similar to how `static`, `const`, `volatile`, etc qualifiers are used.

Re: A Rust shaped hole

#162

Post by Expurple »

whytevuhuni wrote: post #144
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…

If anything I'd like an even lower-level Rust. There's so many good high-level languages to choose from, but when you need to go low-level, there's essentially only C, C++, Rust. Maybe Zig once it reaches 1.0. What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns.

> There's so many good high-level languages to choose from

We have many popular high-level languages, but I disagree that they are good. Most of them are fragile piles of crap unsuitable for writing anything larger than a throwaway script.

(In my subjective and biased assessment, which is hovewer based on professional experience)

Re: A Rust shaped hole

#163

Post by tialaramex »

jcranmer wrote: post #118
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…

Having developed a fair amount of expertise with both C++ and Rust, C++ is on a completely different level of complexity from Rust. In Rust, for most users, the main source of complexity is struggling with the borrow checker, especially because you're likely to go through a phase where you're yelling at the borrow checker for complaining that your code violates lifetime rules when it clearly doesn't (only to work it…

The C++ 11 move semantic is definitely an example of C++ programmers being sold a "pig in a poke"† The claim in the proposal document was that although this isn't the "destructive move" which programmers wanted (and which Rust had by 2015), the C++ 11 move feature can be realised with less disruption and is just as good. In reality it left significant performance on the table and you can't get it back without significant further language change.

† This phrase would have been idiomatic many years ago but it is still used with the same intent today even though its meaning is no longer obvious, the idea is that a farmer at market told you this sack you can't see inside ("poke") has a piglet in it, so you purchase the item for a good price, but it turns out there was only a kitten in the bag, which (compared to the piglet) is worthless.

Re: A Rust shaped hole

#164

Post by Expurple »

uecker wrote: post #140
rstuart4133 wrote: post #76

Earlier quoted context omitted.

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

I'll put it like this. Rust causes you to refactor more often and do a full refactoring at once (because the interfaces are so rigid), but it makes it easy to do a full (and correct) refactoring very quickly. Think of it as docs being part of the interface and the compiler forcing you to always update the docs. That's an amazing property

Re: A Rust shaped hole

#165

Post by sgt »

Expurple wrote: post #152
Sophistifunk wrote: post #139

Earlier quoted context omitted.

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.

Fair enough. That's what they seem to be saying. But then I want to chime in and argue that the repetitive syntax isn't even close to being the main problem with Go: https://home.expurple.me/posts/go-did-not-get-error-handling...

So, while on that subject; does Zig get error handling right?

Re: A Rust shaped hole

#166

Post by thasso »

A nice thing about C is that you can be pretty confident that you know all major footguns (assuming you spent some time reading about it). With languages that are young or complex there is a much greater chance you’re making a terrible mistake because you’re not aware of it.

Re: A Rust shaped hole

#167

Post by timeon »

Symmetry wrote: post #25
blashyrk wrote: post #2

Someone really needs to show Nim to the author :). It checks all of their boxes and then some

I was thinking that too. There are many cases where you do want to manage memory yourself, and in that case you should likely use Rust or maybe Zig if you can choose your own tool. But if you don't want to manage your own memory Nim works nicely, though IMO it requires adherence to a style guide more than most languages.

Depends what you do but most of the time you do not need to do anything special about memory management in Rust. That is why people try to use it for other things then just system programming.

Re: A Rust shaped hole

#168

Post by Expurple »

sgt wrote: post #165
Expurple wrote: post #152

Earlier quoted context omitted.

Fair enough. That's what they seem to be saying. But then I want to chime in and argue that the repetitive syntax isn't even close to being the main problem with Go: https://home.expurple.me/posts/go-did-not-get-error-handling...

So, while on that subject; does Zig get error handling right?

Idk, I'm not familiar enough with Zig to say

Re: A Rust shaped hole

#169

Post by deathanatos »

slowcache wrote: post #15

Odin has been really growing on me lately as a language that checks all of those boxes. String types, first class allocators, built in tests, a batteries included philosophy, and ease of use are some of the things that really drew me towards it. I really wanted to like rust and I wrote a few different small toy projects in it. At some point knowledge of the language becomes a blocker rather than knowledge the problem…

> String types

It's a byte string.

> rune is the set of all Unicode code points.

We copied the awful name from Go … and the docs are wrong.

Five different boolean types?

Zero values. (Every value has some default value, like in Go.)

Odin also includes the Billion Dollar Mistake.

> There seemed to be an anti-DIY approach in the community that finally drew me away.

It's a "let a thousand flowers bloom" approach, at least until the community knows which design stands a good chance of not being a regretted addition to the standard library.

Re: A Rust shaped hole

#170

Post by BiteCode_dev »

amluto wrote: post #146
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…

Even ignoring undefined behavior and nulls, everything in C is mutable. Action at a distance is basically the norm.

And global states.

I remember the first time I was using gettext and wonder "wait, why do I have to switch the language for my whole program if I need it for just this request?" and realized that's because GNU gettext was made like that.

Post reply on HN