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

31–40 of 191 posts

Re: First Impressions of Rust

#31

Post by steveklabnik »

jmillikin wrote: post #26
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…

> Yes, but that doesn't change with rustc vs cargo > though; it's still a single rustc invocation to > compile all those files. When using Bazel instead of Cargo the developer can split the build graph into much smaller crates (down to one per module if desired), and still treat the entire assembly as one package. I should emphasize that this is a limitation of Cargo, not rustc. rustc does just fine with big librarie…

Ah, so you're not saying that you take the same project and port it from Cargo to Bazel and it somehow does less work, you're saying that it's easier to make projects with a larger number of smaller crates with Bazel than Cargo? That would be the bit I'm missing, Bazel and Cargo should invoke rustc the same amount of times per crate: once. Cargo doesn't change the compilation model of the language.

(Sorry, I feel a bit dense here, but I am very curious to understand exactly. I haven't used Bazel a ton yet, but am very interested in it.)

Re: First Impressions of Rust

#32

Post by rat9988 »

svnpenn wrote: post #27

This guys website is weird. I first noticed as scrolling doesnt work with the keyboard. Upon inspection of HTML hes using weird shadow dom stuff. Why do people do stuff like this? Its a static site, modern HTML and CSS are huge and can handle nearly any situation.

Scrolling works with keyboard. There is nothing weird about shadow dom, it's part of the standard.

Re: First Impressions of Rust

#33

Post by jmillikin »

steveklabnik wrote: post #31
jmillikin wrote: post #26

Earlier quoted context omitted.

> Yes, but that doesn't change with rustc vs cargo > though; it's still a single rustc invocation to > compile all those files. When using Bazel instead of Cargo the developer can split the build graph into much smaller crates (down to one per module if desired), and still treat the entire assembly as one package. I should emphasize that this is a limitation of Cargo, not rustc. rustc does just fine with big librarie…

Ah, so you're not saying that you take the same project and port it from Cargo to Bazel and it somehow does less work, you're saying that it's easier to make projects with a larger number of smaller crates with Bazel than Cargo? That would be the bit I'm missing, Bazel and Cargo should invoke rustc the same amount of times per crate: once. Cargo doesn't change the compilation model of the language. (Sorry, I feel a b…

Yep, exactly. If I were building rust-fuse with Bazel I would probably split it into about 4 crates (fuse_kernel, fuse_io, protocol, server). This is what I tried to do in Cargo and gave up because of the crates.io packaging requirement.

Re: First Impressions of Rust

#34

Post by escardin »

steveklabnik wrote: post #16
jmillikin wrote: post #8

Earlier quoted context omitted.

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

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

Maven is from 2004 and has namespaces. Maven has it's problems, but the Java package management ecosystem gets many things right that later systems have not.

Re: First Impressions of Rust

#35

Post by swsieber »

jmillikin wrote: post #25
erickt wrote: post #13

> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into. Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works: https://rust-lang.github.io/api-guidelines/future-proofin…

I'm aware of that workaround and do use it in `rust-fuse`[0], but I'm not satisfied for two reasons: * It's not understood by rustdoc, so I have to manually document that the trait is sealed. * It technically violates Rust's rules against private symbols in the public API, so a future version of rustc might deprecate or remove that functionality. [0] https://github.com/jmillikin/rust-fuse/blob/a6ad16d1127d36f8...

I could see it being deprecated with an edition transition and a blessed solution.

Re: First Impressions of Rust

#36

Post by erik_seaberg »

jmgao wrote: post #15
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!

If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

Is that technically UCS-2 rather than UTF-16?

Re: First Impressions of Rust

#37

Post by breatheoften »

An insufficient auto-formatter is very frustrating ...

I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices.

I think that opinion belongs in the past (with the discussion of tabs vs spaces). We have witnessed the existence of sufficiently high quality opinionated code formatters (java, gofmt, prettier, ...) -- and these code formatters without style choices produce a better world.

The way to get there is to find and prefer the non controversial formatting choices -- that means style preferences are abstracted away and consensus building grows from examples of code that everyone agrees is wrong and wants to fix.

The rust formatting issue he highlights makes me really annoyed -- the format chosen by the auto formatter for that sample code is not the best for that situation -- and I'm pretty sure it would be non-controversial for folks to agree on that ... am i right?

I'm doing some swift in xcode after awhile using an ide that lets me have "reformat on save" and the experience of "reformat on save" is good enough that I think it probably should be adopted as a first class goal of language designers -- there should be a language level "reformat on save" story that language designers assume will be used ... Baking in reformat on save as an assumed feature at language design time could allow creation or recovery from "write only" syntaxes -- (nice to write but ambiguous to read) -- either added on purpose or by mistake. Would also allow for really powerful Language evolution cleanup opportunities and the opportunity to introduce semantic changes where old functionality is preserved with complete compatibility until the source file is interactively edited from within an editor (eg the semantic change produces a code diff) ...

Re: First Impressions of Rust

#38

Post by ChrisSD »

erik_seaberg wrote: post #36
jmgao wrote: post #15

Earlier quoted context omitted.

If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

Is that technically UCS-2 rather than UTF-16?

Technically not since ~2000. Windows uses UTF-16 throughout the OS. That is, Windows strings will be encoded and decoded as UTF-16 not UCS-2.

However the tricky bit is that the kernel doesn't enforce this so it's possible for programmers to intentionally make broken UTF-16 strings. A broken UTF-16 string shouldn't be considered UCS-2 just because it happens to be a valid UCS-2 string (otherwise all bit patterns could be called "UCS-2" so long as they are an even number of bytes in length).

Re: First Impressions of Rust

#39

Post by da39a3ee »

breatheoften wrote: post #37

An insufficient auto-formatter is very frustrating ... I think there are very smart older programmers who don't appreciate this fact properly. They sort of have a belief that there does not exist a "sufficiently good" good code formatter for all users -- and so therefore code formatter should have tons of configuration options to satisfy a range of style choices. I think that opinion belongs in the past (with the dis…

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

Re: First Impressions of Rust

#40

Post by throwaway894345 »

jmgao wrote: post #15
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!

If your String type must be valid Unicode (which is true for pretty much every language that isn't C++), it cannot represent all paths. On most unixy filesystems, filenames are arbitrary byte sequences which aren't valid UTF-8, and on windows, NTFS stores filenames as UTF-16, but it allows unpaired surrogates.

What languages require string types to be valid Unicode? Go for example let’s you put anything in a string; it’s only Unicode if you put Unicode into the string including via creating string literals.
Post reply on HN