13 ms·

I've always wanted to learn Rust but have found it devilishly complex compared to the likes of Go, but I appreciate there's not much that can be done about its

I've always wanted to learn Rust but have found it devilishly complex compared to the likes of Go, but I appreciate there's not much that can be done about its complexity this far down the road. My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go. Having to pull in tons of external crates of varying quality and with varying degrees of dependency chains is not particularly pleasant. Having a decent, well maintained, stdlib that contains "the basics" that one would expect in any 21st century programming language is sorely missing from Rust, and from my personal perspective is something that would draw me back to Rust for another go at learning it.

sanxiyn 5y ago
Rust actually tried this. Search for "stdx". For some reasons, it didn't take off. Maybe we should try again.
- silves89 5y ago
  I found stdx to be a useful set of sign-posts. But it's not been updated in three years. E.g. it suggests `error-chain` instead of `anyhow` and `thiserror`.
staticassertion 5y ago
> Having a decent, well maintained, stdlib that contains "the basics" that one would expect in any 21st century programming language is sorely missing from Rust, and from my personal perspective is something that would draw me back to Rust for another go at learning it. What would you like to see in that? Genuinely curious, I've considered putting something together that's just a meta-crate that pulls in some others.
- frockington1 5y ago
  Personally I would like a standard http library that has async and non async methods. One of the things that initially turned me away from Rust was the complexity of finding a library to use for simple http requests. I know this is also a strength, but it makes the intro days incredibly challenging
  - staticassertion 5y ago
    I wonder if that's a discovery issue. Having used rust for years the quick answer would be 'reqwest', but I guess there's not really any way someone would know that just jumping into the language.
    - wongarsu 5y ago
      Crates.io is great, but it certainly has a discoverability issue. Even knowing about reqwest it's far from trivial to conjure up a search that yields reqwest on the first result page. And I'm sorely missing features like "crates that use this also use" and "instead of this crate, others use". If I had infinite time on my hands it would be a fun exercise to try to improve on it.
      - tempest_ 5y ago
        I disagree that is hard to find this. Searching "Http request in rust" for me yields the the rust cookbook on the first result, which is using reqwest! (https://rust-lang-nursery.github.io/rust-cookbook/web/clients/requests.html https://rust-lang-nursery.github.io/rust-cookbook/web/client...) Regardless I agree that crates.io could have some more features but I am not sure how useful I would find a recommendation engine.
        staticassertion 5y ago
        Right, but isn't it a bit of a shame that I search "http" in crates.io, the site that theoretically should be serving the "find a crate" use case, and I don't get suggestions that are useful?
      - dureuill 5y ago
        there is lib.rs that I find much more efficient to discover crates. Requests is currently #6 in its Web programming > HTTP client category[0]. The download counts, number of contributors, version history, and dependent crates is also prominently displayed. [0]: https://lib.rs/web-programming/http-client https://lib.rs/web-programming/http-client
- traceroute66 5y ago
  > What would you like to see in that? Genuinely curious I see someone else has got there before me and my answer would not be dissimilar. Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. Beyond that (if its not there already) basic tools to enable out-of-the-box CLI writing (e.g. flags etc.)
  - bajsejohannes 5y ago
    > Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have: * an outdated HTTP library (look at how "everyone" is using a 3rd party HTTP library in python) * a JSON library no one uses (everyone used XML, now it's out of fashion. And JSON has obvious problems!) * Old cryptographic standards that you'd rather not use
    - FpUser 5y ago
      >"The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have:" Perfect reason for not writing any software. None would work for 20 years without maintenance (there are some exceptions of course).
      - mplanchard 5y ago
        No, it’s the perfect reason for not pulling software into the standard library, which has strong backwards compatibility guarantees and cannot be as cavalier about changing interfaces and deprecations as external crates.
- lumost 5y ago
  A Collections grouping of common data structures and macros would be useful. There are so many different idiomatic ways to instantiate a type in rust that a crate with a common calling convention for most data structures would be very useful.
  - Elinvynia 5y ago
    You mean like this? https://doc.rust-lang.org/std/collections/index.html https://doc.rust-lang.org/std/collections/index.html
    - nicoburns 5y ago
      I think they want something like a ‘map!()’ macro.
    - lumost 5y ago
      Sibling nailed it but I can’t reply on that post. There are variations such as Vec!, map! Macros collect_vec, collect_map etc. It would be great to have a unified interface that exposes a common set of instantiation mechanisms and apis. Other lib authors should be able to implement this api and get the same calling conventions.
- rastignack 5y ago
  good json parsing is important these days. crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Right now in rust we rely on rust bindings to c libs.
  - traceroute66 5y ago
    > crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Indeed. I would almost put my neck above the parapet and say that in the 21st century any programming language worthy of its name should come with decent crypto out of the box. Crypto is no longer an option these days.
  - SAI_Peregrinus 5y ago
    I disagree about golang's crypto being good. It includes insecure functions like md5 and sha1 that have no place in a crypto library. They should be in some other part of the library (maybe add a "legacy" section) or just not included at all. The go stdlib crypto is also makes the (common) mistake of exposing unsafe primitives (like raw AES without a mode of operation needed to use it for encryption) at the top level of their various sections instead of a well-documented "unsafe" or "hazardous" section. And it's missing useful well-vetted high-performance options like AES-OCB (which recently went out of patent).
    - rastignack 5y ago
      Well sha1 and md5 are used all over the place so supporting them makes a lot of sense. Most of your points are related to documentation, and a bit patronizing. For all I care most of the functionality is there, fast and reasonably well designed.
- nicoburns 5y ago
  I would suggest that an opinionated website documenting a curation of crate choices might be better than a crate (which would be a pain technically). I’ve been considering making one if you’d be interested in collaborating.
  - staticassertion 5y ago
    Happy to discuss. I'm sick so I'm being extra terrible about responding to emails (and I'm about to go to sleep at 6am -_-) but feel free to reach out. I could see a website being much simpler to maintain.
  - woile 5y ago
    I was actually thinking as a learning exercise, to go through python docs and create a rust book covering the needs of a python developer with different crates. If the book is versioned you can easily remove and add new crates. But I've been busy at work...
- derkoe 5y ago
  I think serde should be part of the stdlib. A http server and client library is also really a must-have today. Maybe some abstraction for SQL database drivers. Some other candidates include: logging, anync runtime (Tokyo), random generator, regex
  - the_mitsuhiko 5y ago
    Let me give you some contrasting views on this: we already know that serde has (serious) limitations and sooner or later a completely new version will be needed. HTTP and Client library will not make sense unless async is also in the core. Moving async in the core is going to raise serious problems for people trying to port this to new ecosystems and there is not even agreement on exactly how async should continue into the future. In fact, there are people (like me) who are very happily pushing back on moving stuff into the standard library unless it's clear that the code there can live for 30 years. And I do not see this for almost all the things you just mentioned.
    - tempest_ 5y ago
      What are Serde's serious limitations?
      - the_mitsuhiko 5y ago
        You're constrained by the internal serde data model. For instance serde has no bignum in the data model, so you can't express it in that data model which requires awful workarounds. I went into the types of abuses necessary here a bit: https://lucumr.pocoo.org/2021/11/14/abusing-serde/ https://lucumr.pocoo.org/2021/11/14/abusing-serde/
  - deleted 5y ago
    [deleted]
  - heavenlyblue 5y ago
    What being a part of standard library makes the library better?
the_mitsuhiko 5y ago
> My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go. I think many of us are feeling these days that the rust standard library might already be too large and it's better to be very conservative adding stuff there or only after an extended period of time of independent vetting. I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden.
- flippinburgers 5y ago
  Golangs stdlib is very nice to work with.
  - the_mitsuhiko 5y ago
    I don't disagree, and so was Python's standard library in 2003. The issue with standard libraries is that the moment they move past algorithms, data structures and basic IO they are often not lasting for more than 5 years. Even the Go standard library is quickly aging as contexts were not around when it was first created. It will be interesting to see how Go's standard library is going to evolve with Generics and more reliance on contexts.
    - zibzab 5y ago
      > Even the Go standard library is quickly aging If anything, I found go stdlib to age like fine wine. It doesn't do everything under the sun, but what it does it does very well and can easily be extended if needed.
      - yjftsjthsd-h 5y ago
        I think the argument was that Go is still too young to make that argument in the long view.
        tptacek 5y ago
flippinburgers 5y ago
The basics of rust really are not that bad. It gets funky once you start diving deeply into types. If you are just hitting an api and getting json out followed by working with storage etc in AWS, the situation is pretty straightforward.
codeflo 5y ago
Actually, the "batteries included" school of library design was a 20th century idea; the trend in the 21st century in all other ecosystems very much goes in the opposite direction: fewer features in the stdlib to allow faster iteration, and strong package managers that make it seemless to mix and match packages. Go just dodges that trend and does the 20th century thing, as it does for many other design decisions. Just as it has common data structures as hardcoded language features, instead of the ability to build them as abstractions. To be clear: One can take the position that the trends go in the wrong direction and Go is right to reverse them -- that's a matter of opinion. I just don't think it's fair to argue Go is the language that does the more modern thing.
- wakeupcall 5y ago
  Hard disagree. The main reason I've wrote so much python in the last 10 years is due to it's stdlib being comprehensive enough to do 95% of the tasks I need without adding any dependency. This despite the fact that I never was super-fond of python's syntax and ideology, although I just learned to accept it. I was writing a ton of perl before that, and with python I could do more with less "CPAN". I would have _never_ made the switch without. A good stdlib ensures decent performance, stability and overall code quality to your project. Without that, you need tons of dependencies along with version pinning (as developers nowdays understand semver even less than 20 years ago) and duplication due to your dependencies picking different packages as their own base due to the lacking stdlib. I hate the sort of ecosystem which is built around this pattern. See npm for one extreme, although I see cargo not too far away in the horizon.
  - hiptobecubic 5y ago
    Ok but you didn't contest anything in their argument as far as I can tell.
  - cies 5y ago
    > A good stdlib ensures decent performance, stability and overall code quality to your project. How then? I can give counter examples of the opposite easily: An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. An extensive stdlib ensures overall code quality to your project. This one I agree most with, but because the std lib sets the idiomatic writing style of the project. I'm not how important the size of the std is for this to work.
jonathanstrange 5y ago
I learned Rust only to abandon it afterwards. It's not worth the effort, especially if you already know Ada and various memory-managed languages like CommonLisp and Go. Although I'm sure sure these exist, I've never written a program that would benefit from not having a garbage collector.
- 2143 5y ago
  If your program benefits from having a garbage collector (GC) — which I guess is a lot of programs — then by all means go for a GC-ed language. It's one less thing to worry about. However, the garbage collection process itself sometimes introduce a noticeable pause in execution, which can be unacceptable in certain applications. Especially in critical real-time applications. (That GC pause won't be a problem if your program mostly just waits for user input the majority of the time). For an extreme example, you don't want your car's airbag controller to be paused for garbage collecting during a crash.
  - School-Cotton 5y ago
    Pause-free GCs have existed for years, for what it’s worth. They do still have some CPU overhead in many cases, but it’s a question of throughput, not latency.
  - jonathanstrange 5y ago
    I agree, of course, there are some domains where garbage collection can be problematic, most notably game engines and DSP. High integrity applications and hard real-time systems like the airbag controller you mention usually go a bit further, it is often forbidden to dynamically allocate any memory, or at very least it may only be requested once at the start.
  - Narishma 5y ago
    They also introduce (sometimes quite large) memory overhead.
akavel 5y ago
Two thoughts, as a very recent convert from expert-level Go to all-around-the-place-level Rust: (For some context, interested in Rust since 2009, similar as with Go, but not involved at all, whereas contributor to Go pre-1.0.) First thing, is that I was frustrated with lack of simplicity vs. Go for a long time as well. Finally, recently I got it: AFAIU it's a case of different priorities. In the triangle of simplicity-safety-performance, Go loves all of them, but in case of conflict, chooses simplicity (thus, most notably/infamously, we get GC and nil). Rust also loves all of them, but in case of conflict chooses safety AND performance. What's freaking crazy IMO is the "AND" here, which I see as a huge thing. And it instantly also explains to me a tension in the Rust community between safety and performance camps, infamously most visible around usage of the 'unsafe' keyword. Yet in a barely-managed marriage between safety and performance, simplicity is the heartily beloved friend, who still just gets silently shown out of the room when a serious row starts between the couple, until they're ready to open the door back, and with patient smiles listen to some friendly suggestions. Secondly, I bumped my head into a wall a few times until recently I tried the O'Reilly "Programming in Rust (2nd ed.)" on some recommendation from Reddit. The "2nd ed." part is important here, because it covers a few relatively recent important additions to Rust, that I found I was teeth-gnashing frustrated without before (coming from Go), namely: anyhow, thiserror, and (to a lesser extent) async. Edit: Two bonus personal recommendations for the book: (1) I got a job in Rust after going through it and then testing my abilities on some personal project, where I finally felt I'm managing to do regular non-fancy-shmancy (i.e. web, sqlite, GUI via iced, but no macros and avoiding lifetimes whenever possible - if curious, the project is: https://github.com/akavel/backerrs https://github.com/akavel/backerrs) coding, and can work around lifetime issues (somewhat faster or slower but can, and often just falling back to .clone()/Rc); though in all honesty, they kind of didn't really test my Rust skills, to my huge surprise, and trusted my smarts shown in Go & C++ experience + passion for the project; (2) I'm carrying the book with me to workplace every day and definitely checking things in it from time to time.
- jamincan 5y ago
  Bryan Cantrill has an interesting talk that discusses various languages in terms of their values that you might finding interesting: https://www.youtube.com/watch?v=2wZ1pCpJUIM https://www.youtube.com/watch?v=2wZ1pCpJUIM
Ygg2 5y ago
The ONLY lib missing from stdlib. Is the time library. Maybe unified interface to work with DB. Cryptographic functions while useful age poorly, and require constant change. Serde while extremely useful won't fit every usecase. Sometimes you want something smaller or faster. Http(s) clients also tend to age poorly. Python also had http client/server in std lib that aged like warm milk. For a thing to be in std, it needs to be imo something you don't want implented in several different ways. Something that is essentially solved and will change very little over time.
- pjmlp 5y ago
  And error handling, async runtime,...
  - Ygg2 5y ago
    I thought that was being added (error handling). Async runtime is neat, but it tends to be more trouble than it's worth. And I don't think any design has emerged as universal way to deal with it. Time however has/should have a single representation.
    - pjmlp 5y ago
      It is being added, but not yet there in 2021 edition. Without a proper async runtime it is very hard to write portable asynchronous code, as each library is tied to a specific runtime.
- dhosek 5y ago
  Unicode handling. There are two big projects on that front in the crate space, but this is, for me at least, the biggest gap in the std lib (but then I'm writing a text processing/formatting system so it matters a lot to me).
  - Ygg2 5y ago
    I don't think proper Unicode handling is a thing that can be solved universally. Do you need it for formatting, to count characters, for currency extraction, time formatting, etc.
dragonwriter 5y ago
I’d rather see more of the stdlib usable on wasm32-unknown-unknown, or at least wasm32-wasi, than a generically bigger stdlib.

sanxiyn 5y ago

Rust actually tried this. Search for "stdx". For some reasons, it didn't take off. Maybe we should try again.

silves89 5y ago
I found stdx to be a useful set of sign-posts. But it's not been updated in three years. E.g. it suggests `error-chain` instead of `anyhow` and `thiserror`.

staticassertion 5y ago

> Having a decent, well maintained, stdlib that contains "the basics" that one would expect in any 21st century programming language is sorely missing from Rust, and from my personal perspective is something that would draw me back to Rust for another go at learning it. What would you like to see in that? Genuinely curious, I've considered putting something together that's just a meta-crate that pulls in some others.

frockington1 5y ago
Personally I would like a standard http library that has async and non async methods. One of the things that initially turned me away from Rust was the complexity of finding a library to use for simple http requests. I know this is also a strength, but it makes the intro days incredibly challenging
- staticassertion 5y ago
  I wonder if that's a discovery issue. Having used rust for years the quick answer would be 'reqwest', but I guess there's not really any way someone would know that just jumping into the language.
  - wongarsu 5y ago
    Crates.io is great, but it certainly has a discoverability issue. Even knowing about reqwest it's far from trivial to conjure up a search that yields reqwest on the first result page. And I'm sorely missing features like "crates that use this also use" and "instead of this crate, others use". If I had infinite time on my hands it would be a fun exercise to try to improve on it.
    - tempest_ 5y ago
      I disagree that is hard to find this. Searching "Http request in rust" for me yields the the rust cookbook on the first result, which is using reqwest! (https://rust-lang-nursery.github.io/rust-cookbook/web/clients/requests.html https://rust-lang-nursery.github.io/rust-cookbook/web/client...) Regardless I agree that crates.io could have some more features but I am not sure how useful I would find a recommendation engine.
      - staticassertion 5y ago
        Right, but isn't it a bit of a shame that I search "http" in crates.io, the site that theoretically should be serving the "find a crate" use case, and I don't get suggestions that are useful?
    - dureuill 5y ago
      there is lib.rs that I find much more efficient to discover crates. Requests is currently #6 in its Web programming > HTTP client category[0]. The download counts, number of contributors, version history, and dependent crates is also prominently displayed. [0]: https://lib.rs/web-programming/http-client https://lib.rs/web-programming/http-client
traceroute66 5y ago
> What would you like to see in that? Genuinely curious I see someone else has got there before me and my answer would not be dissimilar. Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. Beyond that (if its not there already) basic tools to enable out-of-the-box CLI writing (e.g. flags etc.)
- bajsejohannes 5y ago
  > Stuff to be able to talk to web services (because let's face it, any modern software will be doing that) is the obvious low hanging fruit, i.e. HTTP, JSON, Crypto etc. The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have: * an outdated HTTP library (look at how "everyone" is using a 3rd party HTTP library in python) * a JSON library no one uses (everyone used XML, now it's out of fashion. And JSON has obvious problems!) * Old cryptographic standards that you'd rather not use
  - FpUser 5y ago
    >"The problem with adding this is that in 10-20 years it's not so useful anymore. Then you'd have:" Perfect reason for not writing any software. None would work for 20 years without maintenance (there are some exceptions of course).
    - mplanchard 5y ago
      No, it’s the perfect reason for not pulling software into the standard library, which has strong backwards compatibility guarantees and cannot be as cavalier about changing interfaces and deprecations as external crates.
lumost 5y ago
A Collections grouping of common data structures and macros would be useful. There are so many different idiomatic ways to instantiate a type in rust that a crate with a common calling convention for most data structures would be very useful.
- Elinvynia 5y ago
  You mean like this? https://doc.rust-lang.org/std/collections/index.html https://doc.rust-lang.org/std/collections/index.html
  - nicoburns 5y ago
    I think they want something like a ‘map!()’ macro.
  - lumost 5y ago
    Sibling nailed it but I can’t reply on that post. There are variations such as Vec!, map! Macros collect_vec, collect_map etc. It would be great to have a unified interface that exposes a common set of instantiation mechanisms and apis. Other lib authors should be able to implement this api and get the same calling conventions.
rastignack 5y ago
good json parsing is important these days. crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Right now in rust we rely on rust bindings to c libs.
- traceroute66 5y ago
  > crypto is a must too. golang's crypto is really good (ssh, tls, sha, md5..) Indeed. I would almost put my neck above the parapet and say that in the 21st century any programming language worthy of its name should come with decent crypto out of the box. Crypto is no longer an option these days.
- SAI_Peregrinus 5y ago
  I disagree about golang's crypto being good. It includes insecure functions like md5 and sha1 that have no place in a crypto library. They should be in some other part of the library (maybe add a "legacy" section) or just not included at all. The go stdlib crypto is also makes the (common) mistake of exposing unsafe primitives (like raw AES without a mode of operation needed to use it for encryption) at the top level of their various sections instead of a well-documented "unsafe" or "hazardous" section. And it's missing useful well-vetted high-performance options like AES-OCB (which recently went out of patent).
  - rastignack 5y ago
    Well sha1 and md5 are used all over the place so supporting them makes a lot of sense. Most of your points are related to documentation, and a bit patronizing. For all I care most of the functionality is there, fast and reasonably well designed.
nicoburns 5y ago
I would suggest that an opinionated website documenting a curation of crate choices might be better than a crate (which would be a pain technically). I’ve been considering making one if you’d be interested in collaborating.
- staticassertion 5y ago
  Happy to discuss. I'm sick so I'm being extra terrible about responding to emails (and I'm about to go to sleep at 6am -_-) but feel free to reach out. I could see a website being much simpler to maintain.
- woile 5y ago
  I was actually thinking as a learning exercise, to go through python docs and create a rust book covering the needs of a python developer with different crates. If the book is versioned you can easily remove and add new crates. But I've been busy at work...
derkoe 5y ago
I think serde should be part of the stdlib. A http server and client library is also really a must-have today. Maybe some abstraction for SQL database drivers. Some other candidates include: logging, anync runtime (Tokyo), random generator, regex
- the_mitsuhiko 5y ago
  Let me give you some contrasting views on this: we already know that serde has (serious) limitations and sooner or later a completely new version will be needed. HTTP and Client library will not make sense unless async is also in the core. Moving async in the core is going to raise serious problems for people trying to port this to new ecosystems and there is not even agreement on exactly how async should continue into the future. In fact, there are people (like me) who are very happily pushing back on moving stuff into the standard library unless it's clear that the code there can live for 30 years. And I do not see this for almost all the things you just mentioned.
  - tempest_ 5y ago
    What are Serde's serious limitations?
    - the_mitsuhiko 5y ago
      You're constrained by the internal serde data model. For instance serde has no bignum in the data model, so you can't express it in that data model which requires awful workarounds. I went into the types of abuses necessary here a bit: https://lucumr.pocoo.org/2021/11/14/abusing-serde/ https://lucumr.pocoo.org/2021/11/14/abusing-serde/
- deleted 5y ago
  [deleted]
- heavenlyblue 5y ago
  What being a part of standard library makes the library better?

the_mitsuhiko 5y ago

> My other big beef with Rust is its lack of a comprehensive stdlib, unlike Go. I think many of us are feeling these days that the rust standard library might already be too large and it's better to be very conservative adding stuff there or only after an extended period of time of independent vetting. I have yet to not experience that standard libraries turn into very stale and outdated things relatively quickly that carries an enormous maintenance burden.

flippinburgers 5y ago
Golangs stdlib is very nice to work with.
- the_mitsuhiko 5y ago
  I don't disagree, and so was Python's standard library in 2003. The issue with standard libraries is that the moment they move past algorithms, data structures and basic IO they are often not lasting for more than 5 years. Even the Go standard library is quickly aging as contexts were not around when it was first created. It will be interesting to see how Go's standard library is going to evolve with Generics and more reliance on contexts.
  - zibzab 5y ago
    > Even the Go standard library is quickly aging If anything, I found go stdlib to age like fine wine. It doesn't do everything under the sun, but what it does it does very well and can easily be extended if needed.
    - yjftsjthsd-h 5y ago
      I think the argument was that Go is still too young to make that argument in the long view.
      - tptacek 5y ago

flippinburgers 5y ago

The basics of rust really are not that bad. It gets funky once you start diving deeply into types. If you are just hitting an api and getting json out followed by working with storage etc in AWS, the situation is pretty straightforward.

codeflo 5y ago

Actually, the "batteries included" school of library design was a 20th century idea; the trend in the 21st century in all other ecosystems very much goes in the opposite direction: fewer features in the stdlib to allow faster iteration, and strong package managers that make it seemless to mix and match packages. Go just dodges that trend and does the 20th century thing, as it does for many other design decisions. Just as it has common data structures as hardcoded language features, instead of the ability to build them as abstractions. To be clear: One can take the position that the trends go in the wrong direction and Go is right to reverse them -- that's a matter of opinion. I just don't think it's fair to argue Go is the language that does the more modern thing.

wakeupcall 5y ago
Hard disagree. The main reason I've wrote so much python in the last 10 years is due to it's stdlib being comprehensive enough to do 95% of the tasks I need without adding any dependency. This despite the fact that I never was super-fond of python's syntax and ideology, although I just learned to accept it. I was writing a ton of perl before that, and with python I could do more with less "CPAN". I would have _never_ made the switch without. A good stdlib ensures decent performance, stability and overall code quality to your project. Without that, you need tons of dependencies along with version pinning (as developers nowdays understand semver even less than 20 years ago) and duplication due to your dependencies picking different packages as their own base due to the lacking stdlib. I hate the sort of ecosystem which is built around this pattern. See npm for one extreme, although I see cargo not too far away in the horizon.
- hiptobecubic 5y ago
  Ok but you didn't contest anything in their argument as far as I can tell.
- cies 5y ago
  > A good stdlib ensures decent performance, stability and overall code quality to your project. How then? I can give counter examples of the opposite easily: An extensive stdlib ensures decent performance: https://stackoverflow.com/questions/31548680/why-is-python-3-is-considerably-slower-than-python-2 https://stackoverflow.com/questions/31548680/why-is-python-3... An extensive stdlib ensures stability: i'm not even sure how, with good version pinning it should always work, regardless of the it being std lib or otherwise. An extensive stdlib ensures overall code quality to your project. This one I agree most with, but because the std lib sets the idiomatic writing style of the project. I'm not how important the size of the std is for this to work.

jonathanstrange 5y ago

I learned Rust only to abandon it afterwards. It's not worth the effort, especially if you already know Ada and various memory-managed languages like CommonLisp and Go. Although I'm sure sure these exist, I've never written a program that would benefit from not having a garbage collector.

2143 5y ago
If your program benefits from having a garbage collector (GC) — which I guess is a lot of programs — then by all means go for a GC-ed language. It's one less thing to worry about. However, the garbage collection process itself sometimes introduce a noticeable pause in execution, which can be unacceptable in certain applications. Especially in critical real-time applications. (That GC pause won't be a problem if your program mostly just waits for user input the majority of the time). For an extreme example, you don't want your car's airbag controller to be paused for garbage collecting during a crash.
- School-Cotton 5y ago
  Pause-free GCs have existed for years, for what it’s worth. They do still have some CPU overhead in many cases, but it’s a question of throughput, not latency.
- jonathanstrange 5y ago
  I agree, of course, there are some domains where garbage collection can be problematic, most notably game engines and DSP. High integrity applications and hard real-time systems like the airbag controller you mention usually go a bit further, it is often forbidden to dynamically allocate any memory, or at very least it may only be requested once at the start.
- Narishma 5y ago
  They also introduce (sometimes quite large) memory overhead.

akavel 5y ago

Two thoughts, as a very recent convert from expert-level Go to all-around-the-place-level Rust: (For some context, interested in Rust since 2009, similar as with Go, but not involved at all, whereas contributor to Go pre-1.0.) First thing, is that I was frustrated with lack of simplicity vs. Go for a long time as well. Finally, recently I got it: AFAIU it's a case of different priorities. In the triangle of simplicity-safety-performance, Go loves all of them, but in case of conflict, chooses simplicity (thus, most notably/infamously, we get GC and nil). Rust also loves all of them, but in case of conflict chooses safety AND performance. What's freaking crazy IMO is the "AND" here, which I see as a huge thing. And it instantly also explains to me a tension in the Rust community between safety and performance camps, infamously most visible around usage of the 'unsafe' keyword. Yet in a barely-managed marriage between safety and performance, simplicity is the heartily beloved friend, who still just gets silently shown out of the room when a serious row starts between the couple, until they're ready to open the door back, and with patient smiles listen to some friendly suggestions. Secondly, I bumped my head into a wall a few times until recently I tried the O'Reilly "Programming in Rust (2nd ed.)" on some recommendation from Reddit. The "2nd ed." part is important here, because it covers a few relatively recent important additions to Rust, that I found I was teeth-gnashing frustrated without before (coming from Go), namely: anyhow, thiserror, and (to a lesser extent) async. Edit: Two bonus personal recommendations for the book: (1) I got a job in Rust after going through it and then testing my abilities on some personal project, where I finally felt I'm managing to do regular non-fancy-shmancy (i.e. web, sqlite, GUI via iced, but no macros and avoiding lifetimes whenever possible - if curious, the project is: https://github.com/akavel/backerrs https://github.com/akavel/backerrs) coding, and can work around lifetime issues (somewhat faster or slower but can, and often just falling back to .clone()/Rc); though in all honesty, they kind of didn't really test my Rust skills, to my huge surprise, and trusted my smarts shown in Go & C++ experience + passion for the project; (2) I'm carrying the book with me to workplace every day and definitely checking things in it from time to time.

jamincan 5y ago
Bryan Cantrill has an interesting talk that discusses various languages in terms of their values that you might finding interesting: https://www.youtube.com/watch?v=2wZ1pCpJUIM https://www.youtube.com/watch?v=2wZ1pCpJUIM

Ygg2 5y ago

The ONLY lib missing from stdlib. Is the time library. Maybe unified interface to work with DB. Cryptographic functions while useful age poorly, and require constant change. Serde while extremely useful won't fit every usecase. Sometimes you want something smaller or faster. Http(s) clients also tend to age poorly. Python also had http client/server in std lib that aged like warm milk. For a thing to be in std, it needs to be imo something you don't want implented in several different ways. Something that is essentially solved and will change very little over time.

pjmlp 5y ago
And error handling, async runtime,...
- Ygg2 5y ago
  I thought that was being added (error handling). Async runtime is neat, but it tends to be more trouble than it's worth. And I don't think any design has emerged as universal way to deal with it. Time however has/should have a single representation.
  - pjmlp 5y ago
    It is being added, but not yet there in 2021 edition. Without a proper async runtime it is very hard to write portable asynchronous code, as each library is tied to a specific runtime.
dhosek 5y ago
Unicode handling. There are two big projects on that front in the crate space, but this is, for me at least, the biggest gap in the std lib (but then I'm writing a text processing/formatting system so it matters a lot to me).
- Ygg2 5y ago
  I don't think proper Unicode handling is a thing that can be solved universally. Do you need it for formatting, to count characters, for currency extraction, time formatting, etc.

dragonwriter 5y ago

I’d rather see more of the stdlib usable on wasm32-unknown-unknown, or at least wasm32-wasi, than a generically bigger stdlib.