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

First Impressions of Rust

john-millikin.com

Post reply on HN
Print view View original

1–10 of 191 posts

Re: First Impressions of Rust

#4

Post by rsa25519 »

kanobo wrote: post #2

Once a Rustacean always a Rustacean - a first impression will inevitably lead you down a never ending road but luckily there is a great community to support you.

Definitely. I must admit, I came to Rust with a lot of baggage from other languages. I've learned a lot from reading about why Rust doesn't let me do things, often causing me to no longer do those things in other languages.

Re: First Impressions of Rust

#5

Post by thenewwazoo »

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run into.

Re: First Impressions of Rust

#6

Post by steveklabnik »

Hey hey, this post is great! A few small comments:

> It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using?

rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to try out new features without committing to them, same as features in the language.

> PyPI launched in 2003, and CPAN has been running since 1995

Neither of these support namespacing though, right?

> Cargo's unit of distribution is the crate, which is a problem because Rust's compilation unit is also the crate.

Cargo's unit of distribution is a package, which is one or more crates. It is true that there can only be one library crate per package, however. This is one area where people don't use the correct words super often, honestly.

> Of course build times are slow if changing one line of a leaf file requires rebuilding dozens of modules.

This shouldn't change based on if you're using Cargo or not; if it's re-building dependencies every time you touch a file, that is a bug.

Re: First Impressions of Rust

#7

Post by saagarjha »

thenewwazoo wrote: post #5

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run…

I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic knowledge of the thing ("while Python supports functional programming, it does not do so very well"). Rust's (intentionally) anemic standard library, strange dance around nightly ("we never break things…except in nightly, which we know you are using for your project because we gated all the features behind it") and a general sort of superiority towards npm when cargo/crates.io shares many of the same issues are the ones I ran into personally. And again, you don't have to be an expert to see these, but they're in this sweet spot between nonobvious and "something that'll go away if you use the language more".

Re: First Impressions of Rust

#8

Post by jmillikin »

steveklabnik wrote: post #6

Hey hey, this post is great! A few small comments: > It's not obvious to me why they do this – it's a documentation generator, why does it care what version of the Rust compiler I'm using? rustdoc, being a part of the Rust distribution, has the same stability guarantees that Rust does: once it gains a feature, it will never go away. We (well, not me I don't really work on rustdoc, to be clear) need the capacity to tr…

  > rustdoc, being a part of the Rust distribution,
  > has the same stability guarantees that Rust does:
  > once it gains a feature, it will never go away. We
  > (well, not me I don't really work on rustdoc, to be
  > clear) need the capacity to try out new features
  > without committing to them, same as features in the
  > language.
I guess I expect rustdoc and rustc to be much less tightly coupled, so that I could use (for example) stable rustc and nightly rustdoc on the same code.

In the current model, I can't use nightly rustdoc features without also using nightly rustc, because the annotations are processed by both systems.

You could imagine an alternate model where rustc stabilizes `#[doc(...)]` and leaves everything in there up to rustdoc's interpretation, and nightly rustdoc might enable new parameters to the #[doc] annotation.

  > Neither of these support namespacing though, right?
That's correct. I meant that mostly in terms of "package registries are not a new and untested idea". It's like using strings for file paths: not obviously a bad idea, turns out to be unworkable for obscure reasons, and as a new language Rust got to avoid that particular mistake. It feels like crates.io didn't (/ doesn't) have a similar process of avoiding known mistakes.

  > This shouldn't change based on if you're using Cargo
  > or not; if it's re-building dependencies every time
  > you touch a file, that is a bug.
Given a crate with a hundred files, each one fairly independent of the other (i.e. a broad shallow build graph), changing one requires (if I understand rustc correctly) recompiling them all. Otherwise the `crate::` references can't be type-checked.

Re: First Impressions of Rust

#9

Post by k__ »

thenewwazoo wrote: post #5

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run…

Coming from a dynamic typing background, I have to say Rust didn't feel much worse than Scala or OCaml to me.

Re: First Impressions of Rust

#10

Post by k__ »

saagarjha wrote: post #7
thenewwazoo wrote: post #5

I went into this expecting yet another barrage of complaints about lifetimes, but was very pleasantly surprised. This is probably one of the most thoughtful experienced-programmed new-to-Rust reviews I've read in a long, long time. I frankly don't have much to add, except to say that, once you really understand the language and start building complex projects, this article really does describe the real issues you run…

I think I am familiar with Rust–I spent a week or so working with it–and I ran into many of these exact issues. I appreciate it very much when someone can give a viewpoint of of using a language beyond the superficial one ("arrays start at one in Lua"), or complains about something core to the language ("C pointers are confusing") and actually says something you will run into but is not obvious from having a basic kn…

"we know you are using [nightly] for your project because we gated all the features behind it"

yes, that kinda sucks.

Post reply on HN