Live data from Hacker News

The struggle with Rust

ayende.com

201–210 of 301 posts

Re: The struggle with Rust

#201
I do not know Rust, but I know C and some Haskell and AFAIK one should building a program in Rust differently than in C/C++ (which is probably the authors background).

Get out a quick correct (and this can not be emphasized enough) version (obviously one has to learn the language here) and then optimize (when you have numbers). The author did not seem to get a working version with Rust (sorry, if I am wrong on this), and tried an approach that he knows would work for C/C++. But maybe another approach would have been already performant enough?

Re: The struggle with Rust

#202
post #192

Earlier quoted context omitted.

Then use https://github.com/Manishearth/rust-gc if you're willing to pay the price of a GC (still experimental). Or better, stick to a GC'ed language. If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. Use the right tool for the job.

> If you don't need manual memory management, it's obviously going to be a burden. There are still use cases for manual memory management though, and that's where Rust comes in. That's exactly the point that I made in my original comment?

Sorry, HN isn't great at keeping track who's who on a comment tree.

Re: The struggle with Rust

#203
post #89
post #69

The first few of these types of posts were OK. But now it's a bit ridiculous. You spent 2 days trying a new language and you didn't like it, your opinion means nothing.

I don't typically respond to comments like this anywhere, but I think this kind of view is dangerous to have. And it's one the Rust community at large seems to try to shy away from. This kind of attitude towards people trying out a new language is damaging to the person trying the new language and to people who are part of that languages community. The former because it will give them the notion that the community is…

For a language like Rust that puts all the pain up-front, I want to hear whether the pain is worth it. But someone who spends only a few days can't give you a weighing of whether the pain is worth it.

I'm reluctant to even listen to someone's Amazon product opinion if they've only used it 2 days.

Re: The struggle with Rust

#204
post #188

Earlier quoted context omitted.

It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it. E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he ne…

And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python int…

Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.

Re: The struggle with Rust

#205

Earlier quoted context omitted.

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

I work on databases and I ran into similar problems implementing index data structures. While I understand petgraph solves some/all of these problems completely - it would be great if the barrier to writing trees / graphs from scratch in Rust would be lower than it is currently.

Re: The struggle with Rust

#206
post #166
post #141

Earlier quoted context omitted.

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

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for.

The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that work here (D, too, but D is like C++. There are also other languages). But systems programming doesn't have to look the same or use the same primitives.

Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code.

Rust does expose this functionality, but if it's not something it expects you to use often it makes sense that it might not always be straightforward to use.

Re: The struggle with Rust

#207
post #59

Earlier quoted context omitted.

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

This example works in SBCL, where types (possible disjoint sets of values) are treated as assertions. By default I always set "safety" and "debug" to 3 (the max), which helps.

    ;; Giving names to abstract things a little
    (deftype zero () `(eql 0))
    (deftype non-zero () `(and number (not zero)))

    ;; Declaration
    (declaim (ftype (function (number non-zero) number) divide))

    ;; Definition
    (defun divide (n d) (/ n d))

    ;; Test
    (lambda (u v)
      ;; introduce a type constraint here.
      (declare (type zero v))
      (divide u v)) ;; (nb: underlined in orange)
This message is also printed:

    note: deleting unreachable code
    warning: 
      Derived type of V is
        (VALUES (INTEGER 0 0) &OPTIONAL),
      conflicting with its asserted type
        (OR (AND NUMBER (NOT INTEGER)) (INTEGER * -1) (INTEGER 1)).
      See also:
        SBCL Manual, Handling of Types [:node]
The warning happens when two types are and-ed (intersection), and the resulting set is empty. You still allow code where there is potentially "bad" value flowing from one place to another, because ultimately you know the runtime will detect it. In other words, the goal is to reject false negatives (unwarranted warnings), which contrasts with statically typed languages where you only accept code that is guaranteed to satisfy static typing rules (it makes sense there because the compiler is your last chance of catching those type errors, since the runtime does generally not perform type checks).

(edit: actually use non-zero instead of (not zero))

Re: The struggle with Rust

#208

Earlier quoted context omitted.

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…

Are these strategies for solving borrow checker issues documented anywhere? Sounds like a case for which a best-practice reference would be golden.

I wrote http://manishearth.github.io/blog/2015/05/27/wrapper-types-i... which explains the primitives that can be composed together to do things like this.

Re: The struggle with Rust

#209
post #16
post #12

Earlier quoted context omitted.

If this were a C++ problem the author wouldn't have blogged because the answer would've been on StackOverflow.

Not sure if your comment was intended dismissively/jokingly, but I think also somewhat insightful. I find myself much less often really thinking about how to do something these days; if it seems remotely standard or potentially troublesome I google it. As a result, I spend less time thinking "algorithmically" about low-level stuff and probably lose something. But I also spend more time thinking (perhaps algorithmical…

Googling for Rust solutions is dangerous since frequently the advice you find only applied to some old beta version and no longer works. Then you find a second answer but it only applies to an even older beta version. None of the examples anywhere work of course.

This is my biggest frustration with the language: the manual is good for what it is, but it only covers the basics. You can see this in the article, where the author tries to implement a simple DNS cache and fails miserably. He doesn't even get to the part where you have a separate thread managing the cache and expiring old entries in the background to avoid unbounded growth and stale data. This is the sort of thing I could whip up in literally half an hour in C, but I just know the borrow checker is going to be a pain in the ass if I try to do something similar in Rust.

Re: The struggle with Rust

#210
post #169
post #97

Earlier quoted context omitted.

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…

> (NO WAY is C++ harder to learn than Rust)

Depends on what you mean. Writing good, safe, C++? Quite hard. Debatably harder than Rust, but it's debatable, not an absolute statement.

The difference is that C and C++ let you write things like doubly linked lists in day 1 of learning them, whereas Rust won't. But a good doubly linked list is tricky to get right anyway.

I learned C++ first too, and I think I have a handle on "safe" C++ practices, but it's mostly a nebulous set of conventions that shift in the particulars based on the codebase. OTOH in Rust I'm immensely productive even in random codebases.

Most of the cognitive overhead of Rust exists in C++ too, since you still need to reason about how your data is shared, just that C++ spreads the cost out over the learning curve, whereas in Rust you have to deal with it up front.

Post reply on HN