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

81–90 of 135 posts

Re: Rust Survey 2021 Results

#81

Post by estebank »

spenczar5 wrote: post #13
alfiedotwtf wrote: post #2

I found this surprising... 59% of respondents sounds huge! "Rust can now safely be classified as a language used by people in professional settings. Of those respondents using Rust, 59% use it at least occasionally at work with 23% using Rust for the majority of their coding. This is a large increase over last year where only 42% of respondents used Rust at work."

I write a bit of Rust, but not for work, and I never heard about this survey. I think that's probably common - the more Rust you write, the more likely it is that you fill out the survey, so the sample is probably very biased towards people who work with it a lot (ie, professionally). Or - you could describe that as biased, at least. Alternatively, maybe the intent of these language surveys is exactly to find out wha…

The self-selection bias effect is why the survey on isolation is not enough to derive meaning on its own. But, looking at the trends over time as the yearly survey is analyzed and compared with the previous ones is useful.

Re: Rust Survey 2021 Results

#82

Post by raverbashing »

kaba0 wrote: post #63
raverbashing wrote: post #38

Earlier quoted context omitted.

> As someone with 20 years of C++ experience... I really don't understand the hatred for OO programming Well, where should I begin: std::cout Is just a nice way of doing things... As the other commenter said, it's not so much OO, but more GoF and how the 2000's OO went. Please tell me why any basic library adds 3 or 4 levels of inheritance just to do something basic like vector or array. "Oh but this is to make thing…

What does std::cout Where is the level of indirection in std::vector implementations? With templates, c++ really doesn’t use virtual dispatch all that much.

> has anything to do with OOP? It is simply operator overloading

It is an example of how they fumbled the implementation of APIs, because this one has very poor usability.

> With templates, c++ really doesn’t use virtual dispatch all that much.

Good, but try to understand why your multiple-inherited vector is not compiling by reading a 3 line error message.

Re: Rust Survey 2021 Results

#83

Post by foldr »

anyfoo wrote: post #11
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…

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…

Out of curiosity, why do you find ScopedTypeVariables essential? I've written a fair amount of Haskell code and never once needed it.

Re: Rust Survey 2021 Results

#84

Post by masklinn »

chrismorgan wrote: post #76
masklinn wrote: post #56

Earlier quoted context omitted.

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.

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 gripe that other langages don’t give this info) separately.

Re: Rust Survey 2021 Results

#85

Post by sanxiyn »

nindalf wrote: post #69
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…

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.

Re: Rust Survey 2021 Results

#86

Post by kristoff_it »

nindalf wrote: post #71
j-pb wrote: post #50

Earlier quoted context omitted.

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

Yes, it can happen. In practice is not a big deal because the kind of stuff that you would want to run at comptime is pretty much all logic that manipulates its inputs without other side-effects, but one could for example add logging to a function and break its ability to be run at comptime (Zig might add in the future ways of solving this problem).

I would say that more in general the problem between public interface vs implementation details is much bigger than any type system and requires humans to negotiate what should be considered part of the public interface through other means (eg: tests, comments). Comptime is one example, another is ABI stability (eg the layout of a struct, or just its size), another could be speed or memory consumption.

Zig doesn't have an official package manager yet, we'll see what happens once we get one and people in the community have to start communicating stability guarantees to their users.

Re: Rust Survey 2021 Results

#87

Post by j-pb »

nindalf wrote: post #71
j-pb wrote: post #50

Earlier quoted context omitted.

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

Kinda, but much more than that and the ergonomics are quite different as the entire language is basically available. For example in Zigs comptime, types are first class citizens which can be queried and operated on. This gives you generics without a lot of type system magic, and even const generics over arbitrary types. All without a macro system or Turing-Complete type checking (similar in flavour to the DeBruijn criterion: the comptime code/higher order proof system is turing complete but the type/core checking is straight-forward).

And yes the problem you describe could exists, but I've not encountered anything like it in practice. But the idea you had there captures the difference between Zigs and Rusts type-system/generics quite nicely:

> Rust tries to proof universally qualified correctness and behaviour of code, i.e. regardless of its context, while zig only proofs you the correctness of specific instantiations.

While this may sound like a bug, I'd argue that it's a feature, as it's YAGNI applied at a type level, and for example allows you to do things like:

  switch (builtin.target.cpu.arch) {
    .x86_64 => //do intel stuff
    .aarch64 => //do arm stuff
    else => @panic("unknown arch!");
  }
With the switch arms that don't apply simply being ignored and never type checked. This allows you to use a basic language construct where C requires a preprocessor and Rust requires macros or compiler magic.

Re: Rust Survey 2021 Results

#88

Post by sanxiyn »

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.

For posterity, this is Rust RFC 2515 type_alias_impl_trait.

Re: Rust Survey 2021 Results

#89

Post by sanxiyn »

LAC-Tech wrote: post #18

I have some time between contracts and I've found myself learning rust. Pros: - Sum types. I am an OO apologist, but trying to use classes in C++ is an exercise in frustration. Sum types map very well to union types and are a better fit for systems programming. - Unit tests built right into the language - it seems like a small thing but it's a hassle in most languages to choose a library, set it up etc. - The above,…

Re: knowledge transfer. Why do you expect your C knowledge to transfer to Rust? Let me tell you clearly: it doesn't. It's not because Rust uses different terminology. Rather, Rust uses different terminology because underlying concept is different, so using same terminology would only lead to confusion.

I found this to be the case: Rust is equally hard to learn, for C programmers and for Java programmers. But C programmers get frustrated more, because while Java programmers don't expect their knowledge to transfer, C programmers have unrealistic and unjustified expectation of knowledge transfer. Actual learning curve is same, just expectations differ.

I wrote about this in 2016: https://sanxiyn.blogspot.com/2016/06/problem-in-rust-adoptio....

Re: Rust Survey 2021 Results

#90

Post by dgellow »

estebank wrote: post #72
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.

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

Ah, thanks for the correction, that's better yes
Post reply on HN