Live data from Hacker News

Rust 1.48

blog.rust-lang.org

101–110 of 119 posts

Re: Rust 1.48

#101
post #36

Earlier quoted context omitted.

steveklabnik is (of course) correct, but you also have to consider the performance cost of a dynamicaly sized slice versus a statically sized array. A situation I've encountered several times already is implementing statically sized FIFOs. At the moment in Rust I can't implement a type "FIFO of depth N" where is a generic, static parameter. My only choices are implementing "FIFO of depth n" where n is provided dynami…

You maybe could write something like this: pub struct Fifo > { and then back it with an array. I learned this trick from whitequark. (Though maybe if you want something other than a slice of bytes, this gets harder... I've used this trick for ringbuffers/mmio only, personally, so YMMV.) That being said real const generics will make this way nicer, eventually.

There's also https://crates.io/crates/generic-array

Re: Rust 1.48

#103
post #32
post #15

Earlier quoted context omitted.

I also like Rustdoc, using markdown and the new linking improvements. It's much better than learning yet another DSL. However, there's one thing I find annoying, and that's the lack of a structure for parameters. Following the `# Arguments:` convention is redundant (I get it's petty, but I'm annoyed every time I write it), but more than that it's error-prone and limiting. Because arguments names are just a convention…

I've seen the argument (not sure if this factored into rustdoc's design or if it's just someone's opinion) that structured per-parameter docs tend toward useless boilerplate, e.g. "foo: a foo object," while a holistic description of the function itself is easier to make useful.

Agreed, I find per-parameter docs useful in dynamic languages such as python, or to a lesser extent useful when the type system is weaker (in C), but in Rust I seldom find them useful. This can be useful to express constraints not present in the type system, for instance `fn matmul(a: Matrix, b: Matrix) -> Matrix` will benefit from a documentation describing the constraints and guarantees on the number of rows and cols of each matrix, since this cannot be expressed in the type system (yet).

Re: Rust 1.48

#104
post #85

Earlier quoted context omitted.

I don't want this to sound like a criticism, but I would like to understand your point of view: do you really consider this a reason for choosing a language over any other? Even if you had to use notepad to program - or had very basic syntax highlighting - wouldn't be what the language provides a more compelling point to make these choices?

I'm currently working myself into rust, and yes, it is certainly a mighty inconvenience. Probably of my setup, I can't tell yet. In java with a good IDE, you can ^Space yourself through a lot of problems without knowing the libraries too much. And even if you don't just pick the first thing sounding right, scrolling through the documentation of the auto suggested methods is very convenient. On the other hand, my dev-…

Since I got a bit engaged there, this has led to my lesson of rust today. Or, the first one: There is the "rust" extension for vscode. This extension can be configured to use rust-analyzer as it's backend and I figured that was what people meant with "use rust-analyzer".

However, there is an extension called "rust-analyzer" and from a few hours of writing rust, it's so much better. Inline type annotations, good type ahead and completion.

Re: Rust 1.48

#105
post #71

Earlier quoted context omitted.

I've seen that with Delphi. The unique factor was that the examples were not a basic call of the function but an actual real world practical sample that usually solved the problem one was looking for.

I was a Delphi programmer for a few years, professionally, when it first came out in the 90s. I worked with their developer products (and for Borland directly on Delphi/Kylix/C++Builder, eventually) until the mid-2000s. I've never seen the match of Borland's docs, before or since, particularly as integrated with the IDE's coding features. There are a number of programming languages and APIs with excellent documentati…

The Delphi IDE help was good but the printed Delphi manuals were just outstanding. I have fond memories of learning much through those manuals.

Re: Rust 1.48

#106

Earlier quoted context omitted.

I was a Delphi programmer for a few years, professionally, when it first came out in the 90s. I worked with their developer products (and for Borland directly on Delphi/Kylix/C++Builder, eventually) until the mid-2000s. I've never seen the match of Borland's docs, before or since, particularly as integrated with the IDE's coding features. There are a number of programming languages and APIs with excellent documentati…

The Delphi IDE help was good but the printed Delphi manuals were just outstanding. I have fond memories of learning much through those manuals.

I have them in print still, including the MS-DOS ones (TP), if you don't have them any longer, they are available at bitsavers.

Re: Rust 1.48

#107
post #99

Earlier quoted context omitted.

Go is the same. Everyone, including the stdlib maintainers seem to think a few lines of comments per method is the same as documentation on how to use the package, best practices, pitfalls, etc.

Rust's stdlib does have a policy of having a runnable code example for every API.

This is the part that blew my mind. For simple functions ("how do I read from a buffer again?"), the code example is more useful than any number of paragraphs of description, especially because its correctness is enforced by the compiler. Switching to learning Node after Rust has been a major step backwards and involves a lot more time on Stack Overflow.

(Unrelated gripe: if I could ban w3schools from my search results, that would be great.)

Re: Rust 1.48

#108
post #98

Earlier quoted context omitted.

So tldr: people don't like writing documentation, and it's hard to make them care.

If you can’t tell a story with text, you won’t be able to tell it with code either. The thing that makes people want better documentation is the same thing that makes it difficult to get. I remember years ago using Ant as a build tool and the only way I figured it out was to Googlestalk the author. Given enough answers to questions in enough places I finally developed a theory of the system. It was still supremely we…

> If you can’t tell a story with text, you won’t be able to tell it with code either.

I couldn't disagree more. Telling a story with words to humans and telling a story with code to a computer are completely different things.

Re: Rust 1.48

#109
post #98

Earlier quoted context omitted.

If you can’t tell a story with text, you won’t be able to tell it with code either. The thing that makes people want better documentation is the same thing that makes it difficult to get. I remember years ago using Ant as a build tool and the only way I figured it out was to Googlestalk the author. Given enough answers to questions in enough places I finally developed a theory of the system. It was still supremely we…

> If you can’t tell a story with text, you won’t be able to tell it with code either. I couldn't disagree more. Telling a story with words to humans and telling a story with code to a computer are completely different things.

You’re not telling a story to a computer. You’re telling it to your coworkers. The people’s code that’s most frustrating to work with share your philosophy. They are often so convinced they’re right that they can’t even hear constructive criticism. That’s not my opinion, that’s the consensus view shared over lunches and coffees with their coworkers, across many jobs.

Re: Rust 1.48

#110

Earlier quoted context omitted.

I was a Delphi programmer for a few years, professionally, when it first came out in the 90s. I worked with their developer products (and for Borland directly on Delphi/Kylix/C++Builder, eventually) until the mid-2000s. I've never seen the match of Borland's docs, before or since, particularly as integrated with the IDE's coding features. There are a number of programming languages and APIs with excellent documentati…

The Delphi IDE help was good but the printed Delphi manuals were just outstanding. I have fond memories of learning much through those manuals.

I had forgotten the “brick” you used to buy with a few CDs (or floppies) and a whole stack of books.

Things sure were heavy before the internet got fast.

Post reply on HN