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

171–180 of 260 posts

Re: Why is Rust difficult?

#171

Post by narimiran »

kumarvvr wrote: post #13

After years of using Python, it's been difficult to wrap my head around GO and Rust. I really wish there was a course on Rust / Go for python programmers.

> After years of using Python, it's been difficult to wrap my head around GO and Rust.

I had the similar post-Python problem, until I settled on Nim [0] - it has Python-like syntax, significant whitespace, and ease of writing (but don't expect Python level of it), while compiling to C and providing significant speed benefits.

Also there is a brief "Nim for Python Programmers" [1], which might interest you.

[0] https://nim-lang.org/

[1] https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

Re: Why is Rust difficult?

#172

Post by steveklabnik »

quodlibetor wrote: post #157
josephg wrote: post #76

Earlier quoted context omitted.

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

The nice thing about Rust not having Async IO built into the language is that arbitrary third-party implementations are possible on a level playing field with the async framework being developed by the core team. For example, there is the May[1] concurrency library. It provides alternative implementations of the standard library's IO interface, but does Go's automatic suspend/resume, so it still looks like blocking c…

It also has possibly irreconcilable soundness issues :/

libfringe is another extremely interesting player in this space.

Re: Why is Rust difficult?

#173

Post by steveklabnik »

nly wrote: post #164
jonathanstrange wrote: post #123

Earlier quoted context omitted.

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

> That being said, Rust is already so obscure that it can easily replace C++ An obtuse syntax is a big downside of C++. Implying that a steep learning curve and the ability to 'show off' helps keep the language where it is grossly misrepresents the vast majority of C++ programmers. Those traits were born out of necessity. In C++98 you simply had to be 'clever' to keep up with modern languages because the language was…

We are certainly not trying to do that. Our stated goals for this past year, and possibly some of our goals this year, are the direct opposite.

Re: Why is Rust difficult?

#174

Post by kqr »

neverartful wrote: post #151
jonathanstrange wrote: post #123

Earlier quoted context omitted.

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime…

I've taken a brief look at Ada several times, but gave up on it because it seemed difficult to get a cohesive set of documentation and examples (and ideally a good book) that were all in sync. Since Ada has been around for so long, there's an awful lot of outdated material. Do you have any suggestions on materials one should use while learning Ada for hobbyist purposes? I'd like to give it another go.

Four versions of Ada, named after the year it was released: 83, 95, 2005, and 2012. Each new version adds features on top of the previous.

Ada 83 has

- arrays,

- records (structs),

- derived types (subtypes carrying the same data as parent type),

- subtypes,

- access types (thick pointers),

- procedures (subprograms executed for their side effects) and functions (subprograms that return values),

- Named parameters

- reference arguments (greatly reducing the amount of pointers you have to deal with)

- Default values for arguments

- overloading by type

- in/out parameters

- private package parts (encapsulation)

- generic packages (kinda like C++ templates)

- exceptions

- tasks (concurrent processes that communicate with message passing)

-----

Ada 95 adds a lot of things that make it easier to do Java-style OOP:

- Record extension (inheritance; subtypes carrying additional data their parent type does not)

- Dynamic dispatch of subtypes

- Abstract types

- Subprogram access types (function pointers)

- Sophisticated package hierarchy (though potentially somewhat unintuitive: child packages extend their parents, parent packages are not umbrellas for children the way they are in Python)

- Protected types (protected objects)

- Modular types (unsigned ints with defined overflow characteristics)

- Unbounded_String (the std::string of Ada, compared to the char[] situation in Ada 83)

-----

In Ada 2005, the greatest addition is probably the Collections packages, which added several common data structures to the standard library:

- Instance.Method(Param) syntax sugar for Object.Method(Instance, Param)

- Interfaces

- Controlled types (RAII)

- Removed silly restrictions on access types

- Keyword "limited" to import only declarations

- Keyword "raise" takes exception message directly

- Pragma Assert

...and this is where I need to get off the train. Anyway, bookmark the Ada 2012 Reference Manual. It has everything in it.

Edit: ...but look what I found! https://www.adacore.com/about-ada/comparison-chart

Re: Why is Rust difficult?

#175

Post by unethical_ban »

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 write somewhat simple programs and webapps for my job, from time to time. I use Python and its standard library, some modules, and the Bottle Framework. Pulling data from APIs, doing analysis, taking some user input, editing configs, etc.

I hardly ever use classes unless I'm extending a vendor library. I have never used generics. Why are generics such a critical component of a programming language that every thread about Go mentions it? It's an honest question from me.

Re: Why is Rust difficult?

#176

Post by steveklabnik »

bitL wrote: post #19
SamReidHughes wrote: post #15

Earlier quoted context omitted.

Is it? Could you give an example? I've found a borrow checker bug in the current release but the rest of the time its behavior is perfectly predictable. Granted, I wouldn't be surprised if the documentation was horrible, my understanding of the checker is based on one way I would do it.

It's simply one more thing you need to keep in your internal "context" while writing a program, taking mental resources you could spend elsewhere. Perhaps an IDE guiding you and outright rejecting the code or offering code completion that is compatible with borrow checker might be a solution, though we aren't there yet I believe.

Experienced Rust programmers usually say the opposite: the borrow checker frees you from thinking about it since the compiler lets you know when you mess up.

Re: Why is Rust difficult?

#177

Post by steveklabnik »

titanix2 wrote: post #38
sillysaurus3 wrote: post #14

Is there a way to avoid the true-believer syndrome for Rust? I want to embrace Rust, but everyone ~100% of the time comes away chanting about how awesome Rust is. So much so that it's a bit unsettling. Zealotry in general is bad, but especially in programming: once you identify as an X programmer, you lose out on ideas from Y and Z. Every tool has its flaws, but for whatever reason it seems extremely rare to discuss…

This is the exact reason I won’t learn Rust past looking quickly the doc: the promotion made by some very vocal people is a huge turn off. Notably by saying that everything must be rewritten in Rust, it implies that every other language is sh*t and people using them are dumb. Of course I don’t like that view for my work nor I won’t to be associated with this kind of people. This is a bit sad because the language prob…

Where are you seeing these kinds of comments? Can you link me to them? I’d like to tell them to cut it out.

Re: Why is Rust difficult?

#178

Post by jchw »

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…

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

I'm only comparing Rust and Go where they overlap. For example, Rust webservers versus Go webservers. There are other languages that may overlap different parts of Rust, such as in fact, Ruby and Python.

Go and Rust are both more general than the languages people compare them to. Both have C interop of various levels. Both allow unsafe code that touches memory directly. Both are high performance, relatively low level, and both provide some level of memory safety (though, Go provides much less.) I think they overlap a whole lot more than people think.

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

Well, I personally would claim it helps a lot of security and crash issues. Buffer overflows, use-after-frees, race conditions, and more. Also, most people do not overstate the safety of Rust, but beginners frequently misunderstand it. This is because people often list the benefits without listing the caveats.

Re: Why is Rust difficult?

#179

Post by stjepang »

steveklabnik wrote: post #172
quodlibetor wrote: post #157

Earlier quoted context omitted.

The nice thing about Rust not having Async IO built into the language is that arbitrary third-party implementations are possible on a level playing field with the async framework being developed by the core team. For example, there is the May[1] concurrency library. It provides alternative implementations of the standard library's IO interface, but does Go's automatic suspend/resume, so it still looks like blocking c…

It also has possibly irreconcilable soundness issues :/ libfringe is another extremely interesting player in this space.

I'd like to read more about those soundness issues - do you have a link?

Re: Why is Rust difficult?

#180

Post by TheCoelacanth »

gkya wrote: post #165
josephg wrote: post #76

Earlier quoted context omitted.

> 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 haven't used Go all that much, but arent the interfaces meant to be used as generics, i.e. in your function you need some data X, and you'll do something with that X. The way you need to achieve this is that expect an X that satisifes a given interface, say Exampler. If a particular X does not support it, you write the method(s) on X's type to satisfy the Exampler interface. IIRC Pike said somewhere that you don't…

Pike clearly doesn't even believe his own argument because he added generics for lists and maps. He just doesn't allow users access to the same capabilities.
Post reply on HN