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

161–170 of 301 posts

Re: The struggle with Rust

#161

Post by steveklabnik »

Amezarak wrote: post #7
grabcocque wrote: post #2

These kinds of articles are always hostages to fortune. Because I guarantee somebody, any second now, will demonstrate that what the author wanted to do was trivial, and if he'd spent a bit less time trying to start flamewars on Hacker News he'd have discovered it. Not me, by the way, I don't know rust. But I reckon it'll be about three comments down.

I think part of the problem is this: if you're say, a C++ programmer, you can write C++ in most other languages and have a working program, even if it's not idiomatic. You can't in, say, SQL, Rust, or Lisp. That doesn't make them a priori harder than other languages, it just requires a shift in thinking, whereas if you're jumping to say, Java after C++, you can get started right away and hopefully pick up idiomatic J…

We're re-writing the Rust book at the moment: http://rust-lang.github.io/book/

It doesn't explicitly have a section like this, exactly, but there are several "thinking in Rust" style chapters towards the end.

Re: The struggle with Rust

#162

Post by bluejekyll »

rbehrends wrote: post #123
humanrebar wrote: post #66

Earlier quoted context omitted.

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…

> 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. No, unsafe would be overkill and if you needed unsafe, it would put Rust at a massive disadvantage vis-à-vis garbage-collected languages. Simply put, Rust doesn't handle multiple ownership well. It results in s…

I think you're implication here is that other languages do handle multiple ownership well. What I think you find in Rust, is that the guarantees you need to make when using unsafe in these limited situations, are the exact same guarantees you need to make in a language like C or C++.

Destroying a circular list takes some thought to make sure you don't double free, same as Rust. Rust just makes those sections of code very explicit and calls your attention to it, while in C you may end up with a segfault, or worse a program that only shows odd bugs during runtime. At least Rust is telling you that you need to put some extra thought in this section.

Re: The struggle with Rust

#163

Post by pcwalton »

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…

Ownership and borrowing are also useful for avoiding data races. OCaml solves the problem by not having any shared state at all, which is obviously a huge limitation.

Re: The struggle with Rust

#164

Post by pcwalton »

jackmott wrote: post #81
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 don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Data races.

Re: The struggle with Rust

#165

Post by pcwalton »

mtanski wrote: post #160
readittwice wrote: post #145

Earlier quoted context omitted.

You could use id/vec indices, instead of directly pointing to your e.g. sucessors: "struct Node { successors: Vec }". This has the obvious disadvantage that deleting nodes is quite hard though.

> This has the obvious disadvantage that deleting nodes is quite hard though It's hard because now you're in charge of building a malloc(3) implementation. Depending how important this data structure is you might need to worry about 1. about fragmentation 2. free space managment 3. adjacency and cache effects So you've traded on hard problem for another hard problem. Not something I'd call a win.

Just use petgraph. It manages all of this for you.

Re: The struggle with Rust

#166

Post by braveo »

drbawb wrote: post #141
maffydub wrote: post #111

Earlier quoted context omitted.

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming. Coming from C/C++, I know that there are structs in memory and can visualize what they look like - surely I can just go and tweak them? (No I can't because either it wasn't safe to do that anyway, or I need to explain to the Rust compiler why it is safe, and that can be quite difficult.) Coming from som…

>Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;) I tend to agree with this sentiment. The moment I saw that OP was doing pointer arithmetic: I knew they were in for a bad time. It's not that you can't do it -- it's moreso that Rust's raison d'etre is to highlight the fla…

In other words, you weren't using it as the systems language it's billed as. Which is fine, but it's claimed to be a systems level language, and if it's really that painful to do systems level things, then there's a problem somewhere.

Which is what's being discussed.

Re: The struggle with Rust

#167

Post by bluejekyll »

spullara wrote: post #155
bluejekyll wrote: post #128

Earlier quoted context omitted.

> It's a terrible tool for most 30 line tasks, simply because the majority of your work will go into arguing with the compiler. This arguing with the compiler is really only while you are learning Rust and it's nuances. For me the first two weeks were this way, then I started thinking more in Rust terms. Now I rarely deal with the borrow checker at all, but I do end up in some complex type situations. You're spot on…

I think the difference is that while you are coding Python in a C style the code is working. The front loaded nature of Rust means that you are in a constant fight to get something to run.

Yes, and I understand how frustrating it can be, I had to learn it, too. My only point is that after you spend the time with it, the cognitive load becomes a lot less and you've learned some new things about programming at the same time.

Re: The struggle with Rust

#168

Post by pcwalton »

rubber_duck wrote: post #64
vertex-four wrote: post #40

Earlier quoted context omitted.

> You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you. Luckily, Rust's community is much more pragmatic - but their goals are still to create something substantially different from existing languages because existing languages are not enough to guarantee what Rust guarantees.

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…

> On one hand a really simple solution would be to make unsafe a first class citizen when it makes sense

I have pushed this several times in the past, but there's always been a lot of resistance to the idea. Though I've always phrased it as "let's allow the safety checks to be turned off", which isn't necessarily the best phrasing...

I wonder if it'd be better to just push to make unsafe easier to use: add sugar for ptr::offset, add a -> operator, relax the restrictions on casts, and so on. When I do OpenGL programming in Rust I drop into unsafe quite regularly, and it feels just like C, except for some annoying papercuts. It'd be nice to get rid of those papercuts.

Re: The struggle with Rust

#169

Post by braveo »

gcp wrote: post #97
shadowmint wrote: post #93

Earlier quoted context omitted.

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

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

As someone who learned C++ first and later Rust, no it isn't. Rust's learning curve is a hell of a lot higher than C++'s.

This reminds me of when Java was trying to compete with C++, you would have all these Java people making claims that HotSpot was going to take over the world and make Java faster than C/C++. Only it never happened outside of a few specific cases because these people were "fanboys" in every sense of the word.

You like Rust, there's nothing wrong with that. You think it's better than C++, that's your belief and I'll defend your right to believe it.

But stop comparing it to C++. Just about every language over the past 20 years has users do the same thing and __C++ IS STILL KING__.

You can push rust without being unfair to C++ (NO WAY is C++ harder to learn than Rust).

Re: The struggle with Rust

#170

Post by pka »

omaranto wrote: post #142
pka wrote: post #106

Earlier quoted context omitted.

You can do that perfectly fine even in a pure language like Haskell.

Or maybe Haskell is also a hybrid? I know about the type theoretic accounting tricks used to stay pure, but when I really need unboxed mutable arrays and several tight loops, I just use the ST monad and write code that is psychologically completely imperative. And it compiles to pretty fast executables too, especially using the LLVM backend.

Yeah, that's what I meant.

You can't tell from the type signature alone if a pure function uses ST though, so I'd say that counts as pure :)

Post reply on HN