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

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

91–100 of 301 posts

Re: The struggle with Rust

#91

Post by alkonaut »

trishume wrote: post #18
adwhit wrote: post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve. The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like th…

> Agreed. Rust is different from other languages in that it is HARD to learn

But do you learn to code in a different paradigm where you don't struggle by iterating on a compilable and runnable piece of code, but rather struggle on iterating on a non-compilable piece of code and "once it compiles, it works"?

Re: The struggle with Rust

#92

Post by gravypod »

Diggsey wrote: post #59
gravypod wrote: post #37

Could the issues of rust be rectified with a better theorem proved that goes past "2 things are touching this"? I don't think I'd mind if the compiler said "your code will not work because eventually it will modify the same bytes at the same time and create an unpredictable state" but I will mind if it says "your not good because you have two mutable references.

Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part. However, what you're asking for is very similar to what types like `RefCell` and `RwLock` do - they effectively delay borrow-checking until runtime. Now yo…

> Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part.

I think there are two solutions to that problem. The first is to involve HCI people in the development in the language to see how they can improve the output and communication from the theorm prover to the programmer. I imagine that, some time in the future, a very powerful therom prover will make its way into a "general" language and will bring some cool effects. The theorum prover I'd like to see will attempt to prove all of the conjectures used in the program and, when not possible, will say "possibly invalid code. Please solve this conjecture" where then this would be given to a mathamatician and they have to complete the missing steps to see if it works, if not we tell the compiler this isn't going to work and it now generates errors for this.

The other solution is to limit the shared state of every program using very strict segregation of all moving parts and an attempt to limit use of side-effect-causing operations.

This second one is nothing new, I mean the original LISP crowd had these ideas down and theres nothing new.

I don't think I've ever worked with a compiler that has a built in theorum prover, possibly a shared library of proven work, and a way to in the language aid the prover. For instance this type of function definition

    int(int numerator, int denominator) where (denominator != 0) divide {
        return numerator / denominator
    }
And even more so I've not heard of unobtrusive theorum provers that keep out of the programmers way while still being useful. I think an unproven relation should be a warning. It's not good but the program can still run and you (you being not me but the math-people) can come up after me and prove all of my work or tell me I'm an idiot and to fix it.

Re: The struggle with Rust

#93

Post by shadowmint »

gcp wrote: post #24
rubber_duck wrote: post #22

Earlier quoted context omitted.

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly. So that's opposed to C++'s "It takes a few years to get acquainted to the language enough that people would want your stuff in production code"? Nobody hires junior C++ programmers.

? What's your point.

The parent post specific said it wanted a replacement for C++; the amount of time and effort it takes to get code right in C++ is a problem.

Rust also has a long learning curve, and its hard to quickly be productive in.

I don't think there's anything wrong with idly wishing there was some kind of middle ground where you could gradually or partially opt-in to the borrow checker with a nice modern language like rust to get started, and then gradually eliminate your GC parts or whatever.

Many game engines use a high level language with a GC like C# or (shudder) python or blueprint which are baked by C++ for the performance critical parts.

You write application logic in the scripting language, and anything that's too complex you fall back to C++ for.

If rust could somehow self host itself as a high level language like that, it would be superb.

Re: The struggle with Rust

#94

Post by rubber_duck »

zzzcpan wrote: post #87
rubber_duck wrote: post #64

Earlier quoted context omitted.

Yea that's what I see as an issue as well, I was hoping it wouldn't be but the deeper I go in to Rust the more it shows up. On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense, this would let you avoid "pushing square pegs in to round holes" solutions when the borrow checker doesn't capture your problem nicely, and it would be trivial for C++ devs to get on board. On…

There might be an easy solution, they could provide more flexibility on using safety features, kind of like Perl did it, i.e. let anyone disable/enable a particular strict feature for a particular scope, for example "no borrowcheck;" or something. This will make it easier and more flexible for everyone, newcomers will be able to gradually learn more about the language and still get things done in the meantime, and po…

They have that with the "unsafe" blocks but like I said promoting it as something you should use when things don't fit borrow-checker goes against their primary goal of making things safe. I guess there are two camps, one that wants compile time safety guarantees - those people made Rust, and the other wants a C++ replacement with modern tooling and no legacy garbage - those are looking at Rust and getting discouraged by safety trade offs they are paying but not really caring for - and every Rust tutorial I've seen focuses on hammering this aspect instead of going "OK here is the equivalent of this C++ code with unsafe code - you now get a sane build system, package manager, modules, fancy syntax. Now if you want here's how to make it safe."

Re: The struggle with Rust

#95

Post by Bartweiss »

humanrebar wrote: post #66
rbehrends wrote: post #55

Earlier quoted context omitted.

This is a different issue. The problem that the author is observing is that Rust operates on the hypothesis that the ownership relation is mostly left-unique and acyclic and that you run into problems when this hypothesis doesn't hold. And this affects not only explicit data structures, but also the implicit structures that involve stack frames (local variables, closures, etc.). While Rust has mechanisms to deal with…

First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker. Second, this article only considers the costs of a stricter borrow checker, not the benefits. It will be more work for the coder to have to think about how allocation and ownership is communicates. But I've been…

> Even if Rust is much harder than alternatives instead of just different, and even if that's inherent in borrow checking, it's not clear that it's still not worth it in the long run.

One obvious argument is that Rust frontloads its difficulty. It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. But that's true of a great many tools - if there's an adequate payoff in safety and comprehensibility at scale, they can still be worthwhile.

That doesn't solve the learning-and-usage problem, though. Most of us are aware that the explosion of dangerous-at-scale tools like Javascript is largely because no one adopts a language that's unfriendly until you reach enterprise sizes. Even if Rust is "worth it", it's unlikely to catch on while the learning experience feels like pulling teeth.

Re: The struggle with Rust

#96

Post by omouse »

rubber_duck wrote: post #22
adwhit wrote: post #5

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust." Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration…

>It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction gra…

To get any programming done, you have to learn certain things, you can't complain that it takes weeks to learn a new programming language and months to assimilate it's model of thinking.

But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream.

You mean it's okay for everyone to struggle to work with JavaScript for years and years trying to come up with an OO system and a module system and trying to just bundle the files for the browser, but it's not okay to spend months on getting intimately acquainted with the language?

Who cares if Rust becomes mainstream, we only need the best open source code to use it (like Firefox and the other C/C++ libs that are thinking of porting over). We don't need it to be mainstream, we just need it to be possible to learn it within a reasonable timeframe (less than a year).

Re: The struggle with Rust

#97

Post by gcp »

shadowmint wrote: post #93
gcp wrote: post #24

Earlier quoted context omitted.

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly. So that's opposed to C++'s "It takes a few years to get acquainted to the language enough that people would want your stuff in production code"? Nobody hires junior C++ programmers.

? What's your point. The parent post specific said it wanted a replacement for C++; the amount of time and effort it takes to get code right in C++ is a problem. Rust also has a long learning curve, and its hard to quickly be productive in. I don't think there's anything wrong with idly wishing there was some kind of middle ground where you could gradually or partially opt-in to the borrow checker with a nice modern…

My point is that C++ has a learning curve that's as steep as Rust's. Rust is a C++ replacement. So this isn't a disadvantage for Rust.

It may stop Rust from getting widespread adoption, but I see no problem with that. C++ isn't "widely used" either by most meanings. Rust may still largely replace C++ even without magically having a less steep learning curve. (Which it, IMHO, actually has anyway.)

Re: The struggle with Rust

#98

Post by Bartweiss »

jnbiche wrote: post #80
smt88 wrote: post #67

Earlier quoted context omitted.

> smooth brain to text programming This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scal…

OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!"

Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irreducible.

Re: The struggle with Rust

#99

Post by omouse »

I know about GDB, that ain’t a good debugging experience

I can't take this article seriously after reading that and after reading this:

So I spent a few evenings with Rust

How long did it take you to learn C, C++, Java, Python, Ruby, Perl or other languages? MONTHS. Many many many months. Sure you could get something up and running in a few evenings but after many months did you realize that earlier code could be better. Each language has its own obstacles and spending a few evenings isn't enough time to get around them.

I gave Haskell a pass but after checking out Elm I can see more of its power. I gave Rust a pass because the language was changing but now that it's stable I expect to sit down for a few months at least learning it.

Re: The struggle with Rust

#100

Post by Bartweiss »

sametmax wrote: post #77
jnbiche wrote: post #53

Earlier quoted context omitted.

> I believe that we are seeing the same kind of phenomenon in Rust: I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, an…

Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.

This is worth remembering. I'm technically on my "second attempt" to learn Rust, but the first one wasn't abandoned because Rust is fundamentally flawed. It was just new enough that the thing I wanted to build was drowning me in nightly builds and hypothetical features. After giving it ~1 year, things are already looking much more welcoming.
Post reply on HN