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

Rust Survey 2021 Results

blog.rust-lang.org

Post reply on HN
Print view View original

111–120 of 135 posts

Re: Rust Survey 2021 Results

#111

Post by dgb23 »

axiosgunnar wrote: post #109
dgb23 wrote: post #59

Rust is a terribly slow language to write in, especially if you’re trying to fight it in any way - because you‘ll lose. It’s verbose and quite ugly as it tries to appeal to C family programmers while being expression and pattern based. When trying to resolve ownership issues with closures the first time, you‘ll be doubting whether Rust is in fact a language or just a sick elaborate joke that tries to mock you for eve…

> When trying to resolve ownership issues aka fix provably buggy code before it makes it to production?

I was trying to joke about the experience of learning the language rather than making an educated assessment of it.

Re: Rust Survey 2021 Results

#112

Post by dllthomas »

tome wrote: post #65
anyfoo wrote: post #11

Earlier quoted context omitted.

The problem with that is in large parts that Haskell 98 is very outdated, and so relatively basic and absolutely useful extensions are in the same pot as all the experimental stuff. Haskell Prime, essentially the Haskell 98 successor, is supposed to fix that. The first thing I do in almost any Haskell project is enable a bunch of extensions that I consider absolutely essential[1]. Most or all of those should likely b…

I think the GHC2021 group of blessed extensions provides what you want. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...

ScopedTypeVariables by default! Excellent.

Re: Rust Survey 2021 Results

#113

Post by CJefferson »

zozbot234 wrote: post #51
CJefferson wrote: post #43

Earlier quoted context omitted.

Some people (including me) felt how async was added was worrying. Adding ".await" means when I teach Rust we now need to say "x.y is member access. Unless y is 'await'. Then it's something totally different". That's the type of strange rule that C++ has, and if you gather enough of them, languages become very hard to teach. However, async seems to be the only big language feature which effected many things which has…

.await is a postfix keyword - it effectively means "crazy control-flow (monadic) magic is happening here". "?" for failure handling is another bit of postfix syntax, that means something very similar. A good IDE will show it with a different highlight, so that it will never be confused for a struct member or method call. This stuff was discussed by the community for a long time - bikeshedding about syntax is a well-k…

My biggest problem with await is it's very non-obvious if you don't know to expect.

Seeing a '?' is obviously a "new thing", so people go look up what it is (in practice, I would expect any Rust programmer to learn '?' really early, but if they somehow miss learning it, they will know to go look it up).

I've seen beginners assume they were "missing the await member". Of course, once you know it's something new you can learn it. I would have prefered something like .!await, just to make clear it's a "new thing".

Re: Rust Survey 2021 Results

#114

Post by UncleMeat »

pjmlp wrote: post #108
UncleMeat wrote: post #100

Earlier quoted context omitted.

It is true that Rust is competing most directly with C++, but "less complex than C++" might be a true statement about every single language in existence that has more than a dozen professional users.

Kind of, Python, C#, Java have enough stuff on language + standard library to compete with C++. A pub quizz with them would be just as fun.

I personally think those are all nowhere close. There are like ten different ways to initialize values in C++ and they all have slight differences.

Re: Rust Survey 2021 Results

#115

Post by Thiez »

pjmlp wrote: post #107
kibwen wrote: post #97

Earlier quoted context omitted.

Rust feature flags aren't the same as Haskell feature flags. In Haskell you design your own programming language by selecting which extensions to enable. In Rust, feature flags only exist on the unstable nightly compiler and either get folded into the language proper or deprecated and dropped entirely. It's not a combinatorial explosion of interacting extensions, it's a single base for everyone that grows over time.

Really? https://doc.rust-lang.org/cargo/reference/features-examples....

Oh, those features, you are talking about stuff that is included/excluded in libraries. Those have nothing to do with compiler extensions, they don't change the language.

Re: Rust Survey 2021 Results

#116

Post by shirogane86x »

FullyFunctional wrote: post #6

I'm definitely in the camp that worry about the feature/complexity creep. I saw it with Haskell. Haskell 98 is a pretty nice and simple language. GHC Haskell is a monster. This matters when you try to read other people code and the overuse of experimental cool new features becomes a major burden for comprehension. Rust is already a very large language and for intrinsic reasons pile on a load more complexity than Hask…

To be honest, and maybe I'm just an outlier... As someone who uses Haskell for most of my personal stuff (sadly, not for work), I really don't mind the complexity. Haskell98 is... nice, at best, but it lacks a lot for me to be truly pleasant. GHC Haskell with extensions however I find a pleasure to use, and I've always felt like the complexity was well placed, right where I wanted it or needed it. Rust is also nice, but for me personally the extra features are just making it better, not worse.

Re: Rust Survey 2021 Results

#117

Post by steveklabnik »

techdragon wrote: post #101
kibwen wrote: post #94

Earlier quoted context omitted.

Even uninteresting examples are absolutely crucial. I've taught Rust to many, many people, and one of the things that new users rave about is how the docs provide an executable example of every API, no matter how trivial. This especially matters for highly generic functions (which are very common in libstd), where the signature is extremely imposing but the usage is surprisingly simple.

Cannot agree hard enough. Nothing is more deeply infuriating than api documentation that just expects the reader to understand what the author means. The trivial examples of everything means I never feel like I’m guessing when it comes to rust’s standard library. I dearly love working with Python and it’s many included batteries but plenty of the most complex and by extension powerful parts of the Python standard lib…

I'm so glad to hear this.

My guiding principle for the absolute minimum of API documentation is "If I read the documentation and want to use the thing I read, I should be able to copy/paste something from right there to get started with."

This isn't perfect (trait implementations...) but it's nice to see that it's been as helpful as I hoped it would be.

Re: Rust Survey 2021 Results

#118

Post by steveklabnik »

cedws wrote: post #47
CJefferson wrote: post #43

Earlier quoted context omitted.

Some people (including me) felt how async was added was worrying. Adding ".await" means when I teach Rust we now need to say "x.y is member access. Unless y is 'await'. Then it's something totally different". That's the type of strange rule that C++ has, and if you gather enough of them, languages become very hard to teach. However, async seems to be the only big language feature which effected many things which has…

Yeah, the await syntax is just bizarre. One of the worst eyesores of any languages I've personally encountered. An await macro or function would have sufficed but because Rust is still mainly a hipster language with a hipster community, they had to choose a hipster syntax after years of bikeshedding about how to make it absolutely perfect.

> An await macro or function would have sufficed

We tried, and it literally did not suffice.

Re: Rust Survey 2021 Results

#119

Post by kibwen »

Thiez wrote: post #115
pjmlp wrote: post #107

Earlier quoted context omitted.

Really? https://doc.rust-lang.org/cargo/reference/features-examples....

Oh, those features, you are talking about stuff that is included/excluded in libraries. Those have nothing to do with compiler extensions, they don't change the language.

Indeed, perhaps it was bad to name this (er) feature of Cargo with the word "features", since it invites conflation with the unstable #[feature] attribute of nightly Rust, but it has nothing to do with the language.

Re: Rust Survey 2021 Results

#120

Post by isomel »

masklinn wrote: post #84
chrismorgan wrote: post #76

Earlier quoted context omitted.

I feel like rustdoc has been going through cycles of being useful, then growing beyond what the current design can handle well, and needing major changes again. It’s currently not good for discovery in std, because each type has far too many methods and each method has far too much text, with examples added to everything.

That's not wrong. Wrt examples I feel like the examples are mostly obvious / uninteresting and thus have little value, but I’ve been in the field a while so that may well be an experience bias. Alternatively some examples show the neat bits but not clearly because they’re artificial e.g. HashSet::insert demonstrates that it returns a bool via an assert_eq, you have to figure out how cool and useful that is (then grip…

if you have better example suggestions, you can easily make a pull requests with them.
Post reply on HN