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

101–110 of 323 posts

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

#101

Post by vvanders »

andromeduck wrote: post #32
vvanders wrote: post #21

Earlier quoted context omitted.

You mean like how Vec has a ton of examples? https://doc.rust-lang.org/std/vec/struct.Vec.html FWIW I'm not a huge fan of Python's docs because I can't quickly scan them to track down that one detail about a function I was using. Rust's docs also let you collapse everything which makes browsing them much faster.

The traits implementation section is god awful and in an utterly unusable order because the ordering makes no sense. I find myself always just looking at the source to make sense of things rather than the docs which kind of defeats the point.

That's because the trait section only shows what traits a type implements. If you want to see how to use a trait just click that trait's name for the trait specific documentation.

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

#102

Post by jcelerier »

tkzzbneig wrote: post #73
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 a…

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

in particular, boost.polycollection is a nice implementation of heterogeneous vectors: http://www.boost.org/doc/libs/develop/doc/html/poly_collecti...

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

#103

Post by pimeys »

gnode wrote: post #47
majewsky wrote: post #39

Earlier quoted context omitted.

I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example: error[E0271]: type mismatch resolving ` + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result >, futures::MapErr , [closure@src/server/mod.rs:74:18: 74:74]>>, std::…

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

Don't get me wrong, it's a great library! You can do pretty darn fast systems with it, all type-checked and correct. Just don't try to fit in too many things into one thread yet, wait for async/await and non-statical lifetimes in the core.

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

#104

Post by steveklabnik »

We've been putting a lot of work into making Rust easier to learn. A lot of that stuff is just starting to land now. Some of it is inherent, but some of it is also just rough edges. Including things that the author talks about here.

So, my message is, we hear you! We're working on it. Might want to check back in in a few months.

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

#105

Post by jcelerier »

kibwen wrote: post #84
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…

(Responding to myself to reply to the parent's edit) > You're absolutely right. What I really meant was that you can't have Vec where T is a trait without also wrapping that in a box, which for me in turn doesn't work for a bunch of other reasons. Ah, it sounds like you're using traits as types directly, which is very much discouraged by Rust ( especially in conjunction with taking references to those traits). What t…

> What the language really prefers for you to do is to use traits as bounds on generic types to get rid of the dynamic dispatch and the consequent complications with lifetimes

Isn't this basically equivalent to only using templates in C++ code ? and doesn't it kill build times & prevent reusability across different shared objects ?

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

#106

Post by jcelerier »

isaachier wrote: post #9

I'm not sure how easy Rust claims to be... The main idea here is " I love that Haskell-esque feeling where a compiling program is usually a working program." Rust will probably get easier, but it's main goal is safety. The main problem I have with a pure safety focus is that the warnings often feel like overkill for 99% of programs. For example, when gcc yells about comparing signed and unsigned ints, I find that the…

> For example, when gcc yells about comparing signed and unsigned ints, I find that there rarely is a true safety concern involved

except for the small detail that stuff like "-1 < 1" is false when comparing int and uint because the int gets casted as the latter ? -Wsign-compare should be used as -Werror=sign-compare

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

#107

Post by plandis »

alexeiz wrote: post #88
majewsky wrote: post #39

Earlier quoted context omitted.

I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example: error[E0271]: type mismatch resolving ` + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result >, futures::MapErr , [closure@src/server/mod.rs:74:18: 74:74]>>, std::…

Finally, a language that can compete with C++ on complexity and size of error messages!

This is still an unstable library (futures and Tokio are both still 0.1 release) actively being developed, in general I tend not to see crazy compile errors working on synchronous projects. FWIF I’ve made a Chip8 emulator with Rust and am working on a Z80 emulator now.

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

#108

Post by Paul-ish »

vvanders wrote: post #101
andromeduck wrote: post #32

Earlier quoted context omitted.

The traits implementation section is god awful and in an utterly unusable order because the ordering makes no sense. I find myself always just looking at the source to make sense of things rather than the docs which kind of defeats the point.

That's because the trait section only shows what traits a type implements. If you want to see how to use a trait just click that trait's name for the trait specific documentation.

Sometime I don't know what trait I need, but I do know what kind of operation I want. In documentation such as Python's, I can "ctrl + F" for word similar to what I want to do and I usually find what I need. In rust, that textual description is usually hidden on the trait's page. This is probably more frustrating to beginners who don't know what most of the basic traits are. In general though, the standard library is better about this than other libraries.

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

#109

Post by oconnor663 »

kibwen wrote: post #86
oconnor663 wrote: post #82

Earlier quoted context omitted.

Responding to your updated question: > What I really meant was that you can't have Vec where T is a trait without also wrapping that in a box, which for me in turn doesn't work for a bunch of other reasons. You can use any type of pointer to refer to a trait object, not just Box. In particular, you can use &T where T is a trait. The vtable work happening at runtime is the same, but the object can live e.g. on the sta…

> You can use any type of pointer to refer to a trait object, not just Box. In particular, you can use &T where T is a trait. You can, though due to the extra annotations required I don't suggest that people new to the language try to use trait objects with references. (Hell, I try to keep people new to the language away from trait objects entirely, they're pretty restrictive.)

Yeah I added a followup bit probably after you wrote your comment. My suspicion now is that parent is running into the "C++ inheritance -> Rust trait objects" mismatch, and that they should probably try to use something else.

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

#110

Post by kibwen »

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…

> My code was littered with .as_str() and .to_string().

PSA: If you have a variable that's a String, you can easily pass it to anything that expects a &str just by taking a reference to it:

    fn i_take_a_str(x: &str) {}
    let i_am_a_string = "foo".to_string();
    i_take_a_str(&i_am_a_string);
Every variable of type &str is just a reference to a string whose memory lives somewhere else. In the case of string literals, that memory is in the static data section of your binary. In this case, that memory is just in the original allocation of your String.
Post reply on HN