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

Rust 1.48

blog.rust-lang.org

Post reply on HN
Print view View original

81–90 of 119 posts

Re: Rust 1.48

#81

Post by imron »

identity0 wrote: post #45
0-_-0 wrote: post #5

Earlier quoted context omitted.

Not directly related, but when I was learning programming back in highschool (before the Internet) what made it easy was the built in help in Turbo Pascal. You could press F1 over any function or keyword and you were given a detailed description and example of usage. Learning C later using the K&R book and Google was a huge downgrade. Even today I think that language help built into the IDE should be a basic function…

In vim if you press K it will bring up the man page for the word under your cursor. It was very useful when learning C, considering that most libc functions have helpful man pages.

Note for people trying this at home, vim is case sensitive.

I still regularly use this feature to look up libc and other things. You can also type 2K to go to ‘man 2’, or 3K to go to ‘man 3’ etc.

Re: Rust 1.48

#82

Post by CryZe »

trevyn wrote: post #25
LandR wrote: post #24

Earlier quoted context omitted.

This is done quite nicely with clojuredocs being intergrated into Cursive / Intellij. I hover over a Clojure function in INtelliJ and I get a pop up of the clojuredocs with description and example usages for that function. It's great and I don't know why more IDE's don't do this. Why isn't VS linked to the MSDN for C# / .NET ? SO I can get the information for that function / class / library etc straight in my IDE!

Bringing it back, this works great with Rust and VSCode and rust-analyzer: Any function in any crate shows its doc comment complete with markdown formatting when you hover over it.

And you can assign a hotkey to open the docs in the browser for the symbol under the cursor.

Re: Rust 1.48

#83

Post by seabird »

ameixaseca wrote: post #73
kamilafsar wrote: post #57

A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?

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?

Absolutely. I don't think developer ergonomics should take priority over absolutely everything (the modern web arena shows why this is bad) but there are some great technologies that have lost out or are relegated to incredibly niche use cases because their ergonomics are bad to the point where you just can't afford to deal with them unless you really have to.

Ada/SPARK/Ravenscar are a perfect example -- they provide incredibly powerful tools for proven correct programming. They are open source. The ergonomics are nowhere near what you're probably used to having, and that's why odds are very high you've never used them.

Re: Rust 1.48

#84

Post by Ar-Curunir »

ameixaseca wrote: post #73
kamilafsar wrote: post #57

A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?

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?

Once you get to larger programs, having nice tooling for things like language-aware autocomplete, language-aware refactoring, etc is an absolute must. It reduces the amount of time spent on the manual labour, allowing you to actually think about the problem at hand

Re: Rust 1.48

#85

Post by tetha »

ameixaseca wrote: post #73
kamilafsar wrote: post #57

A few months ago I tried Rust but found that the tooling like auto completion and highlighting where still a bit alpha. IIRC I used VSCode with the most popular Rust plugin at the time. Did I miss something or is there some progress being made in that respect?

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-laptop currently has about 20 different rust-doc pages open at the moment to keep track of ... the methods Iter has, the methods IterTools has, Vec has, Slices have, what package FromStr was in again, what methods a str::fmt::Formatter has to implement Display to implement Error (that needs to be imported), where HashMap is, what methods those have...

I've been there multiple times over the last decade or two with multiple languages and rust is compelling enough to work through that.

But if you compare the ergonomics of modern java, go or python IDEs with my current vscode+rust-analyze state, rust isn't winning on IDE ergonomics. At least in my setup.

And that's very much a part of language choice.

Re: Rust 1.48

#86

Post by jedbrown »

steveklabnik wrote: post #39
sitkack wrote: post #35

Earlier quoted context omitted.

I had to suffer with coworkers that would write doctests, bad docs and bad tests together at last! The solution here is to write real tests and hyperlink them in a marked up form to the functions they actually test. Coding inside of a doc string is an epic troll. This is a warning to anyone getting seduced by doctests, stay away! They invert the problem, when one should just write tests, it is a problem with the docu…

What is the distinction between a "real" test and a doc test that you're making? At least in Rust, they are the same thing.

I think it's between a test written inside a comment (where smart IDE features don't apply) versus `#[test]` in normal code, where you have a rich editing environment and instant feedback (including `cargo build` failing immediately on errors).

Perhaps it's just my perception, but doctests (in comments) seem slower to run.

Re: Rust 1.48

#87

Post by steveklabnik »

jedbrown wrote: post #86
steveklabnik wrote: post #39

Earlier quoted context omitted.

What is the distinction between a "real" test and a doc test that you're making? At least in Rust, they are the same thing.

I think it's between a test written inside a comment (where smart IDE features don't apply) versus `#[test]` in normal code, where you have a rich editing environment and instant feedback (including `cargo build` failing immediately on errors). Perhaps it's just my perception, but doctests (in comments) seem slower to run.

Ah; rust-analyzer syntax highlights doc tests (though not perfectly), but the higher order bit of "IDE features don't work as well" makes tons of sense, thanks!

Re: Rust 1.48

#88

Post by geoelectric »

Boulth6 wrote: post #71
0-_-0 wrote: post #5

Earlier quoted context omitted.

Not directly related, but when I was learning programming back in highschool (before the Internet) what made it easy was the built in help in Turbo Pascal. You could press F1 over any function or keyword and you were given a detailed description and example of usage. Learning C later using the K&R book and Google was a huge downgrade. Even today I think that language help built into the IDE should be a basic function…

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 documentation, but theirs were above and beyond.

Re: Rust 1.48

#89

Post by dbaupp »

sitkack wrote: post #35
masklinn wrote: post #20

Earlier quoted context omitted.

I mean doctests are not exactly new. The `doctest` module was added to Python in 2.1, back in 2001. And even that is largely just a weak shade of semi-literate programming, to say nothing of actual literate programming.

I had to suffer with coworkers that would write doctests, bad docs and bad tests together at last! The solution here is to write real tests and hyperlink them in a marked up form to the functions they actually test. Coding inside of a doc string is an epic troll. This is a warning to anyone getting seduced by doctests, stay away! They invert the problem, when one should just write tests, it is a problem with the docu…

I think there's another perspective on doctests, that seems more convincing to me: doctest functionality allows testing for the documentation, not a way of writing tests in documentation.

In particular, it's great if the documentation includes clear and simple examples for learning from, and it's even better if these are validated as working. This means that the focus of the code in documentation is typically different to a test (it doesn't need to include such precise validation or look at all the edge cases or regressions), but it's still really useful to have them automatically run.

Re: Rust 1.48

#90

Post by hobby-coder-guy »

LandR wrote: post #24
0-_-0 wrote: post #5

Earlier quoted context omitted.

Not directly related, but when I was learning programming back in highschool (before the Internet) what made it easy was the built in help in Turbo Pascal. You could press F1 over any function or keyword and you were given a detailed description and example of usage. Learning C later using the K&R book and Google was a huge downgrade. Even today I think that language help built into the IDE should be a basic function…

This is done quite nicely with clojuredocs being intergrated into Cursive / Intellij. I hover over a Clojure function in INtelliJ and I get a pop up of the clojuredocs with description and example usages for that function. It's great and I don't know why more IDE's don't do this. Why isn't VS linked to the MSDN for C# / .NET ? SO I can get the information for that function / class / library etc straight in my IDE!

Integrated
Post reply on HN