10 ms·

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

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 stdlib or language features?

philosopher1234 5y ago
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.
- kibwen 5y ago
  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.
  - UncleMeat 5y ago
    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.
    - pjmlp 5y ago
      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.
      - UncleMeat 5y ago
        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.
        pjmlp 5y ago
        Believe me, C# 10, Java 17 and Python 3.7, including standard library and runtimes across 25 - 30 years, have plenty of question material.
CJefferson 5y ago
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 been added.
- cedws 5y ago
  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.
  - zozbot234 5y ago
    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.
    - Gwypaas 5y ago
      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?
j-pb 5y ago
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 languages like Carp or Zig. Carp due to its homoiconicity and lisp heritage allows you to write macros in regular old Carp. Zig doesn't really have Macros, but comptime (compile time) code evaluation, which results in something with a lot of the benefits of a macro system without the drawback of unreadable DSLs, because it too is plain old Zig annotated with `comptime`. Zigs module system is build on Struct name-spacing, so if you know Structs, you know the module system. Its build system is also build on Zig code. My guess is that Rusts origins are partially to be blamed for this, the web is build the same way, disjoint standards that are developed by different groups of people. It's just that just like the web, the sum of the parts is less elegant and usable than each constituent.
- nindalf 5y ago
  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?
  - kristoff_it 5y ago
    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.

philosopher1234 5y ago

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.

kibwen 5y ago
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.
- UncleMeat 5y ago
  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.
  - pjmlp 5y ago
    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.
    - UncleMeat 5y ago
      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.
      - pjmlp 5y ago
        Believe me, C# 10, Java 17 and Python 3.7, including standard library and runtimes across 25 - 30 years, have plenty of question material.

CJefferson 5y ago

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 been added.

cedws 5y ago
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.
- zozbot234 5y ago
  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.
  - Gwypaas 5y ago
    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?

j-pb 5y ago

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 languages like Carp or Zig. Carp due to its homoiconicity and lisp heritage allows you to write macros in regular old Carp. Zig doesn't really have Macros, but comptime (compile time) code evaluation, which results in something with a lot of the benefits of a macro system without the drawback of unreadable DSLs, because it too is plain old Zig annotated with `comptime`. Zigs module system is build on Struct name-spacing, so if you know Structs, you know the module system. Its build system is also build on Zig code. My guess is that Rusts origins are partially to be blamed for this, the web is build the same way, disjoint standards that are developed by different groups of people. It's just that just like the web, the sum of the parts is less elegant and usable than each constituent.

nindalf 5y ago
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?
- kristoff_it 5y ago
  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.