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

71–80 of 135 posts

Re: Rust Survey 2021 Results

#71

Post by nindalf »

j-pb wrote: post #50
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…

Rust doesn't reuse concepts well. The different capabilities and subsystems are all build from disjoint building blocks, which you could call modular in a sense, but it doesn't make them easy to use, learn, or joyful. The module system, the macro system(s), the core language, the borrow checker. It's all different micro-languages without a shared foundation. I think it's easier to when you compare Rust to simpler lan…

Serious question about Zig’s comptime - isn’t that just like Rust’s const fn, except every function is implicitly opted in to being const?

Where this could be a problem - I write a comptime function, only using other functions that I’ve verified can be executed at compile time. But now the implementation details of those functions (that they’re comptime) has leaked to their definition. Now a change to the impl of those functions could break my code, without the authors of those functions realising it.

Perhaps this is not a problem in practice?

Re: Rust Survey 2021 Results

#72

Post by estebank »

dgellow wrote: post #58
zozbot234 wrote: post #51

Earlier quoted context omitted.

.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…

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.

It's more like

  let v = match x {
    Ok(o) => o,
    Err(e) => return Err(e.into()),
  };
> That feels like something that could be done with a macro.

Indeed. It used to be a macro called try!.

Re: Rust Survey 2021 Results

#73

Post by sirwhinesalot »

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…

Crypto is like the dotcom bubble. Lots of scams, lots of half finished (but well intentioned) crap, and a few projects that might survive into the future and become something useful beyond being a casino with constantly changing odds.

Rust is particularly good for crypto because 1) it is very efficient and 2) ownership semantics let you model things in a way that prevents many of the issues plaguing solidity and etherum.

There will be a crash though, and a lot of the money on Rust will evaporate, but I think this early push will ensure the language survives well into the future.

Re: Rust Survey 2021 Results

#75

Post by estebank »

pornel wrote: post #42
svnpenn wrote: post #24

Earlier quoted context omitted.

> language evolution speed has nothing whatsoever to do with the learning curve I don't think that's true at all. Little by little, ergonomic changes make it in, that are actually quality of life improvements for the end user. Better error messages, smarter faster compiler, better idioms etc. These are all small, but they add up. For someone coming into the language cold, it can be the difference between a terrible e…

Rust keeps making small usability improvements all the time, but the major improvements have already landed in the 2018 edition (smarter borrow checker, modules syntax, forgiving match patterns).

I think everyone in this thread can be in agreement:

* there are language and tooling improvements all the time, that make learning the language easier

* waiting to learn the language can make it easier due to the above

* if you learn Rust today the amount of things you need to learn going forward are few to none, the evolution of the language doesn't make your old knowledge useless

Re: Rust Survey 2021 Results

#76

Post by chrismorgan »

masklinn wrote: post #56
chrismorgan wrote: post #12

Earlier quoted context omitted.

Rust is necessarily a comparatively large language, but I’m content that at present it’s not getting noticeably worse: additions are mostly filling things that could be expected but are missing, plus some focusing on improving ergonomics. Take generic associated types, for example: they’re a major new feature… but are conceptually just removing a potentially surprising limitation. Or const generics: they really are a…

One of the annoying things though is lots of the fills are rather inelegant extensions of APIs. They’re not nonsensical, and TBH I don’t really have a solution, but e.g. allocators support (between custom allocators and faillible allocations) ultimately doubles the size of Vec, or near enough. This makes going through the API a major chore. But maybe this would be better fixed through Rustdoc, by supporting topics /…

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.

Re: Rust Survey 2021 Results

#77

Post by estebank »

pornel wrote: post #44
tialaramex wrote: post #36

Earlier quoted context omitted.

> every method on collections like `map` or `filter` I think you're remembering the various iterator adaptors, but they aren't methods on collections, they work on Iterators as their name implies. Somebody else explained why these methods can't all just return "Iterator" (that isn't a type) but just thought I'd mention you won't find map and filter in Rust's Vec or HashMap types, those methods live in the Iterator tr…

`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.

Re: Rust Survey 2021 Results

#78

Post by pjmlp »

zozbot234 wrote: post #70
pjmlp wrote: post #68

Earlier quoted context omitted.

I beg to differ, and until Rust community acknowledges they are relevant, there are industry domains where C++ will keep its dominance.

Take a look at the C++ community discussion around the feasibility of "ABI breaks". The C++ community is acknowledging the issues, and how they're getting in the way of continued "dominance" in many sectors.

I am fully aware of them, a vocal minority that only cares about FOSS libs.

Why do you think Apple has spent such a big effort making Swift work for shipping binary libraries?

Most devs would just stick with Objective-C, C and C++ otherwise.

Re: Rust Survey 2021 Results

#79

Post by Tobu »

danielscrubs wrote: post #37

How's the compiler speed? I've been so burnt out on hobby programming on SwiftUI because of the horrendous long compilation times. Makes me long for some Pascal. :)

The compiler itself is fine and its performance well managed, with weekly perf triage and efforts driven by profiling[1], but because adding dependencies is effortless and vetting them isn't, dependency trees tend to get large if not careful. In particular, widely used proc-macros (code transformations pulled by popular packages like serde, clap, tokio…) add very heavy dependencies (like syn) to the critical path. As a consequence, downloading and installing a tool from source is often a poor experience.

As far as development experience, cargo clippy / cargo check / rust-analyzer give you the feedback you need without involving codegen (except for any proc-macros in your dependency tree), and incremental compilation makes codegen faster after the first build. Work is also ongoing[2] to make debug-quality codegen faster.

Here is a quality article on the art of keeping a Rust project fast to build: https://matklad.github.io/2021/09/04/fast-rust-builds.html

The overall series on organizing a large project is worth reading as well: https://matklad.github.io/2021/09/05/Rust100k.html

[1]: https://nnethercote.github.io/2021/11/12/the-rust-compiler-h...

[2]: https://bjorn3.github.io/

Re: Rust Survey 2021 Results

#80

Post by Gwypaas »

zozbot234 wrote: post #54
cedws wrote: post #47

Earlier quoted context omitted.

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.

Prefix syntax has drawbacks that were constantly pointed out in that long discussion. In particular, it doesn't compose well in practical scenarios. .await just 'flows' better and in a more intuituve way.

Completely agree. I've used it at work now for about a year and the postfix notation flows perfectly with more intricate usages of futures. Especially with the sense that you construct one, then decide when to await it, or await a collection or whatever. Following the rust style of immutable variables and chaining function calls.

You can even await the same future multiple times in a select statement keeping it executing a bit further each time until it returns, if you do it by mutable reference. Really quite magic.

Now we just need async closures and some nice async style iterators. Something like FuturesOrdered or even FuturesUnordered in an inline iterator style allowing efficient nice composability. Without any of the pitfalls and gotchas those two currently have.

I think that might be what throws many people off? The regular style of method chaining and having the cold futures just be a dead piece of memory you can pass around until actually passed to the runtime?

Post reply on HN