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

100 days with Rust: a series of brick walls

brandur.org

Post reply on HN
Print view View original

271–280 of 323 posts

Re: 100 days with Rust: a series of brick walls

#271

Post by b0rsuk »

vvanders wrote: post #21
b0rsuk wrote: post #19

Earlier quoted context omitted.

They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentati…

You mean like how Vec has a ton of examples? https://doc.rust-lang.org/std/vec/struct.Vec.html FWIW I'm not a huge fan of Python's docs because I can't quickly scan them to track down that one detail about a function I was using. Rust's docs also let you collapse everything which makes browsing them much faster.

Vec may have examples, but lots and lots of other pages don't, and people learn by example. Python library writers add documentation similar to what they're familiar with. Rust library writers are going to document in a way that resembles typical Rust documentation.

That's why I was careful to call it different, not bad. Coming from Python it's a culture shock. They are very different ways of handling documentation, and I take into account the docs are under construction. I'll try to get more used to it, see how it develops, and then form an opinion. So far Rust docs are awkward to use for me.

Re: 100 days with Rust: a series of brick walls

#273

Post by microtonal »

pcwalton wrote: post #145

I'm obviously about as far from the modal Rust user as one can get, but at this point the language has completely melted away into the background. I'm often tempted to write smallish scripts in dynamic languages, but even for those I frequently choose Rust just for the Cargo ecosystem. In particular I never see a reason to use C++ unless I'm contributing to a codebase that's written in it. It takes different programm…

Same here. I used to use Python for small one-off scripts, but I now primarily use Rust. I can write Rust nearly as fast as Python and Go now, plus there are a lot of useful crates for the type of command-line utilities that I write.

For me the benefit is that a Rust utility usually works when it compiles, plus I can easily deploy the binaries on other machines (without going through another pyenv/pip dance).

To give an example: I work a lot with dependency treebanks on CoNLL-X format. Over my past to years with Rust, I have accumulated a bunch of utilities for doing things like paritioning data, merging treebanks, shuffling treebanks, extracting forms/lemmas, checking for cycling graphs, etc. I use them nearly daily:

https://github.com/danieldk/conllx-utils/tree/master/src/bin

Re: 100 days with Rust: a series of brick walls

#274

Post by b0rsuk »

heavenlyblue wrote: post #79
wmonk wrote: post #41

Earlier quoted context omitted.

Coming from well established js libs to python I have found the documentation really hard to deal with. I'm not entirely sure why that is. I really like getting to a repo on github and having the docs in the readme. Both python and rust have their own language specific doc implementations ReadTheDocs and docs.rs (I think). And you usually have to go to a separate site to view them which is fine, but I really dislike…

That's absolutely true. Python documentation severely lacks the necessary detail. Especially the newer doc format on that lighter background.

The Python criticism I heard is that it makes it harder for library writers because they have to dive into source code. But here's the thing, when using a dynamic language with duck typing you don't really care what type specifically something is, only that you can iterate over it. I experienced the difference when porting someone's Python application to Rust. In Python, I didn't care what type the argument is, only what operations are performed. When writing the Rust equivalent, the Rust compiler was quick to complain it wanted to know the exact type.

So I think Python docs are good for dynamic languages, while Rust documentation pleases people used to static languages.

Re: 100 days with Rust: a series of brick walls

#275

Post by jokoon »

The more I read about those new-wave languages, the more I end up thinking that the simple languages like python and C are the clear winners.

I started to learn about rust, but honestly it feels like it has the same design and features of ADA, in term of code correctness. It's a great thing, but I still wonder if it's really useful for everyone. Usually ADA was used in aerospace.

And I still believe C++ has a good future, of course as long as you keep using the good parts.

Re: 100 days with Rust: a series of brick walls

#276

Post by dottrap »

dman wrote: post #260
steveklabnik wrote: post #204

Earlier quoted context omitted.

Rust is certainly not the "end of history" for programming languages. But, taking on that task is for future generations of language devs; it's an open research question today. I can only hope so! I wrote some thoughts about "complexity" and language design here: http://words.steveklabnik.com/the-language-strangeness-budge... I also think the difference between incidental and inherent complexity is important...

One question I had after reading your post is - We currently build languages with purely additive models, ie features can be added to a language over time. Overtime the interaction between features creates "incidental complexity". Was wondering if you know of any languages that have been able to drop old features / ideas in a controlled manner.

Lua has been known to remove things. The language still remains small and clean after over 20 years. The creator has given some talks about how breaking compatibility (e.g removing features) requires its own thought process. There are different types of changes. The easiest to change are the ones that can be detected immediately in existing real world programs whereas the hard changes are the kinds that could go silently undetected by users until it is too late.

Re: 100 days with Rust: a series of brick walls

#277

Post by b0rsuk »

weberc2 wrote: post #65
b0rsuk wrote: post #19

Earlier quoted context omitted.

They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentati…

They problem isn't that they're auto-generated, but that they're poorly organized or displayed (not sure exactly; hard to put my finger on). Everything on godoc.org (e.g., https://godoc.org/github.com/weberc2/httpeasy ) is autogenerated and the readability is top notch. By contrast, Python (which is my day-job language) is a hot mess. Usually everything is on one page, and it's often unclear which class's `__str__` m…

Another thing: lists of function signatures are cumbersome to read. For example:

pub fn last_mut(&mut self) -> Option

pub fn get(&self, index: I) -> Option>::Output>

pub fn get_mut( &mut self, index: I ) -> Option>::Output>

Quite often when I program I try to read the list of operations a type implements and find one that does what I need. The list above is 3 consecutive methods from Vec documentation, and it's actually from collapsed (i.e. abridged) list. I actually cut some of that collapsed info out ("where" sections) because it's not relevant at the moment. What I'm looking for at first is "last_mut", "get", "get_mut". Now the syntax is highlighted so function names are brown, but I still have to fish out function names from that soup. The "collapse" button actually hides text description, not type information.

I find looking at the left side (table of contents) much more effective. But I never felt it was necessary when reading Python documentation.

I don't know, maybe I'm just not used to static languages.

https://doc.rust-lang.org/std/vec/struct.Vec.html

Re: 100 days with Rust: a series of brick walls

#278

Post by pjmlp »

thowawayburnout wrote: post #259
pimeys wrote: post #161

Earlier quoted context omitted.

I've definitely seen much worse with C++. These kind of errors you get though when you use Tokio and combine many different futures together, the future wanting to have static lifetimes and me using a reference to self inside an async block, hopefully solved this year.

I have found while the C++ error messes can be very long, its surprisingly often in the first line of the error message that you see the problem.

Also since clang, at least using recent versions of clang, gcc and VC++ they use heuristics to try to present some kind of meaningful message.

And latest C++14 and C++17 changes also help library writers to error check the type parameters.

Of course those that have to use other compilers still need to face the sea of incomprehensible error messages.

And in any case, better stay away from template meta-programming libraries, at least until modules and concepts eventually land.

Re: 100 days with Rust: a series of brick walls

#279

Post by pjmlp »

tormeh wrote: post #246
jdemler wrote: post #226

Earlier quoted context omitted.

Ever tried changing an owned field in a struct to a borrowed one with lifetimes? Be prepared to change not only the struct and its fields but also everything else where it appears. Yes, the compiler will catch your mistakes, but no, it's not something I love.

I think the Rust devs like C++'s abstraction level. Rust is about the same (more modern), it just catches your errors. I don't think it's possible to make Rust as ergonomic as Python, but I do think it's possible to move a little in that direction without losing Rust's strengths.

Actually that is the goal of the other languages, Swift, Haskell, OCaml, ParaSail...

Influenced by Rust's success bringing affine types into mainstream.

To keep using automatic memory management as their default way of managing memory, while offering some escape hatches based on affine types for low level optimizations.

Re: 100 days with Rust: a series of brick walls

#280

Post by pjmlp »

jokoon wrote: post #275

The more I read about those new-wave languages, the more I end up thinking that the simple languages like python and C are the clear winners. I started to learn about rust, but honestly it feels like it has the same design and features of ADA, in term of code correctness. It's a great thing, but I still wonder if it's really useful for everyone. Usually ADA was used in aerospace. And I still believe C++ has a good fu…

If software companies got recalls and were sued for lack of quality like in other industries, by now everyone would care about how their code gets written.
Post reply on HN