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

Why is Rust difficult?

vorner.github.io

Post reply on HN
Print view View original

81–90 of 260 posts

Re: Why is Rust difficult?

#81

Post by singularity2001 »

(for newcomers) nothing works out of the box or as expected

program[0]="+"; | ^^^^^^^^^^ the type `str` cannot be mutably indexed by `{integer}` error: use of unstable library feature 'collections': needs investigation to see if to_string() can match perf

error: borrowed value does not live long enough reference must be valid for the block suffix following statement 0 When you use an index operator ([]) you get the actual object at index location. You do not get a reference, pointer or copy. cannot move out of indexed content

Re: Why is Rust difficult?

#82

Post by vlovich123 »

jchw wrote: 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…

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web browser in Go, but you would (& Mozilla is) in Rust.

In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security. This "limited" class of bugs is responsible for quite a large number of runtime issues & they can be frustratingly difficult to find/fix (+ be confident that you did actually fix it). It's hard to say how much better things will play out in real-world software development as at some fundamental point there are always unsafe calls which weakens the guarantees Rust can make (but does put an explicit boundary on where you should go looking for bugs).

As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. What Rust does do extremely well is that the errors are very clearly explained in the terminal (with an error code that has pretty good online documentation), but also gives you hints on simple ways to potentially alter the code to fix it. As a beginner, I've found it way quicker to fix those bugs (even within macros) than the compiler issues I encountered learning C++ - granted back then compilers were a lot worse on that front, but even these days with C++ I've struggled fighting the compiler/preprocessor.

Also, the Rust compiler appears pretty vibrant with lots of improvements being made to help with user friendliness, so it's possible that further improvements in inference might reduce the problem spots (it's already pretty magic to me).

I've started learning Rust a few weeks ago & those are my impressions so far.

Re: Why is Rust difficult?

#83

Post by Joool »

bluejekyll wrote: post #61
jchw wrote: 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,…

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

Unit testing can only proof one instance of the input domain, e.g. the function square() returns 4 under the input 2. Languages like Coq allow you to proof that the function square returns the squared input for every possible input.

Re: Why is Rust difficult?

#84

Post by flohofwoe »

pjmlp wrote: post #78
blattimwind wrote: post #75

Earlier quoted context omitted.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge. C is the default and not a challenge on 8-bitters.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/

Re: Why is Rust difficult?

#85

Post by dullgiulio »

josephg wrote: post #76
jchw wrote: 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…

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully. I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to…

I do hope it's not true that people from the community would attack you for writing a compile-to-go language.

I don't think it's such a bad idea, considering how stable the language itself is, it's a pretty solid bet.

Re: Why is Rust difficult?

#86

Post by majewsky »

turbinerneiter wrote: post #80
StudentStuff wrote: post #70

Earlier quoted context omitted.

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.

Comparison of a sensor fusion algorithm the likes of which are used in quadcopters: | impl | c | py3 | mpy | pypy3 | cy3 | |------|-------|--------|---------|-------|-------| | [ns] | 0.176 | 11.462 | 37.633 | 0.818 | 0.590 | | .c | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 | mpy - MicroPython cy3 - Cython So, ... low resource can't run heavy languages fast (yet?). Good thing is by using MicroPython and writing the ti…

If you add two spaces in front of each line, it formats as monospace. Like this:

  | impl | c     | py3    | mpy     | pypy3 | cy3   |
  |------|-------|--------|---------|-------|-------|
  | [ns] | 0.176 | 11.462 |  37.633 | 0.818 | 0.590 |
  | .c   | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |
Also, I'm taking a guess here and assuming that the values in the second line mean "execution time as multiples of the execution time for C".

Re: Why is Rust difficult?

#87

Post by majewsky »

vlovich123 wrote: post #82
jchw wrote: 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…

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web br…

> In terms of correctness, I've never heard claims about improving security issues

I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues.

> As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that.

Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;)

Alternatively, write some C++ code that uses std::map or something like that incorrectly, and marvel at the page-long exceptions with all the default template arguments expanded into an unreadable mess.

> Also, the Rust compiler appears pretty vibrant with lots of improvements being made to help with user friendliness, so it's possible that further improvements in inference might reduce the problem spots (it's already pretty magic to me).

I also recently got into Rust (coming from Go), and the thing I miss most is `gofmt`. Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

Re: Why is Rust difficult?

#88

Post by pjmlp »

flohofwoe wrote: post #84
pjmlp wrote: post #78

Earlier quoted context omitted.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/

Thanks for pointing it out, I wasn't aware of it and it does look good, but they clearly state the uses cases which it isn't fully ANSI C compliant on page 24 of the documentation.

Re: Why is Rust difficult?

#89

Post by majewsky »

Zalastax wrote: post #66
bluejekyll wrote: post #61

Earlier quoted context omitted.

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

> There's a lot of research that needs to be done before proven programs can become the norm.

At least equally importantly, we need a new generation of developers to grow up with these tools before they can become the norm.

In fact, the biggest contribution that academia could make to safe programs is to replace Java and C by Rust in all the programming courses, so that the next generation of developers is raised on Rust and makes that language (and its strictness mindset) popular in the industry in the same way that Java's relevance in the industry is based (in part) on its prevalence in curriculums.

Re: Why is Rust difficult?

#90

Post by majewsky »

Ar-Curunir wrote: post #69
jchw wrote: 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.

"Most" is a problematic word because it requires a baseline to compare against. When you're coming from something like Ruby, Rust most definitely solves "most" correctness bugs. When you come from Go, probably not.
Post reply on HN