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

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

71–80 of 323 posts

Re: 100 days with Rust: a series of brick walls

#71

Post by Yoric »

arghwhat wrote: post #66
seawlf wrote: post #10

As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. I've found the compiler messages to be succinct and helpful. The package system is wonderful. It's dead easy to get something off the ground quickly. All it took was learning how and when to borrow.

I recently wrote a few projects in Rust (C/C++/Go/JavaScript/Java/Python as background), and very much like the language. My 2 cents from my endeavors with Rust I felt like all type errors are backwards. That is, "got" was the target you are giving your type to, not the type that you are passing. This may only happen in some cases, but I just started tuning the content of those errors out and instead adjusted randoml…

> Enums are super nice, but it's very annoying that you cannot just use the value as a type. My project had a lot of enums (user-provided query trees), and it was causing a lot of friction.

Note that OCaml has this feature of using-a-enum-value-as-a-type (or using a subset of enum values as a type, etc.). It works very well, but it quickly produces impossibly complicated error messages.

I'd like Rust to have this feature, eventually, but not before there is a good story for error messages.

Re: 100 days with Rust: a series of brick walls

#72

Post by skohan »

SCdF wrote: post #38

I am currently learning Rust and I feel this intensely[1]. I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more. Want to have a da…

Two things jump out at me:

1. Automatic reference counting is a really good alternative to GC. It takes a little bit more book-keeping, but the performance characteristics are predictable since allocations/frees are handled along the way. Many GC implementations require execution to be halted while the reference graph is traced, which makes it a non-starter for applications trying to deliver predictable real-time performance.

2. Most of the limitations in Rust you're lamenting are there to ensure that your code is safe and performant. Rust requires adapting to very different design-patterns than you might be used to to get these benefits: if something is hard to do in Rust it's probably an anti-pattern with respect to memory performance or safety. Then again if performance isn't your main concern, maybe you don't need Rust.

Re: 100 days with Rust: a series of brick walls

#73

Post by tkzzbneig »

SCdF wrote: post #38

I am currently learning Rust and I feel this intensely[1]. I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more. Want to have a da…

It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. You may very well get the program to compile, but then run into odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). So any overridden methods which expect extra data in a subclass will not behave as expected.

So what you usually do here is have a pointer and a VTable and all that jazz. But there's been a resurgence in interest in putting data into contiguous blocks of memory. Check up on data driven design.

I don't think it's fair to compare GC'd languages to Rust's complexity. At least, compare C to Rust. But still, to be truly fair, weigh the usability differences against the safety differences. There are a lot of trade-offs here and perhaps this isn't the right way for you to go forward, but keep a broad view of the other aspects at play.

Re: 100 days with Rust: a series of brick walls

#74

Post by kibwen »

Jweb_Guru wrote: post #60
kibwen wrote: post #58

Earlier quoted context omitted.

> Want to have a data structure of variable size (eg a struct with an Vector in it)? You can't do that, structs have to be fixed size. I'm unclear what you mean here, because Vecs in Rust do have a fixed size. You can see this by using std::mem::size_of on a Vec: for any type, a Vec is three words in size. You can see this documented in the stdlib documentation for Vecs: https://doc.rust-lang.org/std/vec/struct.Vec.h…

You can also make a struct actually variable size anyway...

You can, but depending on what you actually want to do with that struct it can be pretty grotty to instantiate. Very much not beginner territory. I believe there's currently an approved RFC for making it easier to work with dynamically-sized data.

Re: 100 days with Rust: a series of brick walls

#75

Post by zyxzevn »

The problem with Rust is that it is very hard to program interconnected graphs.

Basic Rust does not allow cyclic references, which means that almost every graph needs to use special tricks to make it work. These tricks are variants of reference counting. A trick that was copied directly from C++.

It feels like having to build a car with only a screwdriver and hammer. Each section of your graph needs to be managed separately. With non-safe rust or C++ you can put whole panels or sections on your car. And a garbage collector works like a robot: usually effortless.

Re: 100 days with Rust: a series of brick walls

#76

Post by nemothekid »

rayascott wrote: post #63

There are a few things in life you just should not do. One of them is jump from your only language experience being Python into an advanced language like Rust when you’re struggling to grok SQL.

I’m pretty sure the author knows more than just Python and SQL. I would guess from his bio he knows C++, Haskell, go, Ruby, and JS.

Re: 100 days with Rust: a series of brick walls

#77

Post by SCdF »

scrumper wrote: post #68
SCdF wrote: post #38

I am currently learning Rust and I feel this intensely[1]. I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more. Want to have a da…

Minor point: you can have Vectors in structs. Vector is a fixed-size type on the stack so it works fine. And other types in structs too. EDIT: sorry, I see you got to that before I'd finished this post :) Rust is a language where you have to kind of take a step back before working with it to read about the design tradeoffs and why they were made. Certain things you're used to doing with other languages just won't wor…

> lifetime system logical on its own terms but very, very unnatural to learn

That is a succinct explanation of it, yes! Like I can read the documentation and nod along, and the rules seem simple. Actually then remapping your brain and how you want to achieve things seems incredibly challenging

Re: 100 days with Rust: a series of brick walls

#78

Post by robotmay »

weavie wrote: post #30
robotmay wrote: post #17

I've been learning Rust for a little while, and while I agree that it can be frustrating, it's nowhere near as bad as trying to learn Haskell. I regularly get a friend of mine to explain things to me, because the documentation and community for Haskell are 90% incomprehensible to anyone who doesn't have a comp-sci degree or a higher education in mathematics. Example: https://wiki.haskell.org/Lifting . It's not that I…

> Lifting is a concept which allows you to transform a function into a corresponding function within another (usually more general) setting. What's there not to understand? :)

Yeah that bit was alright, it was everything after that I struggled with ;) As an example; I don't know what a functor is. I've not come across that term in anything I've done before, so I click on it to read up and get the definition: "The Functor typeclass represents the mathematical functor: a mapping between categories in the context of category theory. In practice a functor represents a type that can be mapped over.", which uh, doesn't really help. I only did mathematics to GCSE level here in the UK, during which I never came across most of the terms used frequently in Haskell's documentation :D

There's a lack of examples of "real-world" usage in Haskell. e.g. here's how you'd use lifting, in a practical example. e.g. why is lifting a thing and what possible uses does it have when writing an application? Because to my knowledge I've never done it before, so why is it good?

Thankfully my friend sent me this: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_..., which is a much better explanation. It's probably due to a difference in my background (predominantly web, applications, self-taught etc) and the more academic history of Haskell, but I find the vast majority of examples irrelevant. Luckily there are a -few- books/tutorials around that explain the language more clearly and why I might want to write software with it.

It's a shame because it looks like a really cool language, but it is seriously hard to get into. Whereas with Rust, it just kinda makes sense to me.

Re: 100 days with Rust: a series of brick walls

#79

Post by heavenlyblue »

wmonk wrote: post #41
b0rsuk wrote: post #19

Earlier quoted context omitted.

They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentati…

Coming from well established js libs to python I have found the documentation really hard to deal with. I'm not entirely sure why that is. I really like getting to a repo on github and having the docs in the readme. Both python and rust have their own language specific doc implementations ReadTheDocs and docs.rs (I think). And you usually have to go to a separate site to view them which is fine, but I really dislike…

That's absolutely true. Python documentation severely lacks the necessary detail. Especially the newer doc format on that lighter background.

Re: 100 days with Rust: a series of brick walls

#80

Post by pornel »

zyxzevn wrote: post #75

The problem with Rust is that it is very hard to program interconnected graphs. Basic Rust does not allow cyclic references, which means that almost every graph needs to use special tricks to make it work. These tricks are variants of reference counting. A trick that was copied directly from C++. It feels like having to build a car with only a screwdriver and hammer. Each section of your graph needs to be managed sep…

Reference counting is not a trick in Rust. The standard Rc type is relatively easy to use and fast (since you can use a thread-unsafe variant safely).

The tricky things are only if you want to have 2-way pointers without refcounting overhead.

Post reply on HN