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

91–100 of 135 posts

Re: Rust Survey 2021 Results

#91

Post by dgellow »

zozbot234 wrote: post #67
dgellow wrote: post #58

Earlier quoted context omitted.

Isn't "?" just a sugar for something like the following? That's how I think about it in my mind at least. // with "?" let v = x?; // without "?" let v = match x { Ok(o) => Ok(o), Err(e) => return Err(e), // exit current scope due to the return }.unwrap(); That feels like something that could be done with a macro.

Yes, that's control flow magic. It was prototyped with a macro, but failure handling comes up all the time in practical programming, and it's important to make it as ergonomic as possible.

I see. I think reading your initial comment I took issue with the hyperbole "crazy control-flow (monadic) magic is happening here".

But yes it is a hidden control flow, and taking in account hidden control flows is inherently more complicated (or at least has a steeper learning curve).

Re: Rust Survey 2021 Results

#92

Post by marcos100 »

dgellow wrote: post #62

That's not covered by the survey but I'm wondering how much of Rust usage is driven by crypto-currency projects. I'm personally completely convinced by the Rust language and the ecosystem, and decided to bet on it as my main tool for the next decade or so, but I'm also a bit worried that a lot of the money for Rust roles comes from crypto-currency projects (an industry I'm now very sceptical of given the amount of sc…

Why would it be worrying? Lack of jobs outside cryptocurrency companies? Language features focused on crypto?

Re: Rust Survey 2021 Results

#93

Post by ChrisSD »

pjmlp wrote: post #46
jamil7 wrote: post #34

Earlier quoted context omitted.

It shares that as well as horrendous compile times with Swift.

The irony being that while C++ is known for its compile times, the ecosystem relience on binary libraries makes it much more tolerable. Microsoft is also shipping pre-compiled projections for Rust/WinRT. Then we have examples like image, that compile rayon twice, with different versions, because we just love to watch third party crates being compiled. However I should also add that compile times have improved greatly…

> Microsoft is also shipping pre-compiled projections for Rust/WinRT.

Eh, sort of. They're basically shipping the Rust equivalent of C header files and import libraries. Whereas before they would parse metadata in a build script which would then generate the Rust code on the fly (which was hell for a number of reasons). And the installed Windows SDK was used for the import libraries.

Re: Rust Survey 2021 Results

#94

Post by kibwen »

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…

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.

Re: Rust Survey 2021 Results

#95

Post by tialaramex »

estebank wrote: post #77
pornel wrote: post #44

Earlier quoted context omitted.

`iterator.map(…)` must return a new wrapper type, because it needs to store the closure somewhere, so it returns struct Map { closure, original_iterator } This fact could have been hidden by making these methods return `impl Iterator`, but it would be strictly less useful/performant in case you needed to store the iterator somewhere, because then you couldn't name the actual type, and would need to work with an abstr…

> because then you couldn't name the actual type I'm sure you know this, but `type Alias = impl Trait;` is on its way which would make naming those possible.

Although that's true, and potentially useful as a feature (not sure I want it, but pretty sure I wouldn't be angry if it was added)..

I don't think that's what your parent was talking about when they say "couldn't name the actual type".

They're saying, suppose I have a function that says it return an Iterator and I realise ah, it's not really returning an Iterator, but some subtype of Iterator - or, in Rust where subtypes don't exist, a type which merely implements Iterator. I now can't talk about the actual type being returned, because that's hidden from me, and it needn't be.

Re: Rust Survey 2021 Results

#96

Post by kibwen »

philosopher1234 wrote: post #28
dgellow wrote: post #26

Earlier quoted context omitted.

I often see people complaining how bloated or large the language is, but I never see specifics. As someone who started learning and using Rust at the beginning of this year I was surprised to find out how simple the language is given its reputation on forums. What makes you feel the language is becoming too large, where is the feature creep, and where is the complexity you're talking about? Are you talking about the…

Complexity is a death by a thousand cuts issue. I suspect most people complaining are going to have a hard time enumerating the many small sources of complexity they encountered.

Rust isn't a complex language by the standards of languages like C++. Complexity arises by features that work together in surprising ways. Rust has a medium-large amount of features (similar to Python (though obviously with a more imposing learning curve than Python)), but those features tend to compose very well, which keeps complexity from ballooning.

Re: Rust Survey 2021 Results

#97

Post by kibwen »

pjmlp wrote: post #29
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…

I get the same feeling, Rust seems to be going down the path of "#[feature]" collection.

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.

Re: Rust Survey 2021 Results

#98

Post by [deleted] »

ChrisSD wrote: post #93
pjmlp wrote: post #46

Earlier quoted context omitted.

The irony being that while C++ is known for its compile times, the ecosystem relience on binary libraries makes it much more tolerable. Microsoft is also shipping pre-compiled projections for Rust/WinRT. Then we have examples like image, that compile rayon twice, with different versions, because we just love to watch third party crates being compiled. However I should also add that compile times have improved greatly…

> Microsoft is also shipping pre-compiled projections for Rust/WinRT. Eh, sort of. They're basically shipping the Rust equivalent of C header files and import libraries. Whereas before they would parse metadata in a build script which would then generate the Rust code on the fly (which was hell for a number of reasons). And the installed Windows SDK was used for the import libraries.

[deleted]

Re: Rust Survey 2021 Results

#99

Post by kibwen »

sanxiyn wrote: post #85
nindalf wrote: post #69

Earlier quoted context omitted.

To my knowledge, most of the people working on Rust, the project, are employed full time at Amazon, Facebook, Google, Microsoft etc. There are a few folks who benefit from sponsorship from some crypto firms but I think that’s the minority. While it’s a legitimate concern that many jobs appear to be from the crypto industry, I wouldn’t worry too much. Whether they’re scams or not, the entire community benefits from th…

Re: blockchain sponsorship. Minority, yes, but not without weight. For example, current Rust language team leader and library team leader are sponsored by blockchain projects. See https://medium.com/concordium/the-devx-initiative-rust-ecosy... for details.

Perhaps I'm asking you to trust me, but I can stake my own reputation on the fact that neither Mara not Josh are in any way compromised by this sort of sponsorship. Both of them have been doing incredible work for years, and while I can't speak to Mara's financial situation, Josh gets sponsored by a ton of different companies to do Rust work (including my own, and we have nothing to do cryptocurrency).

Re: Rust Survey 2021 Results

#100

Post by UncleMeat »

kibwen wrote: post #96
philosopher1234 wrote: post #28

Earlier quoted context omitted.

Complexity is a death by a thousand cuts issue. I suspect most people complaining are going to have a hard time enumerating the many small sources of complexity they encountered.

Rust isn't a complex language by the standards of languages like C++. Complexity arises by features that work together in surprising ways. Rust has a medium-large amount of features (similar to Python (though obviously with a more imposing learning curve than Python)), but those features tend to compose very well, which keeps complexity from ballooning.

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.
Post reply on HN