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

121–130 of 301 posts

Re: The struggle with Rust

#121

Post by rubber_duck »

vertex-four wrote: post #103
rubber_duck wrote: post #94

Earlier quoted context omitted.

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

You're almost certainly not looking for Rust if you don't want your language to prevent a vast variety of bugs, and instead want something that allows and encourages you to design systems which make it easy to shoot yourself in the foot (which all C++ codebases I've ever seen have grown). I don't think language developers are interested in making such a language in general, as it's not interesting - you'd just be reh…

>and not making anything particularly easier to do

Have you used C++ in the real world ? Dealt with it's insane build systems, build times, obscure semantics, etc. ? Not to mention there's nothing close to a sane package manager.

There's plenty of value of just rehashing the lessons learned in last 20 years of language design to a systems language.

Re: The struggle with Rust

#122

Post by lmm »

gravypod wrote: post #117
lmm wrote: post #65

Earlier quoted context omitted.

Well Rust's way of ensuring you don't modify the same bytes at the same time is to ensure that any byte has precisely one "owner" in any region in which it is mutated. That's a model we know how to implement and also an easy model for humans to think about - we can see what's going on (we can see the regions in the code) and we know what to expect to work (e.g. if you have a mutable reference you expect to be able to…

From an implementation standpoint that makes sense. From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but in…

> From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but instead is "scary" or "spooky".

I find passing ownership around very usable, and can never understand how the bit-twiddling C folks ever get anything done. Maybe that's my mathematical background - I like my functions to be functions.

> I'm just someone on the internet here to complain. I can't do that because I'm not a smart math person who can prove how to get there or even generalize it to work with other programming related things.

The hard part is forming the model. Once you actually know how it's supposed to work, proving it is the easy part. But I mean, how would you even explain to another human that a given algorithm is safe, if not by arguments along the line of "look, this function owns this piece of data and this function owns this piece of data and they're called one after the other"?

Re: The struggle with Rust

#123

Post by rbehrends »

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…

> 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 syntactic bloat and/or runtime overhead. But multiple ownership occurs naturally in a number of real-world programs.

> Second, this article only considers the costs of a stricter borrow checker, not the benefits.

This is why I very specifically mentioned that it's a tradeoff.

Re: The struggle with Rust

#124

Post by the_af »

rubber_duck wrote: post #102
the_af wrote: post #84

Earlier quoted context omitted.

That's because a lot of things (let's not debate exactly how many here) translate well between C++ and Java. But my point wasn't about going between relatively similar languages; it was about learning something radically different for the first time, like it was when you learned your first programming language.

But that's not going to work in practice - there are many skilled C++ devs and C++ has many ingrained legacy issues which another systems programming language could solve - but the bridge between that language and C++ must exist for this to happen. Like in the post, OP is a competent programmer - he can solve his problem in C++ - why would he invest months in to Rust to do the same thing ? If your answer is safety th…

Safety and correctness are big deals. I get that for many people they aren't a high priority. Such is life.

If someone thinks they won't gain anything by going from C++ to Rust, then no effort to learn it will be worth it. Obviously the Rust devs think there is a benefit.

Re: The struggle with Rust

#125

Post by sidlls »

gcp wrote: post #41
wiremine wrote: post #39

Earlier quoted context omitted.

> It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. In my experience, most developers can't or won't put in this sort of investment. Which leads me to wonder what fields/niches will Rust land in? This might change if, as other commenters have stated, it is taught as a first or second language, but that doesn't seem likely anytime soon...

Rust's niche seems very clear: C++ programmers that need better tools. This is an audience that should be willing to make a time investment, and understands the trade-off, for the most part.

I disagree to some extent, for a couple of reasons.

First, C++ programmers in aggregate have to consider more than the choice of language for their projects. Odds are they work for somebody else, on a team, an established project, whatever. In these cases "C++ programmers need better tools" doesn't mean "toss the bath out with the water." Rust isn't necessarily a good move in established products, in other words.

Second, Rust would do better, in my opinion, to target folks who are new to systems programming and, for whatever (mostly invalid, in my opinion) reasons, are intimidated by C or C++. Rust is very powerful and in many ways I like it much better than C++. I think Rust offers a great way for these people to have a gentle introduction to the world of systems programming. I say "gentle" because a good portion of the "pain" of learning is front-loaded into getting a build, rather than back-loaded into futzing about with gdb (although that would be something these folks will miss out on--who doesn't like a good session with gdb with a satisfying bug squash at the end?). Get them while they're young, as they say.

Re: The struggle with Rust

#126

Post by drbawb »

>We are talking about allocating memory, in a system level language, and unless you are jumping through hops[sic], there is just no way to do that.

To be fair, if you want to call malloc it is still just as accessible[1][2] as it is in C. If you search the Rust documentation for malloc `libc::malloc` is even the first result. If you were to use that on stable Rust the error message will even tell you to link your program to the libc published on crates.io (which is just adding a line in your Cargo.toml file.)

I'm not sure I'd call that jumping through hoops. I'd love if Rust provided easy access to its own allocator on the stable release channel; but I'm willing to wait for them to get it right, these things take time.[3]

[1]: https://doc.rust-lang.org/libc/x86_64-pc-windows-msvc/libc/f...

[2]: https://is.gd/cgkX2R

[3]: https://github.com/pnkfelix/rfcs/blob/117e5fca0988a1b0c4b6e4...

Re: The struggle with Rust

#127

Post by throwaway91111 »

eternalban wrote: post #73
gnuvince wrote: post #11

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems…

You came from interpreted Python to compiled OCaml and I suspect that your initial encounter with a compiler is the underlying issue. (For example, being new to FP but very friendly with compilers -- C, C++, Java, C# -- I found the initial OCaml encounter surprisingly pleasant. Haskell was something else though :)) I looked at Rust specs 1.0 when they were released and immediately recognized that Rust is not a 'datin…

Of all the things I'd accuse rust of, complex is not one of them. Could you give an example of the complexity? I've not found a single pattern in rust I wouldn't already have to think about in c++, but I have to think about it less because the compiler thinks about it for me. I just can't postpone the confidence until later.

Re: The struggle with Rust

#128

Post by bluejekyll »

Bartweiss wrote: post #95
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…

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

> 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 with the frontloads difficulty. Honestly though, I can't think of any language that I've learned that in under a few weeks I knew how to properly do things in the language.

Python was this way for me. My code looked like C when I started with it, and then I learned after a few weeks about 'with' and 'yield' and started writing real code.

Rust is worth the initial investment, but the first two weeks will require some perseverance.

Re: The struggle with Rust

#129

Post by kazagistar »

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…

(SQL is still kinda a crap language for dealing with sets, because the synatx does not represent the order in which set operation are applied or anything else; instead, they went with the "cobol" strategy of trying to make things like english.)

But I agree with your premise, certainly.

Re: The struggle with Rust

#130

Post by wyldfire »

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.

Don't you think C/C++ are hard to learn too? C++ has a vast surface area and I think it's unlikely that most people who use it understand much of it. When I code in C, I feel like I have to be paranoid because it's so easy to forget a path that doesn't recover allocated resources. But if I'm not paranoid, I just leak the resources and don't care about it (ever, or until many months or weeks later when the problem's discovered). So the easiness is illusory IMO. It seems to me that all of those other resource leaks are just leaking too slowly for us to discover yet.

> Each project involved tons of compiler fighting that I now know how to avoid or solve.

As frustrating as it is, it's easier than struggling with heisenbugs. Those can easily eat up days trying to reproduce issues.

Post reply on HN