191–200 of 256 posts
Earlier quoted context omitted.
> The standard library also includes Path/PathBuf and OsStr/OsString. Right. And you want people to explicitly convert between them. Having to convert between string types isn't a problem. String encoding is hard, and you're going to have to pay that cost somehow .
Having to convert isn't a problem. Having to write some algorithms multiple times for different string types is a problem.
Earlier quoted context omitted.
It had, Modula-2 and Pascal dialects usually had richer libraries. For example check Turbo Pascal libraries, including Turbo Vision, already on MS-DOS. C took off thanks to UNIX's adoption, like JavaScript on browsers nowadays, it became the language to use for anyone working on the enterprise on those new shiny UNIX boxes. In Europe it was just another systems language to choose from, back when CP/M and other 8 / 16…
C was usable on MS-DOS before Modula-2 or Turbo Pascal were available.
Also there were C, Pascal and Modula-2 compilers available for ZX Spectrum.
And on my part tiny of the globe I can guarantee that everyone only cared about x86 Assembly, Turbo Basic and Turbo Pascal, with Clipper for business stuff.
I only got to learn C in 1993, after having been a Turbo Pascal 3, 5.5 and 6.0 user.
Earlier quoted context omitted.
I think rust needs to slow down in this regard. I have been with Python since 1999 and the stdlib has held it back, I have also used Scala and Haskell and have witness the mess that platform libs on each have caused. What Rust has right now is pretty amazing. What needs to happen is a way for devs to easily break the dependency cycle and include multiple versions of the same crate. Something that has plagued Haskell.…
Rust will already allow you to have multiple versions of transitive dependencies.
Earlier quoted context omitted.
Maybe a change in attitude? Stability can be a good thing. Go's standard library doesn't change that much, and that's a strength. How about: "std is where code goes when it's done". As is, really done. The API's won't need changing.
The counterpoint being Python simplejson vs json. Most working Python developers I know try simplejson first (when they are not controlling dependencies in the environment) and fall back to stdlib json because simplejson got much faster as it evolved outside of the standard library[0]. Most who don't know this go the other way[1]. There are a number of counterpoints in Python, in fact, which epitomizes the "standard…
Even more code just use the standard json package without any fallback. The ease of development or deployment is clearly worth more to them than what small speed advantage they can get from going with the external dependency.
The calculus will be different for Rust, of course, with different build and deployment system.
I'm a bit worried when a language develops a "platform" and an "ecosystem". This usually means you need to bring in a large amount of vaguely relevant stuff to do anything. It adds another layer of cruft, and more dependencies. Write standalone tools, but don't create a "platform". Don't make the use of the language dependent on your tools. C++ does not have a "platform". Nor does it need one.
C++ has innumerable de facto "platforms" and "ecosystems". You have to choose one to get anything done, whether that be various Boost libraries, POSIX, Win32, Cocoa, Qt, GTK(mm), even stuff like XPCOM… Helpfully, many of these platforms reinvent basic things like strings [1] and reference counted smart pointers [2] in incompatible ways. Wouldn't it be better if there were just one platform? [1]: http://doc.qt.io/qt-4…
Earlier quoted context omitted.
C was usable on MS-DOS before Modula-2 or Turbo Pascal were available.
Both C compilers and Turbo Pascal already existed in CP/M, which preceded MS-DOS. Also there were C, Pascal and Modula-2 compilers available for ZX Spectrum. And on my part tiny of the globe I can guarantee that everyone only cared about x86 Assembly, Turbo Basic and Turbo Pascal, with Clipper for business stuff. I only got to learn C in 1993, after having been a Turbo Pascal 3, 5.5 and 6.0 user.
I first used C in 1983 on MS-DOS, I didn't use UNIX until a couple of years later. I bought Turbo Pascal 1.0 when it was released but already had a C compiler at that point.
Earlier quoted context omitted.
The 'std lib is where libraries go to die' was invented by Python. The libs are shallow, don't break backwards compat and provide a substandard experience. Things that continue to improve provide an out of tree alternative package name. Python codebases that are resilient don't use much of "core", arrow for time, requests for http, simplejson, etc. Using core is an antipattern that will get you stuck on a version of…
Just as a data point... I like and heavily use the core libs... And not once i used arrow, request or simplejson, while knowing them, because i didn't feel the needs
People then gain experience with it and sometimes subtle issues emerge. Those issues can be fixed, either in Boost itself or when libraries move from Boost to stdlib (and sometimes the issues inform language features).
While C++'s standard library is not "batteries included" like Python's, it's been very gratifying to see it expand slowly and surely over the last few years.
Earlier quoted context omitted.
Maybe a change in attitude? Stability can be a good thing. Go's standard library doesn't change that much, and that's a strength. How about: "std is where code goes when it's done". As is, really done. The API's won't need changing.
Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics. Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. That's the definition of 'stdlib is where packages go to die'. It's not that the API is unusable , it's just basically…
>Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution.
How does that reflect the quality of the std lib implementation? All the high-level wrappers I've seen still utilize database/sql, they just provide convenience methods on top of the existing functionality. Are people using NoSQL databases because database/sql is so bad or merely because that technology fits their project's requirements?
>That's the definition of 'stdlib is where packages go to die'.
steveklabnik's example of Ruby XML parsing libraries is a better example of this, if only because the std lib implementations are almost completely ignored by all other gems. Go's database/sql is actively used outside of the std lib to great affect, whether in wrappers and ORMs or in implementing other SQL databases (like Postgres).
Earlier quoted context omitted.
Both C compilers and Turbo Pascal already existed in CP/M, which preceded MS-DOS. Also there were C, Pascal and Modula-2 compilers available for ZX Spectrum. And on my part tiny of the globe I can guarantee that everyone only cared about x86 Assembly, Turbo Basic and Turbo Pascal, with Clipper for business stuff. I only got to learn C in 1993, after having been a Turbo Pascal 3, 5.5 and 6.0 user.
Being able to compile stuff on CP/M wasn't much help if you wanted to develop MS-DOS applications. I first used C in 1983 on MS-DOS, I didn't use UNIX until a couple of years later. I bought Turbo Pascal 1.0 when it was released but already had a C compiler at that point.
So I got to see the language world in a different way, given the local choice of languages as I mentioned.
EDIT: Reformulated the answer