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

151–160 of 319 posts

Re: A Rust shaped hole

#151

Post by rahkiin »

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.

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.

Re: A Rust shaped hole

#152

Post by Expurple »

Sophistifunk wrote: post #139
Expurple wrote: post #116

Earlier quoted context omitted.

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.

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

Re: A Rust shaped hole

#153

Post by staunton »

shmerl wrote: post #143
Expurple wrote: post #137

Earlier quoted context omitted.

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

Well, C has such contest, not every language on the other hand.

I'd guess that's mostly because C has been around long enough to be chosen for it and people who are into that kind of thing don't urgently need more than one contest, regardless of language...

Re: A Rust shaped hole

#154

Post by tialaramex »

saghm wrote: post #147
WD-42 wrote: post #131

Earlier quoted context omitted.

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

Yes, I think it's pretty easy to be sure that this isn't where the complexity comes from when there's literally a method to do that on arrays. I'm not even sure which language you're talking about here, because you can call `.len()` in Rust or `.size()` in C++. If you're trying to remember what the language is where there's no immediately obvious straightforward way to get the length of an array, it's not Rust or C++…

This is a case of exactly the "hoarder" modality in C++ that I described. When somebody says array in C++ you think of std::array, the newer shiny C++ class which you're asked to use instead of the native array types. The native array types in C++ still exist and indeed do not provide methods like size()

In Rust the arrays aren't stunted left over primitive types which weren't gifted modern features, array.len() works because all Rust's types get features like this, not just the latest and greatest stuff.

Re: A Rust shaped hole

#155

Post by lmm »

tayo42 wrote: post #150
lmm wrote: post #94

If they're serious about their criteria they should go with OCaml (or maybe, like, Swift, or any of dozens of languages in that space). (Of course they actually do want Haskell but they probably need to get there gradually)

Does ocaml have a mature ecosystem of libraries and dependencies? And easy way to manage them? Even rust with all its hype lacks in this area imo.

No, and that's part of why I use Scala instead. But this person is looking to make a binary to do a small thing on their desktop and does not list dependency management among their criteria.

Re: A Rust shaped hole

#156

Post by [deleted] »

tayo42 wrote: post #150
lmm wrote: post #94

If they're serious about their criteria they should go with OCaml (or maybe, like, Swift, or any of dozens of languages in that space). (Of course they actually do want Haskell but they probably need to get there gradually)

Does ocaml have a mature ecosystem of libraries and dependencies? And easy way to manage them? Even rust with all its hype lacks in this area imo.

[deleted]

Re: A Rust shaped hole

#157

Post by Expurple »

uecker wrote: post #135
anon-3988 wrote: post #127

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

> in the end, you can write Option just fine it C.

No, you can't. In the sense that the compiler doesn't have exhaustiveness checks and can't stop you from accessing the wrong variant of a union. An Option in C would be the same as manually written documentation that doesn't guarantee anything.

std::optional in C++ is the same too. Used operator* or operator-> on a null value? Too bad, instant UB for you. It's laughably bad, given that C++ has tools to express tagged unions in a more reliable way.

> And then, also Rust can not express everything in the type system. (And finally, there are things C can express but Rust can't).

That's true, but nobody claims otherwise. It's just that, in practice, checked tagged unions are a single simple feature that allows you to express most things that you care about. There's no excuse for not having those in a modern language.

And part of the problem is that tagged unions are very hard to retrofit into legacy languages that have null, exceptions, uninitialized memory, and so on. And wouldn't provide the full benefit even if they could be retrofitted without changing these things.

Re: A Rust shaped hole

#158

Post by anon-3988 »

uecker wrote: post #135
anon-3988 wrote: post #127

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

Yes, all I am saying is that we have to be honest what level of problems we are solving when we encounter a complicated solution.

The solution have to scale linearly with the problem at hand, that is what it means to have a good solution.

I agree with the article that Rust is overkill for most use cases. For most projects, just use a GC and be done with it.

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

This can be taken as a feature. For example, is there a good reason this is representable?

struct S s = 10;

I LOVE the fact that Rust does not let me get away with half-ass things. Of course, this is just a preference. Half of my coding time is writing one-off Python scripts for analysis and data processing, I would not want to write those in Rust.

> But in the end, you can write Option just fine it C.

Even this question have a deeper question underneath it. What do you mean by "just fine"? Because to me, tagged enums or NULL is NOT the same thing as algebraic data types.

This is like saying floating points are just fine for me for integer calculations. Maybe, maybe for you its fine to use floating points to calculate pointers, but for others it is not.

Re: A Rust shaped hole

#159

Post by rapsey »

_mlbt wrote: post #35
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…

Swift is a great C++ and Rust alternative that doesn’t get enough attention outside of Apple platforms. It’s a performant, statically typed, compiled language that feels almost like a scripting language to write code in. It’s memory safe, cross platform, has a fantastic standard library, and has excellent concurrency capabilities. Even the non-Xcode tooling is maturing rapidly. The big weak spot really is lack of com…

Swift has IMO surpassed Rust in complexity. Rust changes very little but Swift has gone through multiple major changes and is accumulating cruft.

Re: A Rust shaped hole

#160

Post by staunton »

uecker wrote: post #130
nemothekid wrote: post #92

Earlier quoted context omitted.

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

> interfaces

You mean obsolete and subtly wrong comments buried among preprocessor directives in some far-upstream header files?

Post reply on HN