Hacker News Reader

Comment by resoluteteeth | Hacker News Reader

When I first used python like 20 years ago I was blown away by how much functionality was blown in, and it can be annoying using languages where even the most basic functionality involves downloading 50 packages from the internet, but on the other hand the standard library does seem to be a mess now.

View on HN

I found that attractive when I first learned Python, but when I (much more recently) started picking up Rust, I was blown away by how easy and normal it is to use external packages: the build tool and package manager are the same thing and shipped with the language, the hello-world-equivalent docs assume you're using it, and even the Rust compiler and standard library themselves can (carefully) depend on external packages. Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole. (Rust is not the only language that does this - my impression is Node/NPM and Swift, at least, are similar - but it's the one I happen to be familiar with.)

In Python's defense, this was not obvious at the time; my understanding is Rust came to this approach by looking at the experience of Python and other languages. When Python's standard library was first being written, there were no easy package managers for any language, and the normal thing to do for installing dependencies in e.g. C was to grab random tarballs and figure out how to build and deploy them yourself. So avoiding that process made perfect sense.

> Having run up against limits of the Python standard library several times in years of writing production software in it and not just learning it, I find the batteries-not-includes-but-easy-to-install approach better on the whole.

Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network. Many networks were essentially "airgapped", so it's not like you could just ignore the rules. The bureaucratic process alone meant that we preferred large bundles like Anaconda or Qt. Trying to use Cargo as it is typically used and documented would be a complete non-starter.

Yes, my own employer is similar (you don't need permission, but production systems have no internet access and so you need to pre-download all your tarballs etc.), and cargo doesn't work right. But I think there is work on pointing cargo at an internal mirror.

We do have an internal PyPI mirror (with devpi) and we point `pip` at that, and it works pretty well.

Hm, Cargo should absolutely work in this environment; it’s required by the Firefox and Debian build systems, for example.

(Pointing at an internal mirror is now stable. Setting up that mirror is the hard part.)

>Obviously it doesn't apply to everyone, and it certainly doesn't apply to most startups or open source developers, but I spent most of the last 20 years working in environments where you have to get permission for every third party library you bring on to the network.

Situations like this will really make you appreciate "batteries included". I think this particular issue is fairly revealing of the attitudes common among programmers of different languages. I think it's a good thing to be skeptical of a program pulling in a bunch of standard libraries over the Internet. It worries me when I find something on Github I want to try and I can't download and compile it without it pulling in 30 or 100 other libraries that I haven't looked at or decided to trust come along for the ride. I don't like that way of doing software, and unfortunately it's the norm in node and starting to become a norm in Rust as well. Real security fails have been caused this way in node's case at least.

Even in cases when Python programs depend on external libraries, I usually don't need to use pip for anything because Python programs will pull in dependencies provided by your distribution just fine. (My distribution doesn't even have any Rust libraries, so even if dynamic linking is possible in Rust not many people are shipping software that way.)

"Download by default" is a worse way of doing things, and it makes me sad to see newer languages like Go and Rust embracing it.

Standard libraries serve several functions. One of them is to bless certain versions of certain libraries as "known good". This can be done outside the standard library too, without incurring the penalties of actually moving things into the standard library. Rust definitely needs more work in this area though.

You can use `conda install rust_osx-64` on macOS and `conda install rust_linux-64` to use `cargo` with the Anaconda Distribution libraries and tools (including its compilers).

Rust is good at many things, but it's not as attractive for Python for the sort of program you write when a shell script gets a bit too complicated and you want to write it in a proper language.

So Rust can get away more easily without having support for things like command line parsing in the standard library, because it isn't really trying to support situations where it would be inconvenient to give your program its own project directory and Cargo.toml and all.

This is a pretty niche case imo. If you really want a stand-alone dole, you can forego the use of Cargo.toml and instead use std::env::args to get command line arguments.

If it really matters, then do it right (in whatever language makes the most sense).

> When Python's standard library was first being written, there were no easy package managers for any language

Wasn't perl's CPAN developed around that time period (mid '90s) ?

Emphasis on easy :-P Using CPAN in even the late '00s was an ordeal.

It just took ages to install and test some huge and popular modules like Catalyst, Moose. However, once installed and tested they would just on your system. And it wasn't that easy for modules creators and core developers as red hat was notorious for shipping decades of Perl versions (5.10 times).

Node is ostensibly batteries included, but they’re weird, arcane batteries powered by tears. Therefore, to get anything done easily usually requires an external package.

Node doesn't even have a stdlib. You have to npm or yarn anything. And yes most of the time it will end in tears. That's not my definition of batteries included, but rather some batteries might explode, others might only ignite, we wish you the best of luck.

What's a stdlib then, if Node's isn't?

> Node doesn't even have a stdlib.

Yes it does. Perhaps you're thinking of browser JS, which does not.

Yea. I'm using Rust at the moment for fun and the amount of things not in the standard library is crazy to me. What? There is no built-in dictionary? What do I use instead and where is it?

Edit: based off of all the replies below, everyone understands the validity of what I'm trying to say, but also have fortunately pointed out my admittedly grevious error of not knowing you can just import hashmap from stdlib. The extra step is pretty minimal and not a problem. I'm hoping this is covered in the Rust book.

Yeah Rust is pretty extreme. I was just trying to generate a random number in it and was pretty surprised to find out that at some point it did have this functionality in the standard library but they actually removed it and now it's a separate crate.

That is actually being considered for inclusion at some point. It was mainly excluded due it not being ready and them not wanting to commit to the existing API. That said, I like the Rust way. Including a library is pretty easy, and it mains you get the best API as the main one (rather than a stdlib function that is "good enough", and another library to use if you really care about that functionality).

You mean a map? It's in the standard library.

Yep. Map/Hash/Dictionary.

I didn't know it was included in stdlib (I really thought it wasn't) and feel idiotic now. It is still odd (having a primarily scripting background and not coming from the systems side) that I have to include what seems to be essentially an import statement at the top. I guess it is a lot more efficient that way though. Thanks for pointing out my error!

Er, doesn't hashmap do pretty much the same thing? https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

Dictionary in the python sense? There are two!

https://doc.rust-lang.org/std/collections/struct.HashMap.htm... https://doc.rust-lang.org/std/collections/struct.BTreeMap.ht...

At least the first one seems pretty straightforward and thanks for replying. I only just started and have a lot to learn.

Oof, I wasted a good hour+ trying to convert from one to the other. Maybe there's an easy way to do this, but not many people on IRC knew (or were available at the time).

    use std::iter::FromIterator;
    BTreeMap::from_iter(hash_map.into_iter())

Or .into_iter().collect(), I believe. No import needed.

Assuming the keys are Hash + Ord, wouldn't that just be:

  for (k,v) in &src
    { dst.insert(k,v); }

?

Yes, that's what I ended up doing, but the error confused me and I ended up looking for a less hacky way for more than an hour until I said "fuck it" and just did that.

Are they compatible?

If you are using dictionary in the Python sense, Rust has that built in too, you just have to import it from the standard library collections module.

https://doc.rust-lang.org/std/collections/struct.HashMap.htm...

I know it's not the whole point, but there is a hash map and sorted (btree) map in the std collections.

That being said the point still stands, I remember specifically feeling it at the lack of included regex. I overall prefer the slim std lib of rust over the massive python though. Especially with the community being pretty good about nominating de facto standard packages like for regex.

When I first touched Python I had only used C. Is your story similair?

Had I been using Java or Visual Basic or even C++ proirly maybe I wouldn't be so impressed as I were.

I think the mistake Python is doing is messing with it's simplicity with decorations, halfass lambdas and stuff. As a newbie you could understand Python code, while eg. C++ templates were magic. You need to know more Python to understand Python code nowadays.

Decorators added were in in 2004, I think lambdas were an original language feature (like... before 2004).

There are other new stuff that might be confusing to beginners (like our mighty walrus operator), but those two examples have been there for effectively forever.

Ok it's maybe just my random perception of the language evolving in unsync with my (moderate) skills in it.

I just had the feeling there's more "stuff" that you need to know.

Reply on news.ycombinator.com