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

41–50 of 323 posts

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

#41

Post by wmonk »

b0rsuk wrote: post #19
vvanders wrote: post #11

I was following along until this: > universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more. The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

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 ReadTheDocs. It anyways seems really hard to find what I actually want. Take flask and alembic

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

#42

Post by AndyKelley »

I have a similar story: http://genesisdaw.org/post/progress-so-far.html

This is why one of the main features of zig listed on the home page is:

"Small, simple language. Focus on debugging your application rather than debugging your knowledge of your programming language."

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

#43

Post by grayrest »

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. I hope Rust is better than that.

In Rust these are treated as two completely different types so this is a compiler error and not a warning. You need to explicitly cast one of them to make the comparison and integer types are not automatically converted in any way. You have to do the same for any other operation involving the two types (e.g. addition).

You could certainly define the `ParitalOrd` trait for the two types to make the comparison possible (I don't know the implications off the top of my head). The language defaults to safe and explicit.

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

#44

Post by majewsky »

weavie wrote: post #24
vvanders wrote: post #11

I was following along until this: > universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more. The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

I did find the documentation for promises and tokio to be pretty confusing. But I had only been learning Rust for a few days at that point, so I think I was probably just not ready for it. I went on to just use the basic sockets instead and that was pretty easy.

> I did find the documentation for promises and tokio to be pretty confusing.

I've been learning Tokio just this week, and I think this has to do with their ongoing refactoring away from the tokio-core crate to the tokio crate.

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

#45

Post by kibwen »

majewsky wrote: post #39
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 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::…

Coincidentally, `impl Trait` stabilization was just approved, meaning it should be in the next beta: https://www.reddit.com/r/rust/comments/86f3h6/impl_trait_sta... . It will be a crucial step forward for Tokio's error messages.

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

#46

Post by majewsky »

drbawb wrote: post #31

>Even something as simple as abstracting a new helper function often turns into a veritable odyssey because getting type annotations right can be so difficult (especially where a third party library is involved). This is a sentiment I can't say that I share or even understand. You have a compiler doing inference, it will tell you what the types are if you ask? A lot of times when I find myself writing something where…

> A lot of times when I find myself writing something where I'm unsure of the concrete type -- I'll just stick a bogus type ascription in the expression somewhere. Then I run `rustc` knowing full well that it will fail. Somewhere in the error will be a message of the form "found expected " and now I know what the inferred type is.

I've found myself doing this a lot in order to find the type of an expression. I stick it in a variable, add an `variable.asdf();` somewhere and look for the error message "no method asdf() on type ".

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

#47

Post by gnode »

majewsky wrote: post #39
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 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.

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

#49

Post by oblio »

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.

Were you a C/C++ programmer before? Your starting perspective matters a lot.

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

#50

Post by szemet »

"getting type annotations right can be so difficult"

I had the same experience. After getting lifetimes (more or less) this became my largest headache... I wish for stronger type inference and features like this: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_gu...

I feel my productivity (and code quality) would increase a lot. For example right now I have to struggle so hard if I would like to write generic code, while in haskell that's more or less the default thing (the compiler infers it) if I just omit type annotations...

Post reply on HN