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

Was Rust Worth It?

jsoverson.medium.com

Post reply on HN
Print view View original

721–730 of 736 posts

Re: Was Rust Worth It?

#721

Post by littlestymaar »

lumost wrote: post #715
littlestymaar wrote: post #409

Earlier quoted context omitted.

> is there not an intended replacement for these data structures? Or do they expect it all to go under Unsafe? For linked-lists, there's one in std and the majority of people should never have to write their own as it's error prone and requires unsafe. For graph use-case then you can either use ECS, arena, ref counting or unsafe, but you're probably better off using/developing a dedicated crate that optimizes it and…

The one in std uses unsafe. My main concern with learning rust is that you can spend ages trying to learn “the right way” of doing things in rust, when the right way really is to use unsafe.

No, the right way is to use unsafe primitives that have been tested, audited or even formally proven (like the ones in std).

Sometimes such a primitive doesn't exist and you should use unsafe yourself, but then you're the one supposed to make sure that your code is in fact sound. If you keep unsafe for small portions of the code you can reason about and extensively test so Miri gives you a good level of confidence, then it's fine to use unsafe. But it's the more expensive option, not the default.

Re: Was Rust Worth It?

#722

Post by littlestymaar »

richbell wrote: post #655
carols10cents wrote: post #631

Earlier quoted context omitted.

Namespaces can't be typosquatted?

I don't believe I said that. The point is that it's much easier to make a mistake typing "requests" than " org.kennethreitz:requests" (as a pure hypothetical.) It also means that more than one project can have a module called "utils" or "common", which once again reduces the risk of people accidentally downloading the wrong thing.

> The point is that it's much easier to make a mistake typing "requests" than " org.kennethreitz:requests" (as a pure hypothetical.)

Sorry what? It's strictly the opposite: more character to type equals more risks to make a mistake.

In fact, in the general case, namespace increase the risk of supply chain attacks, because it makes packages names even less discernable.

Re: Was Rust Worth It?

#724

Post by underdeserver »

lumost wrote: post #713
underdeserver wrote: post #558

Earlier quoted context omitted.

I don't write Rust, but I never understood why graphs meant you need circular references. Doesn't it just come down to the question of who owns the node? If it's a tree, and parents are never removed before children, just make the child owned by the parent and keep a weak reference to the parent. If it's a general graph, and vertices can exist or not exist regardless of edges, keep a list of them independent of the e…

Things get tricky when you have a valid triangular relationship amongst equal objects. This comes up far more often than you’d expect.

Can you give an example?

Re: Was Rust Worth It?

#725

Post by subarctic »

cmrdporcupine wrote: post #306
jandrewrogers wrote: post #172

Earlier quoted context omitted.

I don't think it is unusually difficult to find Rust programmers. The challenge is finding Rust programmers who also have expertise in systems software development. Rust was designed to be a systems language but ironically it primarily seems to attract developers that do not have expertise in systems software. This isn't necessarily a problem. C++ and Rust can coexist pretty well in practice, and Rust is a good entry…

Sadly I have found the flip side, too: as someone with a systems software interest/background (I wouldn't say expert), the # of jobs in the Rust ecosystem that are not glorified webdev/microservicing (or worse, crypto) is actually quite small. So I guess I wouldn't be surprised that the applications are trending that way, too, as that is where growth is happening right now it seems.

That's the flip side of the same coin as your parent comment, I guess - because Rust is more accessible than C or C++, a lot of people have started using it for stuff that's not hardcore systems software, and as a result it's not as good a filter for that stuff as C and C++ are.

On the other hand, we use Rust on the backend of our web based saas product, and it serves as a great filter for quality developers for us.

Re: Was Rust Worth It?

#726

Post by oneshtein »

hgs3 wrote: post #657
oneshtein wrote: post #636

Earlier quoted context omitted.

Can you give us examples, please? I use Rust since version 1.0, and I like it a lot.

Cyclic data structures are impossible to represent in safe Rust because there is no clear "owner" in a cyclic data structure.

Cyclic structures can be flattened into a vector or an arena, or unsafe Rust can be used.

Re: Was Rust Worth It?

#727

Post by lmm »

tialaramex wrote: post #692
lmm wrote: post #669

Earlier quoted context omitted.

Can you give a more concrete example of the kind of thing you're talking about? Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runtime if you did in fact violate the semantic constraint, and any sane implementor wo…

> Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? It's not merely about whether your comparisons are transitive, the type must exhibit a total ordering or your sort may do anything, including buffer overflow. > Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runt…

> the type must exhibit a total ordering or your sort may do anything, including buffer overflow.

Sure. But there's no requirement for the compiler to be a dick about it, and hopefully most won't.

> I don't think I know how to prove it, but I'm pretty sure it's going to be Undecidable at runtime too in many of these cases. Rice reduced these problems to Halting, which I'd guess means you end up potentially at runtime trying to decide if some arbitrary piece of code will halt eventually, and yeah, that's not helpful.

At runtime can't you just run the code and let it halt or not? Having your program go into an infinite loop because the thing you implemented didn't meet the requirements is not unreasonable.

I'm sympathetic to the idea that there could be a problem in this space, but without a real example of a case where it's hard for a compiler to do something reasonable I'm not convinced.

> I've written about it before, but I should spell it out: The only working alternative is to reject programs when we aren't sure they meet our constraints. This means sometimes we reject a program that actually does meet the constraints but the compiler couldn't see it.

> I believe this route is superior because the incentive becomes to make that "Should work but doesn't" set smaller so as to avoid annoying programmers, whereas the C++ incentive is to make the "Compiles but doesn't work" set larger since, hey, it compiles, and I see Rust's Non-Lexical Lifetimes and Polonius as evidence for this on one side, with C++ 20 Concepts and the growing number of IFNDR mentions in the ISO standard on the other side.

Meh. I'm no fan of the C++ approach, but I'd still rather see C++ follow through on its strategy than half-assing it and becoming a watered-down copy of Rust. People who want Rust know where to find it.

Re: Was Rust Worth It?

#728

Post by mcronce »

goku12 wrote: post #416
PartiallyTyped wrote: post #359

Earlier quoted context omitted.

Surprisingly, I am faster in Rust than any other language. Something about my prior experiences just made it click just the right way. I don't want to program in anything else anymore. I don't want to deal with obscure C++ error messages, C footguns and lack of ergonomics, I don't want to deal with abstraction hell of Java, or the poor person's typing that python has. I have been programming in Python for the past 6…

> Surprisingly, I am faster in Rust than any other language. Not really surprising, given that you have C and C++ background. That's what I was trying to highlight. Rust isn't a confusing or unproductive language as many project it to be - if you have the conceptual understanding of what happens on the hardware. Especially about stack frames and RAII. If you know those, the borrow checker complaints will immediately…

My background is PHP, Python, and Go, and I have the same experience as GP

Re: Was Rust Worth It?

#729

Post by tialaramex »

lmm wrote: post #727
tialaramex wrote: post #692

Earlier quoted context omitted.

> Like, if you try to sort something and your comparator implementation for that type is not transitive, the compiler can silently produce a broken binary? It's not merely about whether your comparisons are transitive, the type must exhibit a total ordering or your sort may do anything, including buffer overflow. > Surely in the undecidable cases the compiler is allowed to produce a binary that errors cleanly at runt…

> the type must exhibit a total ordering or your sort may do anything, including buffer overflow. Sure. But there's no requirement for the compiler to be a dick about it, and hopefully most won't. > I don't think I know how to prove it, but I'm pretty sure it's going to be Undecidable at runtime too in many of these cases. Rice reduced these problems to Halting, which I'd guess means you end up potentially at runtime…

Historically correctness wasn't seen as an important goal in C++ and so no, I don't think any of the three popular C++ stdlib implementations will do something vaguely reasonable for nonsense sort input. It's potentially faster (though bad for correctness) to just trust that this case can't happen since the programmer was required to use types with total ordering. So yes, I'd expect it to result in bounds misses in real software.

Re: Was Rust Worth It?

#730

Post by mcronce »

robertlagrant wrote: post #597
goku12 wrote: post #585

Earlier quoted context omitted.

That's the entire point we're making. Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python.

> Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. Definitely not - mypy's pretty good these days, and lots of people use it. > But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python. Well, Python's objects are gen…

Mutability is a big one for correctness. In Python, any function you pass any (non-primitive) object to might be mutated right out from under you and you have no idea it's happening. In Rust, you have to explicitly provide mutable references, or you need to hand over ownership, in which case you don't care if the callee mutates its argument, because you no longer have access to it.
Post reply on HN