8 ms·

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

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 Haskell (just look at the iterators). I write this as a fan and advocate of Rust.

ekidd 5y ago
I feel like the pace of Rust language evolution slowed down significantly after the 2018 edition and the work on async shortly thereafter. Most of the more recent language changes feel like pretty minor ergonomic improvements, things which always should have worked. I suppose we got const functions (can be evaluated at compile time), and const generics (allow you define fixed-length vectors for size N). But those features are well established in other languages and they don't interact much with anything else. And I'm sure I'm forgetting a few things, but that's sort of my point—subjectively, not a lot has changed for me recently. What I have seen is a lot of good work in the larger ecosystem. And the tooling continues to improve.
zozbot234 5y ago
No worries, Rust has a looong way to go before they reach C++ levels. And the editions system even makes it feasible to pursue some ex-post simplification, though that requires a number of years to complete and cross-linking across editions must be preserved regardless.
stjohnswarts 5y ago
Alas I had fun with rust and made some small apps but as I got deeper I just got scared off by the learning curve. I'm kind of over the hump with c++, javascript and python and I just couldn't do it again. Maybe I will revisit in a few years if it actually slows down.
- pie_flavor 5y ago
  The language evolution speed has nothing whatsoever to do with the learning curve - there's like two major features a year, one of which is only for advanced users. The rolling release cycle just means the tiny incremental improvements arrive sooner. The learning curve has been in place since 1.0 and it only gets harder the more times you give up.
  - svnpenn 5y ago
    > 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 experience and a decent one. No language was born perfect, so let's not pretend Rust is there, or even close.
    - pornel 5y ago
      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).
      - estebank 5y ago
        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
anyfoo 5y ago
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 be incorporated into the new standard, and then the truly experimental stuff stands out as experimental again. Unfortunately it seems that Haskell Prime efforts have slowed down, despite a very active Haskell community in total. I have not looked into details there, though. [1] For example ScopedTypeVariables, where it's hard to imagine for me at least why this would not be the default.
- tome 5y ago
  I think the GHC2021 group of blessed extensions provides what you want. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#extension-GHC2021 https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...
  - dllthomas 5y ago
    ScopedTypeVariables by default! Excellent.
  - anyfoo 5y ago
    That's indeed useful and something that I didn't know about, thank you!
- foldr 5y ago
  Out of curiosity, why do you find ScopedTypeVariables essential? I've written a fair amount of Haskell code and never once needed it.
  - anyfoo 5y ago
    Here's some explanation (not by me, found through search): https://blog.ocharles.org.uk/guest-posts/2014-12-20-scoped-type-variables.html https://blog.ocharles.org.uk/guest-posts/2014-12-20-scoped-t... And among other things, it also enables pattern signatures. The official docs at https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/scoped_type_variables.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/scop... are generally worth a read, they start out with an example of what lexically scoped type variables allow, and follow with the design principles for the extension.
chrismorgan 5y ago
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 major new feature, but in general the code that can use them was a good deal more complex and inconsistent before. You’d have a stronger argument about complexity creep on async—there was lots of demand for it, but it’s not clear that the design that is now frozen was in fact ideal.
- masklinn 5y ago
  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 / sections, and being able to “globally” set which standard topics you’re interested in e.g. I don’t do embedded so generally unsafe and explicit allocations I’m uninterested in, that stuff could be folded away / hidden in both the sidebar & main text.
  - chrismorgan 5y ago
    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.
    - masklinn 5y ago
      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.
dnsco 5y ago
GHC seems to be more of a platform for crafting your own language than rust. Yes, rust nightly has experimental features that can enabled, but they seem to have gone through more vetting and design, whereas in GHC the features seem to be much more exploratory, or more explicitly, research oriented. It seems as though every contemporary haskell program is written in a different language, though rust at least, always has stable, which seems a much more sensible default than GHC's.
- masklinn 5y ago
  > GHC seems to be more of a platform for crafting your own language than rust. It’s always been that tho, one of the motivations behind Haskell was to have a unified basis for FP language research: at the time (late 80s) there were a dozen half-assed half-implemented languages in the space, and the main and most stable platform (Miranda) was proprietary software.
dgellow 5y ago
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
pjmlp 5y ago
I get the same feeling, Rust seems to be going down the path of "#[feature]" collection.
- jamil7 5y ago
  It shares that as well as horrendous compile times with Swift.
  - pjmlp 5y ago
    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, my travel netbook can finally handle small Rust projects without killing the battery.
    - zozbot234 5y ago
      C++ binary libraries are a disaster. At least Rust is honest and tells you to just fall back to the C ABI for interop, and rebuild high-level abstractions around it in code that's built with the project - much like a 'header-only library' in C++.
      - pjmlp 5y ago
        I beg to differ, and until Rust community acknowledges they are relevant, there are industry domains where C++ will keep its dominance.
        zozbot234 5y ago
        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.
shirogane86x 5y ago
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.

ekidd 5y ago

I feel like the pace of Rust language evolution slowed down significantly after the 2018 edition and the work on async shortly thereafter. Most of the more recent language changes feel like pretty minor ergonomic improvements, things which always should have worked. I suppose we got const functions (can be evaluated at compile time), and const generics (allow you define fixed-length vectors for size N). But those features are well established in other languages and they don't interact much with anything else. And I'm sure I'm forgetting a few things, but that's sort of my point—subjectively, not a lot has changed for me recently. What I have seen is a lot of good work in the larger ecosystem. And the tooling continues to improve.

zozbot234 5y ago

No worries, Rust has a looong way to go before they reach C++ levels. And the editions system even makes it feasible to pursue some ex-post simplification, though that requires a number of years to complete and cross-linking across editions must be preserved regardless.

stjohnswarts 5y ago

Alas I had fun with rust and made some small apps but as I got deeper I just got scared off by the learning curve. I'm kind of over the hump with c++, javascript and python and I just couldn't do it again. Maybe I will revisit in a few years if it actually slows down.

pie_flavor 5y ago
The language evolution speed has nothing whatsoever to do with the learning curve - there's like two major features a year, one of which is only for advanced users. The rolling release cycle just means the tiny incremental improvements arrive sooner. The learning curve has been in place since 1.0 and it only gets harder the more times you give up.
- svnpenn 5y ago
  > 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 experience and a decent one. No language was born perfect, so let's not pretend Rust is there, or even close.
  - pornel 5y ago
    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).
    - estebank 5y ago
      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

anyfoo 5y ago

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 be incorporated into the new standard, and then the truly experimental stuff stands out as experimental again. Unfortunately it seems that Haskell Prime efforts have slowed down, despite a very active Haskell community in total. I have not looked into details there, though. [1] For example ScopedTypeVariables, where it's hard to imagine for me at least why this would not be the default.

tome 5y ago
I think the GHC2021 group of blessed extensions provides what you want. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html#extension-GHC2021 https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/cont...
- dllthomas 5y ago
  ScopedTypeVariables by default! Excellent.
- anyfoo 5y ago
  That's indeed useful and something that I didn't know about, thank you!
foldr 5y ago
Out of curiosity, why do you find ScopedTypeVariables essential? I've written a fair amount of Haskell code and never once needed it.
- anyfoo 5y ago
  Here's some explanation (not by me, found through search): https://blog.ocharles.org.uk/guest-posts/2014-12-20-scoped-type-variables.html https://blog.ocharles.org.uk/guest-posts/2014-12-20-scoped-t... And among other things, it also enables pattern signatures. The official docs at https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/scoped_type_variables.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/scop... are generally worth a read, they start out with an example of what lexically scoped type variables allow, and follow with the design principles for the extension.

chrismorgan 5y ago

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 major new feature, but in general the code that can use them was a good deal more complex and inconsistent before. You’d have a stronger argument about complexity creep on async—there was lots of demand for it, but it’s not clear that the design that is now frozen was in fact ideal.

masklinn 5y ago
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 / sections, and being able to “globally” set which standard topics you’re interested in e.g. I don’t do embedded so generally unsafe and explicit allocations I’m uninterested in, that stuff could be folded away / hidden in both the sidebar & main text.
- chrismorgan 5y ago
  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.
  - masklinn 5y ago
    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.

dnsco 5y ago

GHC seems to be more of a platform for crafting your own language than rust. Yes, rust nightly has experimental features that can enabled, but they seem to have gone through more vetting and design, whereas in GHC the features seem to be much more exploratory, or more explicitly, research oriented. It seems as though every contemporary haskell program is written in a different language, though rust at least, always has stable, which seems a much more sensible default than GHC's.

masklinn 5y ago
> GHC seems to be more of a platform for crafting your own language than rust. It’s always been that tho, one of the motivations behind Haskell was to have a unified basis for FP language research: at the time (late 80s) there were a dozen half-assed half-implemented languages in the space, and the main and most stable platform (Miranda) was proprietary software.

dgellow 5y ago

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

pjmlp 5y ago

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

jamil7 5y ago
It shares that as well as horrendous compile times with Swift.
- pjmlp 5y ago
  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, my travel netbook can finally handle small Rust projects without killing the battery.
  - zozbot234 5y ago
    C++ binary libraries are a disaster. At least Rust is honest and tells you to just fall back to the C ABI for interop, and rebuild high-level abstractions around it in code that's built with the project - much like a 'header-only library' in C++.
    - pjmlp 5y ago
      I beg to differ, and until Rust community acknowledges they are relevant, there are industry domains where C++ will keep its dominance.
      - zozbot234 5y ago
        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.

shirogane86x 5y ago

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.