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

121–130 of 191 posts

Re: First Impressions of Rust

#121

Post by Quekid5 »

dthul wrote: post #108
twic wrote: post #100

Earlier quoted context omitted.

As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.

I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference: In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates unde…

> In Maven anybody could publish a package that starts with "com.google".

I don't think that's the case. If you want to get on Maven Central (at least via SonaType OSS) you have to prove that you own an email address on the relevant domain.

If it's your own private package repository, then sure, but then that's not an issue for anybody else.

Re: First Impressions of Rust

#122

Post by quietbritishjim »

Macha wrote: post #109
quietbritishjim wrote: post #97

> it doesn't even properly align the parenthesized expression after line-breaking it: Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distractin…

rustfmt's defaults would agree with you. The kind of alignment it did in OP's example is an option you need to turn on.

In fairness I just tried their example in the Rust Playground [1] online and it gave exactly the formatting they showed [2]

[1] https://play.rust-lang.org/

[2] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Edit: I just realised the example I showed is different in that it doesn't try to line up all the field values (for fields that do fit on one line) so it must actually have some other option set, like you said.

Re: First Impressions of Rust

#124

Post by aorth »

dthul wrote: post #108
twic wrote: post #100

Earlier quoted context omitted.

As a baseline, just do it exactly like in Java/Maven, where it has been absolutely fine for almost twenty years.

I don't know Maven much so please correct me if I'm wrong, but I believe there is a substantial difference: In Maven anybody could publish a package that starts with "com.google". The namespacing proposals I have seen for crates.io assume that namespaces are exclusive to a single entitity though. So once someone that is not Google reserves the "google" namespace, Google itself would not be able to publish crates unde…

I just published my first Java package on Maven Central via Sonatype OSSRH this week and when you sign up you have to verify your "groupId" (aka your namespace) using either DNS TXT records or with com.github.username where they ask you to create a repository with a given name to prove you control it.

So you could easily publish a package using the com.google namespace on your blog or whatever, but not on Maven Central.

Re: First Impressions of Rust

#125

Post by quietbritishjim »

jmillikin wrote: post #116
quietbritishjim wrote: post #97

> it doesn't even properly align the parenthesized expression after line-breaking it: Fair enough if that's not your preference for how parenthesized expressions should be broken across lines, but this quote makes it seem like it's objectively wrong. In fact it's very much a matter of opinion, and personally I hate the style of line breaking that he describes as "properly" aligned because you end up with a distractin…

Your formatting style works too, and rustfmt will switch to it for function calls that exceed the line width limit. rustfmt is not properly handling alignment in combination with hard tabs. It should either break after the open paren and indent both names, or break near the '+' and align them both. Good output if aligned: field: (value_1 + value_2) field: (value_1 + value_2) Good output if indented: field: ( value_1…

Thinking about it, you're probably right. One thing you're missing for your comment is different field name lengths, which is important because you seem to care about alignment of field values:

    field1:                 1
    this_is_a_longer_field: 2
Playing with rustfmt online [1], I found that by default it doesn't do that:

    field1: 1
    this_is_a_longer_field: 2
As a sibling comment says, you must have an option turned on an option for this, and your complaint is that this option isn't working for these nested structs. I guess that's the risk of not using the formatter in its default configuration. But I agree it probably is a bug.

(You've presumably also got an option turned on for tabs. I honestly think that is quite a niche preference nowadays - cue flame war - so I can see that there would be bugs in that option too. But although you bring up tabs in your comment here and in your blog post, I don't see that it's related to the bug you're talking about. Once the formatter has (incorrectly, you argue) decided to format those lines as "one more level of indentation than the line before", it chooses the correct combination of tabs and spaces to do that.)

[1] https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: First Impressions of Rust

#126

Post by EamonnMR »

I'm surprised they didn't mention the elephant in the room: the borrow checking, boxes, and other ways that the code forces you to do the work of making sure your code is bug free before it will compile.

Re: First Impressions of Rust

#127

Post by EamonnMR »

p1necone wrote: post #55
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 he…

I don't think the problem with lifetimes is that they are complex, it's that other languages handle lifetimes for you, but Rust outs to onus on you to manage them. C++ also has complex object lifetimes but if you don't invoke that complexity you don't need to deal with it.

Re: First Impressions of Rust

#128

Post by bananaface »

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…

What's more important IMO is the erasure of time & mental overhead that are normally spent formatting. Formatting is (broadly) a giant waste of time. I honestly do not care if the result is ugly.

And that ignores the synergistic benefits of erasing all style-based co-ordination problems & arguments & bikeshedding & whatever else from the entire codebase. IMO it's a no-brainer.

Re: First Impressions of Rust

#129

Post by jmillikin »

quietbritishjim wrote: post #125
jmillikin wrote: post #116

Earlier quoted context omitted.

Your formatting style works too, and rustfmt will switch to it for function calls that exceed the line width limit. rustfmt is not properly handling alignment in combination with hard tabs. It should either break after the open paren and indent both names, or break near the '+' and align them both. Good output if aligned: field: (value_1 + value_2) field: (value_1 + value_2) Good output if indented: field: ( value_1…

Thinking about it, you're probably right. One thing you're missing for your comment is different field name lengths, which is important because you seem to care about alignment of field values: field1: 1 this_is_a_longer_field: 2 Playing with rustfmt online [1], I found that by default it doesn't do that: field1: 1 this_is_a_longer_field: 2 As a sibling comment says, you must have an option turned on an option for th…

  > You've presumably also got an option turned on for
  > tabs. I honestly think that is quite a niche
  > preference nowadays
gofmt always indents with tabs, so I'd argue that it's not _that_ niche.

One might also argue that, as a zero-cost abstraction for consistently applying a developer's preferred indent depth, they are the most Rust-appropriate option .

  > Once the formatter has (incorrectly, you argue) decided
  > to format those lines as "one more level of indentation
  > than the line before", it chooses the correct
  > combination of tabs and spaces to do that.)
I'm not sure that's the case. It seems to be correctly aligning it when using spaces, so I think the issue is that somewhere it gets confused about whether to indent or align. A lot of very old indenters will treat tabs and spaces as interchangeable, which is why you see so much poorly-formatted C in open-source UNIX tools.

Re: First Impressions of Rust

#130

Post by jmillikin »

panzerklein wrote: post #123

Suggestion for page styling: replace "overflow: scroll" with "overflow: auto" to get rid of unnecessary scrollbars in code blocks. Unless you like them the way they are, of course.

CSS and I have a strained relationship.

https://mstdn.io/@jmillikin/103158451151123313

I'll put this on the list of things to fix next time I go digging at the stylesheet.

Post reply on HN