Hacker News Reader

Comment by srssays | Hacker News Reader

I wouldn't say it works, rather that people will put up with it. When I write JavaScript/node.js code, I have no idea whether the dependencies I'm using will be supported 6 months from now.

It's not so easy to just "choose the right package". Often all the packages for a given function are someone's hobby.

Consequently JavaScript code needs constant, expensive maintenance. Whereas Python code can rely more on the standard library and big frameworks and tends to keep working for years.

Programming language designers should see themselves as builders and curators of great standard libraries, the language itself is almost incidental to that goal.

View on HN

What makes the libraries blessed by the language designers so much better than a library blessed by any other trusted party? Rust is an open source language, and only the core team works on it full time - even then, any one of them could leave at any time and the community at large would need to pick up the slack. This isn't any different than the situation around any of the amazing community libararies in the Rust ecosystem. Heck, libs blessed by the language designers aren't even always the best choice - just look at json manipulation in .NET; you get multiple different stdlib ways to work with json, yet the community still gathers around the much better JSON.NET package.

In terms of value proposition, I think the author is just hankering for some .NET style support agreements in order to hedge his maintenance cost bets - and I'm sure there are or will be plenty of consultancies willing to provide this service, so long as the demand exists. That open source language users are entitled enough to expect this service for free from language maintainers... I'm not sure that's completely justifiable.

If a library is supported and maintained by the language designers, then its lifetime will be at least as long as the lifetime of the programming language. Or if the library is replaced, then it will be done through some mechanism of deprecation, rather than sudden abandonment.

I don't see the standard library and third-party packages as being in opposition. Far from it. A rich standard library encourages a rich ecosystem of third-party packages.

Maintenance costs affect the authors of open source packages even more than they affect commercial users. They are working for free and in their spare time. A rich standard library makes a language attractive to people who want to write packages.

Omg. You just made me think about lifetime markers for crates... your project requires a minimum lifetime of stability in a crate or something. Kinda funny.

I don't think he's arguing that the language designers are the ones that need to be curating crates, he just brought up Python as an example of some sort of curation happening in a similar ecosystem. It's the community at large that needs to be more active about identifying and signaling which crates should be preferred to provide particular functionality.

I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.

Libraries tend towards standardisation regardless of whether they're being curated by the language designers.

Python is actually a good example of this. Look at the library ecosystem built up around scientific computing. None of that is in the standard library, yet there is a common set of packages being used.

Of course. But these projects exist in addition to a rich standard library.

C++ takes the approach mentioned of having a rich standard library (Boost) that is a separate project from the core language. It (IMO) does not work very well. Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.

> Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.

That is because a boost installation litters your hard drive with several hundred thousand tiny files. I can't in good conscience require end-users to install that monster to compile my 10Kloc project.

Yeah, but C++ doesn't really have a good, cross platform package manager. In Java land, for example, the lingua franca is Maven (even across different build systems).

As a result many libraries are close to de facto standards because any Java dev can easily get those libraries, regardless of being on Win, Mac, random Linux distributions, etc.

Scientific libraries are a complex problem, writing yet another web framework isn't. Furthermore most sci/num libs are heavily linked to C/C++ and FORTRAN code, where most of the work is done.

Web frameworks are rarely part of standard libraries. The closest I can think of is ASP.NET for C#.

Go has a http server, so does python and javascript.

So a http server is a web framework now? Okay, let's go along with this.

Node.js is popular, but it's not 'standard'. It's not part of any ECMAScript standard libraries, which would be the requirement if it was to be standard.

I don't know the situation with Go that well, so if it has a http library in the standard I'll take your word for it, but there do seem to be some popular non-standard http servers like Caddy.

As for Python, this is probably an example of where the impact of standards is not that great. How often is the standard http server used compared to popular third party alternatives? Are there any web apps you know of that are using the standard http server in production?

Reply on news.ycombinator.com