Live data from Hacker News

Why is Rust difficult?

vorner.github.io

61–70 of 260 posts

Re: Why is Rust difficult?

#61
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I would normally define 'correctness' to include rigorous mathematical proofs.

Do you have an example of a language that does what you're looking for?

On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different.

> Go works wonderfully

Go does work wonderfully, you should definitely use what you like. For me personally, though, Go never excited me. Rust on the other hand continues to be exciting, I always feel like I'm learning something new (and I've been using it for the past 3 years).

> For example, you could always just clone memory at every occasion, return the input instead of borrowing, etc. In fact, these things might be easier for a beginner to do.

I think most Rust beginners (I know it was true of me anyway) do often just clone everywhere. Eventually, you then replace that with Rc or Arc... And then one day you decide you want the fastest thing on the block, and now you know the in's and out's of Rust, so you decide to up the ante and put lifetimes on everything.

I recommend this pattern to all Rust beginners.

Re: Why is Rust difficult?

#62
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics.

Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks:

* It makes it harder and much less convenient to call libraries in this language from other languages.

* Low-resource embedded systems are a no-go.

* GC is typically a tradeoff between speed and memory usage. Manual memory management can be very fast and very lean.

Re: Why is Rust difficult?

#63
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I would normally define 'correctness' to include rigorous mathematical proofs. Do you have an example of a language that does what you're looking for? On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. > Go works wonderfully Go does work wonderfully, you should definitely use what you like. For me personally, though,…

I think they mean something like what proof assistants like Cog and Irdis do. ATS is another language that enables proofs, and it's more geared to the systems programming use case, as it's similar to C.

Note that unit tests prove only that the code works for those inputs and those code paths tested. Mathematical proofs are supposed to be exhaustive.

Re: Why is Rust difficult?

#64
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I would normally define 'correctness' to include rigorous mathematical proofs. Do you have an example of a language that does what you're looking for? On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. > Go works wonderfully Go does work wonderfully, you should definitely use what you like. For me personally, though,…

> Do you have an example of a language that does what you're looking for?

Dependently typed programming languages such as Coq and Idris let you write proofs about your programs. These languages are fairly academic, and most engineers probably won't find it worthwhile to use these tools. Personally, I love them. I wrote a short article about my experience with Coq: https://www.stephanboyer.com/post/134/my-unusual-hobby

Re: Why is Rust difficult?

#65
post #60

I do think a lot of the difficulty when starting Rust was all about it forcing you to do everything correctly, even when the 'correctness' wasn't needed for how the program was currently being used. However, my experience learning Rust was that it was pretty easy to work through these things because of how precise the compiler is at describing the issue. I feel like the compiler was my teacher, and it kept on teachin…

> I feel like the compiler was my teacher, and it kept on teaching me new concepts to look up in the docs. I work primarily in F#, a functional .Net language, which also enforces strict rules at compile time to ensure correctness... With the benefit of experience it's amazing and comforting and lets you reason happily about applications at a higher level. It's on of my favorite parts of the language, TBH. And while I…

F# is nice, if only Microsoft would actually provide feature parity with C#, VB.NET and C++ tools.

I bet C# will sooner copy F# features than Blend, GUI designers or .NET Native will support F#.

Re: Why is Rust difficult?

#66
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I would normally define 'correctness' to include rigorous mathematical proofs. Do you have an example of a language that does what you're looking for? On the proof side, Rust's built in unit testing is great, and allows for quick validation of code (proofs). But I think you mean something different. > Go works wonderfully Go does work wonderfully, you should definitely use what you like. For me personally, though,…

You'd have to look at niche languages like Coq, Idris, or Agda if you want mathematical proofs. There's a lot of research that needs to be done before proven programs can become the norm.

Re: Why is Rust difficult?

#67
post #62
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

> Low-resource embedded systems are a no-go.

Only if talking about microcontrolers with few hundred KB, where even C is a challenge.

There are Java and Oberon implementations for single digit MB, like Cortex-M4.

Re: Why is Rust difficult?

#68
post #51
post #10

Earlier quoted context omitted.

"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's really not hard to get code past the borrow checker anymore. Maybe every thousand lines or so you'll need to add a block or pull a temporary variable out of a one-liner, but the compiler basically tells you exactly what to do when something like that is releva…

Try to use the borrow checker of this decade to write callbacks in GUI frameworks, without polluting the code with Rc and RefCell, even though it is obvious there is only one path to the data being used.

Callbacks by definition create multiple paths to the data.

(You can also often get away with Cell rather than RefCell.)

Re: Why is Rust difficult?

#69
post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

Regarding your first point, I have never seen anyone on the Rust side of things claim that Rust can solve most correctness bugs. The attitude has always been to take things one step at a time, and to slowly strengthen the type system to make it expressive enough to write more statically enforceable constraints.

Re: Why is Rust difficult?

#70
post #67
post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

Even the ESP8266, where ram & flash are measured in kilobytes can run a minimal version of python. This whole "low resource can't run heavy languages" trope needs to die.
Post reply on HN