7 ms·
> IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem. Go and C# (.
by WuxiFingerHold 1y ago
> IMO any system where taking a dependency is "easy" and there is no penalty for size or cost is going to eventually lead to a dependency problem.
Go and C# (.NET) are counterexamples. They both have great ecosystems and just as simple and effective package management as Rust or JS (Node). But neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs and even large frameworks like ASP.NET or EF Core.
A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. But again, Go and C# are proving them wrong. A great std lib is a solution, but one that comes with huge efforts that can only be made by large organisations like Google (Go) or Microsoft (C#).
- zahlman 1y ago>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. Python's standard library is big. I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.
- notpushkin 1y agoThere are things added from tine to time, but yeah, some stuff in there just feels dated at this point. I’m still hoping we can get a decently typed argparse with a modern API though (so much better for tiny scripts without deps!)
- voidnap 1y agoI'm thankful argparse exists in pythons stdlib. But argument parsing is not that hard especially for simpler programs. programmers should be able to think for a minute and figure it out instead of always reaching for clap, thats how you get dependency hell. Argument parsing, in partucular, is a great place to start realizing that you can implement what you need without adding a dozen dependencies
- fyrn_ 1y agoHard disagree. Standardized flag parsing is a blessing on us all, do not want to jave to figure out what flag convention the author picked to implement of the many lile one does with non getopt c programs. Don't disagree with the principle, there are a lot of trivial pythong deps, but rolling your own argument parsing is not the way
- voidnap 1y agoAgain, argument parsing is not that hard most of the time. You dont have to make your own conventions. Thats just weird. If youve never thought about it, it might seem like you need an off-the-shelf dependency. But as programmers sometimes we should think a bit more before we make that decision.
- FuckButtons 1y agoYou can, but there’s always a tradeoff, as soon as I’ve added about the 3rd argument, I always wish i had grabbed a library, because i’m not getting payed to reinvent this wheel.
- zahlman 1y agoArgument parsing is absolutely the kind of thing where I'd reach for a third-party library if the standard library didn't provide (and in Python's case, maybe even then - argparse has some really unpleasant behaviours). When you look through library code, it might seem like way more than you'd write yourself, and it probably is. But on a conceptual level you'll probably actually end up using a big chunk of it, or at least see a future use for it. And it doesn't tend to pull in a lot of dependencies. (For example, click only needs colorama, and then only on Windows; and that doesn't appear to bring in anything transitively.) It's a very different story with heavyweight dependencies like Numpy (which include reams of tests, documentation and headers even in the wheels that people are only installing to be a dependency of something else, and covers a truly massive range of functionality including exposing BLAS and LAPACK for people who might just want to multiply some small matrices or efficiently represent an image bitmap), or the more complex ones that end up bringing in multiple things completely unrelated to your project that will never be touched at runtime. (Rich supports a ton of wide-ranging things people might want to do with text in a terminal, and I would guess most clients probably want to do exactly one of those things.)
- kokada 1y agoWhile not everything in Python's stdlib is great (I am looking at you urllib), I would say most of it is good enough. Python is still my favorite language to get stuff done exactly because of that.
- nicce 1y agoMaybe Python 4 will just remove stuff.
- zahlman 1y agoMy personal language design is strongly inspired by what I imagine a Python 4 would look like (but also takes hints from other languages, and some entirely new ideas that wouldn't fit neatly in Python).
- iTokio 1y agoI think this is partially true, but more nuanced than just saying that Rust std lib is lacking. Compared to go and c#, Rust std lib is mostly lacking: - a powerful http lib - serialization But Rust approach, no Runtime, no GC, no Reflection, is making it very hard to provide those libraries. Within these constraints, some high quality solutions emerged, Tokio, Serde. But they pioneered some novel approaches which would have been hard to try in the std lib. The whole async ecosystem still has a beta vibe, giving the feeling of programming in a different language. Procedural macros are often synonymous with slow compile times and code bloat. But what we gained, is less runtime errors, more efficiency, a more robust language. TLDR: trade-offs everywhere, it is unfair to compare to Go/C# as they are languages with a different set of constraints.
- whstl 1y agoI would say compared to other languages Rust feels even more lacking. All those AFAIR need 3rd party packages: Regex, DateTime, base64, argument parsing, url parsing, hashing, random number generation, UUIDs, JSON I'm not saying it's mandatory, but I would expect all those to be in the standard library before there is any http functionality.
- kouteiheika 1y ago> All those AFAIR need 3rd party packages: Regex Regex is not 3rd party (note the 'rust-lang' in the URL): https://github.com/rust-lang/regex https://github.com/rust-lang/regex
- orphea 1y ago3rd party relative to the standard library. In other words: not included.
- okanat 1y agoHaving some of those libraries listed and then not being able to change API or the implementation is what killed modern C++ adoption (along with the language being a patchwork on top of C). As some of the previous commenters said, when you focus your language to make it easy to write a specific type of program, then you make tradeoffs that can trap you in those constraints like having a runtime, a garbage collector and a set of APIs that are ingrained in the stdlib. Rust isn't like that. As a system programmer I want none of them. Rust is a systems programming language. I wouldn't use Rust if it had a bloated stdlib. I am very happy about its stdlib. Being able to swap out the regex, datetime, arg parsing and encoding are a feature. I can choose memory-heavy or cpu-heavy implementations. I can optimize for code size or performance or sometimes neither/both. If the trade-offs were made to appease the easy (web/app) development, it wouldn't be a systems programming language for me where I can use the same async concepts on a Linux system and an embedded MCU. Rust's design enables that, no other language's design (even C++) does. If a web developer wants to use a systems programming language, that's their trade-off for a harder to program language. The similar type safety to Rust's is provided with Kotlin or Swift. Dependency bloat is indeed a problem. Easy inclusion of dependencies is also a contributing factor. This problem can be solved by making dependencies and features granular. If the libraries don't provide the granularity you want, you need to change libraries/audit source/contribute. No free meals.
- athrowaway3z 1y agoNo it doesn't. A large stdlib solves the problems the language is focused on. For C# and Go that is web hosts. Try using them outside that scope and the dependencies start to pile in (Games, Desktop) or they are essentially unused (embedded, phones, wasm)
- merb 1y agoactually dotnet also does not need too many dependencies for games and desktop apps.
- Ygg2 1y agoSo it comes out of box with good renderers, physics engines, localization, input controllers and in-game GUIs?
- 7bit 1y agoThose are extremely specialized dependencies. Whereas in Rust, we talk about e.g. serde, which is included in the std libs for many major languages Are you really trying to compare serde to rendering engines?
- cyber_kinetist 1y agoTo be fair, there is no language that has a framework that contains all of these things... unless you're using one of the game engines like Unity/Unreal. If you're willing to constrain yourself to 2D games, and exclude physics engines (assume you just use one of the Box2D bindings) and also UI (2D gamedevs tend to make their own UI systems anyway)... Then your best bet in the C# world is Monogame (https://monogame.net/ https://monogame.net/), which has lots of successful titles shipped on desktop and console (Stardew Valley, Celeste)
- Ygg2 1y ago> To be fair, there is no language that has a framework that contains all of these things. Depends. There is Godot Script. Seeing how it comes with a game engine. But original claim was > actually dotnet also does not need too many dependencies for games and desktop apps. If you're including languages with big game engines. It's a tautology. Languages with good game engines, have good game engines. But general purpose programming language has very little to gain from including a niche library even if it's the best in business. Imagine if C++ shipped with Unreal.
- fiedzia 1y ago> but neither Go or C# have issues with dependency hell like Rust or even more JavaScript, because they have exceptional std libs They also have a lot narrower scope of use, which means it is easier to create stdlib usable for most people. You can't do it with more generic language.
- djfivyvusn 1y agoI didn't understand the embedded systems argument. Just because a standard lib is large doesn't mean it all ends up in the compilation target.
- kbolino 1y agoIndeed, it has no bearing on binary size at all, because none of it will be included. If you are coming from the perspective where the standard library is entirely unusable to begin with, then improving the standard library is irrelevant at best. It also likely means that at least some time and effort will be taken away from improving the things that you can use to be spent on improving a bunch of things that you can't use. I feel like this is an organizational problem much more than a technical one, though. Rust can be different things to different people, without necessarily forcing one group to compromise overmuch. But some tension is probably inevitable.
- thayne 1y ago> Indeed, it has no bearing on binary size at all, because none of it will be included. That depends on the language. In an interpreted language (including JIT), or a language that depends on a dynamically linked runtime (ex c and c++), it isn't directly included in your app because it is part of the runtime. But you need the runtime installed, and if your app is the only thing that uses that runtime, then the runtime size is effectively adds to your installation size. In languages that statically link the standard library, like go and rust, it absolutely does impact binary size, although the compiler might use some methods to try to avoid including parts of the standard library that aren't used.
- slashdev 1y agoI don’t want a large std lib. It stifles competition and slows the pace of development. Let libraries rise and fall on their own merits. The std lib should limit itself to the basics.