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

591–600 of 736 posts

Re: Was Rust Worth It?

#591

Post by mike_hearn »

HKH2 wrote: post #157
throwaway914 wrote: post #7

I feel like Rust finally broke the idea that programmers should be in complete control and completely conscious of everything the compiler is doing. It hasn't been that way in decades, compilers are freaking magic. But Rust undid a lot of that with borrowing. People became comfortable with the compiler knowing better than them. I just wish we could relax further: We should never be explicitly iterating forward over a…

> Give me rusty bash. Bash with types (especially floats), fewer edge cases, functions with explicit parameters, simple command line flags...

We use a Kotlin scripting variant for our own shell scripting needs at Hydraulic, it's pretty nice because we've joined it with a lot of internal APIs that make working with the filing system and network easy. It fits all those requirements and more (you can declare flags easily at the top level, it has built in progress tracking for slow operations etc).

The Kotlin type system is comparable to Rust without the borrow checker. It has non-null types, generics, etc.

It's not really a "product" per se but there's an old version for download and some lightweight docs here:

https://hshell.hydraulic.dev/

We've never worked out what to do with it. Ideas and feedback welcome. It's pretty nice to use, albeit you need to use IntelliJ to edit scripts if you want IDE features.

Re: Was Rust Worth It?

#592

Post by benibela »

maxbond wrote: post #124
Sharlin wrote: post #93

Earlier quoted context omitted.

A null pointer exception is a bug that breaks business logic. There's no "business logic instead of language stuff" because the language stuff is the foundation that business logic rests on. If you don't test against failure modes, what's even the point in testing?

To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.

Still someone might call unwrap on an Option and then run into some kind of null pointer exception

Re: Was Rust Worth It?

#593

Post by goku12 »

mst wrote: post #576
caskstrength wrote: post #489

Earlier quoted context omitted.

> 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 make sense and you will know how to resolve them. I have reasonable understanding of "what happens on the hardware" (been writing kernel code for years), know mode…

I get the feeling that learning rust can be a "bang your head against it until you get an 'aha' moment" sort of affair, much like learning git. Some people pick up rust quickly because it clicks into their brain early, some take longer or end up bouncing off.

I had university courses on computer architecture and assembly, even before I took up Python as a hobby. I did have a little C experience before that. My entire perspective on Rust type system from day 1 (back in 2013, before Rust 1.0) was based on the hardware (primarily stack frames) and problems I had with assembly and C. There was never a point where the borrow checker didn't make sense. This is why I insist that Rust isn't hard to understand if you learn the hardware on which it runs.

Back then, people were debating the design decisions that led to the borrow checker, in public for everyone to see (on Reddit and IRC). They were trying to avoid memory safety issues in Firefox and Servo. They were even a bit surprised to discover that the borrow checker solved many concurrency bugs as well.

Re: Was Rust Worth It?

#594

Post by flohofwoe »

ParetoOptimal wrote: post #574
flohofwoe wrote: post #512

Earlier quoted context omitted.

I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff, especially for scenarios where C is useful. We need many more Rust alternatives that explore into different directions, Rust is already too big and "established" for any radical changes in direction.

> I think nobody is arguing the need for static memory safety, just that the poor Rust ergonomics aren't a good tradeoff Unless the "poor ergonomics" and lack of shortcuts are explicitly what provides the static memory safety.

IMHO Rust's ergonomics problems aren't caused by the borrow checker itself, but have the same cause as similar problems in C++ (mainly a "design by committee" approach to language design and implementing features that should be language syntax sugar in the stdlib instead, which then directly results in the stdlib being too entangled with the language and "too noisy" hard to read code).

Apart from the static memory safety USP, Rust is repeating too many problems of C++ for my taste, and at a much faster pace.

Re: Was Rust Worth It?

#596

Post by estebank »

rcxdude wrote: post #412
rat87 wrote: post #345

Earlier quoted context omitted.

What are the benefits?

mainly, you can trust that anything under the foo/ namespace is controlled by only a smaller group of people, as opposed to the current situation on cargo where people pseudo-namespace by making a bunch of packages called foo-bar, foo-baz, and you can't trust that foo-bin wasn't just inserted by someone else attempting to appear to be part of the foo project. It also helps substantially with naming collisions, especi…

If you want to check your dependency tree for the number of maintainers you're dealing with instead of the number of dependencies, this can be done with cargo tree + checking the Cargo.toml/crates.io ownership info for each of the found packages. I don't know if there's a command written to do that already, but I've done that with a small script in the past.

Re: Was Rust Worth It?

#597

Post by robertlagrant »

goku12 wrote: post #585
robertlagrant wrote: post #564

Earlier quoted context omitted.

> For larger programs in Python, you need an upfront design stage because the lack of static typing will allow you to organically accrete classes whose job overlap but interfaces differ. You can also install pre-commit and mypy, and have static typing.

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 generally garbage collected rather than explicitly destroyed, so I don't think it'd make sense to have lifetimes? They don't seem a correctness thing in the same way that types do.

Re: Was Rust Worth It?

#598

Post by PartiallyTyped »

mst wrote: post #576
caskstrength wrote: post #489

Earlier quoted context omitted.

> 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 make sense and you will know how to resolve them. I have reasonable understanding of "what happens on the hardware" (been writing kernel code for years), know mode…

I get the feeling that learning rust can be a "bang your head against it until you get an 'aha' moment" sort of affair, much like learning git. Some people pick up rust quickly because it clicks into their brain early, some take longer or end up bouncing off.

I took a different route to Goku (other commenter), I used to write a lot of C and C++ in university, did everything there, up until 2018-ish, I got a bit into rust and things just clicked, my understanding of memory was just not that good enough, and then my C skills skyrocketed as a consequence of learning proper memory management.

Then I got into Haskell, and functional programming, that made thinking about traits, immutability, and all functional aspects a breeze.

Then finally, I got into rust again, use it at work and personal projects. Somehow I managed to rewrite a project that took me 4 months in Python in about 4 days. It was faster, more robust, cleaner, and I could sleep at night.

Re: Was Rust Worth It?

#599

Post by GoblinSlayer »

Buttons840 wrote: post #519
pjmlp wrote: post #513

Earlier quoted context omitted.

It is, however those same companies aren't dialing full safe ahead knob either, hence why Microsoft just recently published a set of secure coding guidelines for C and C++. https://devblogs.microsoft.com/cppblog/build-reliable-and-se...

Does it have tooling to enforce those guidelines? If not, how is it better than someone saying "write correct code" and calling it a guideline?

Following a guideline that checks correctness for you is easier than following "write correct code".

Re: Was Rust Worth It?

#600

Post by ilaksh »

FridgeSeal wrote: post #529
ilaksh wrote: post #176

Earlier quoted context omitted.

1. Not applicable unless it is absolutely required, and not something I will consider until I have exhausted other options, since there is a reason they have not made it Send already. It will likely be quite complex and enlarge the scope. 2. I am using a normal thread but when I make it async the compiler wants Send. 3. The await point is in code that uses the engine. I am not sure there is another good option, since…

> 2. I am using a normal thread but when I make it async the compiler wants Send. This is likely because you are using the multi-threaded scheduler, which requires futures to be Send, even if you’re running only a single thread. This is because Tokio is based on a “work stealing” runtime, so in “normal” operations, expects the futures themselves to be able to be shuffled around threads where necessary. For you use ca…

Right, GPT-4 explained that much about shuffling. I am trying to do all the interaction with MPSC channels but was still running into issues.

I think I have a lot of good advice to go try now. Thanks.

Post reply on HN