First Impressions of Rust • Hacker News Board

Re: First Impressions of Rust

#51

Post by da39a3ee » Fri, Aug 07, 2020, 2:58 AM UTC

breatheoften wrote: post #42

da39a3ee wrote: post #39

Earlier quoted context omitted.

Whether reformat is called on save is up to your text editor and has nothing to do with the language.

Yes but there is no reason a language ecosystem can't assumes that this functionality is present, implemented in canonical form, and that it is a language use error not to enable. If the language designers assume the capability exists and will be used -- they can specifically evolve the language based on this assumption. All thats needed is a super high quality, compiler-provided implementation of the functionality -…

I think that you should have a second think about whether what you're saying makes sense.

To "save" some code means that an application writes it to hard drive. But writing to a hard drive is entirely orthogonal to the operation of a compiler. For example, a compiler should be able to compile code that is never written to hard drive -- exists only in memory. The hard drive is just one possible source of code to be compiled.

I do agree with you though that autoformatting code on save is a fantastic experience. It works beautifully with Rust, and so now I do it (less beautifully) with Python/black. I just think that although it's a great developer experience, it's several steps removed from anything that anyone would want tied to the compiler.

Re: First Impressions of Rust

#52

Post by steveklabnik » Fri, Aug 07, 2020, 3:00 AM UTC

jmillikin wrote: post #50

steveklabnik wrote: post #48

Earlier quoted context omitted.

Gotcha. You can use path as a dependency if you also use the version as a dependency, and it’ll use the path locally but the version when you publish. Maybe that needs to be better documented and would have just fixed your issue. (This is described at https://doc.rust-lang.org/stable/cargo/reference/specifying-... )

That requires publishing the internal crates as separate entries in crates.io, if I understand correctly, which I don't want to do (see the final section on crates.io's packaging model). Ideally I could have a single crates.io package, with a single tarball, containing multiple crates. The internal crates would not be exposed to users, wouldn't have versions, wouldn't be on docs.rs, and so on.

Yeah, that is true, it does.

I do think that's an interesting idea. I'll have to mull on it. Thanks again. I've been thinking of a few things here, very interesting :)

Re: First Impressions of Rust

#53

Post by berkut » Fri, Aug 07, 2020, 4:28 AM UTC

cgrealy wrote: post #47

zamalek wrote: post #44

> I eventually gave up on trying to make the formatted rust-fuse code look pretty, and settled for "consistent". Even though it's a bit ugly, this is a big win. As for why it does this, from my experience, rust-fmt will try to keep lines under a column limit but not greedily. e.g. if a params list would extend past the limit, then all params get a newline. It seems to try to balance horizontal estate and vertical est…

Consistency > prettiness

Is it just prettiness though?

When I worked in the defence industry (~15 years ago now), a lot of the coding standards for C/C++ (which was starting to be used more and more over ADA at the time) were very strict on the matching alignment of things like open / closing braces, so things like hanging braces were not allowed, both opening and closing braces had to be on their own lines.

The argument behind this was it made the code clearer, and more easy to match clauses / scoping - in a way arguing it was "safer" in terms of interpretation of the code.

Re: First Impressions of Rust

#54

Post by migueloller » Fri, Aug 07, 2020, 4:31 AM UTC

jmillikin wrote: post #24

migueloller wrote: post #12

Earlier quoted context omitted.

Would you be willing to expand on why using strings for file paths turns out to be unworkable? Very curious what the obscure reasons are!

Short version: file paths are an OS-specific construct, and not all OSes have paths that can be round-tripped through Unicode. The first bad option is to say "paths are bytes", which is true on traditional POSIX platforms. Then you run your code on macOS and discover it's processing your bytes as UTF-8 and applying Unicode normalization. After fixing that you try porting to Windows and get to learn about `wchar_t`. T…

Thanks for the response!

Re: First Impressions of Rust

#55

Post by p1necone » Fri, Aug 07, 2020, 4:35 AM UTC

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…

Imo lifetimes aren't that complex. They're just a wholly new programming language feature - learning lifetimes is hard because you're simultaneously learning the syntax and the concept.

Compare to something like generics where it's roughly the same idea in most languages that feature them, you just need to learn the syntax and maybe some edge details that differ between languages (Contravariance and Covariance say hello!).

If you've ever helped someone who's entirely new to programming learn their first language you might see some parallels with experienced programmers learning entirely new features like lifetimes.

Re: First Impressions of Rust

#56

Post by pcwalton » Fri, Aug 07, 2020, 4:36 AM UTC

You should be able to get the size of c_ulong without any dependencies using std::mem::size_of::(). I usually use std::os::raw instead of the libc dependency in my own crates, even though some people consider it bad style to do so. (Working in graphics it's often the case that I don't need anything from libc except a few data types.)

Another note: The notion of a "compilation unit" in Rust is fuzzier than in C/C++, because of incremental compilation. The goal is to be able to point rustc at a crate and have rustc/cargo internally decide which parts of it should be recompiled and which can be cached. A good chunk of this is already done today—for example, rustc will internally split up single crates into multiple LLVM compilation units to get better parallelism during the codegen phase—but more can definitely be done. Basically, Rust leans more on "compiler heroics" than C/C++ traditionally has, in that the compiler effectively splits up source files automatically instead of the programmer manually doing so.

Re: First Impressions of Rust

#57

Post by indolering » Fri, Aug 07, 2020, 4:39 AM UTC

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…

> 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")

Creating a beta channel or getting more of those features released in stable requires money or time.

Re: First Impressions of Rust

#58

Post by vlovich123 » Fri, Aug 07, 2020, 4:40 AM UTC

Diggsey wrote: post #21

saagarjha wrote: post #7

Earlier quoted context omitted.

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…

> which we know you are using for your project because we gated all the features behind it I don't think that's really fair, or at least hasn't been true for a long time now. Use of the stable channel far exceeds use of nightly according to all the surveys. At my company we've always stuck to the stable channel, and even in my own personal projects where I have no need for stability, I don't remember the last time I…

Anyone doing OS development is still on nightly last I checked but aside from that stable has the features most people need.

Re: First Impressions of Rust

#59

Post by jmillikin » Fri, Aug 07, 2020, 4:41 AM UTC

escardin wrote: post #34

steveklabnik wrote: post #16

Earlier quoted context omitted.

> I guess I expect rustdoc and rustc to be much less tightly coupled Yeah, and that could work in theory. The thing is, rustdoc uses the compiler as a library, so they actually are pretty tightly coupled. This causes a lot of pain but also has a bunch of upsides. I really want to see a rustdoc that is not, but it's gonna take a long time. > That's correct. Cool, I thought so, I just wasn't 100% sure! I think it's int…

> Cool, I thought so, I just wasn't 100% sure! I think it's interesting how different people take away different things here, to me, this demonstrates that you don't have to have namespaces; many of the largest ecosystems do not and have not had them. We did learn a lesson there, just didn't come to the same conclusion that you did. This one is more controversial within the community though, many people do agree with…

You are correct that Maven is one of the first package registries to use a principled approach toward namespacing.

I didn't mention it because -- and this may be rude to Maven -- I consider Maven's coordinates syntax to be closer to "primitive Go" than it's own distinct thing. If software hosted on `example.com/foo/bar` has the package name `com.example.foo/bar` then it's introducing ambiguity without much benefit.

Re: First Impressions of Rust

#60

Post by eddyb » Fri, Aug 07, 2020, 4:49 AM UTC

jmillikin wrote: post #8

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

You can use #[cfg(doc)] and #[cfg_attr(doc, ...)], but it looks like that still requires #![feature(doc_cfg)], so I guess it wouldn't be compatible with stable rustc anyway, until it's stabilized itself.