For contrast, with .NET Core, Microsoft decided to cut up .NET's quite extensive stdlib (BCL + FCL) into packages. On paper, it looks pretty good, but it remains to see how well the versioning will work in the long run.
The Rust Platform
181–190 of 256 posts
Re: The Rust Platform
#182Earlier quoted context omitted.
I can tell it is lots of "fun" when you can only use a Maven mirror, with approved jars. To get a jar into that mirror, a request needs to be sent to the legal team describing the license and business case use, after approval the IT team will add the said jar to the mirror. The same applies to version upgrades of already approved jars. This is a typical scenario I had already in a couple of projects.
I agree that this sucks, but not doing it that way is dangerous for the company because developers might not care enough about license compliance when they include some stuff into their project.
I also agree, as I have been through what happens when developers do exactly that and then it gets discovered the worse way.
Re: The Rust Platform
#183Earlier quoted context omitted.
If you can, could you elaborate more on python's stdlib holding it back? I think batteries-included experience is one of the reasons why so many people (including myself) use python. It's also one of the features I sorely miss when using Rust. Luckily, Rust's stdlib is starting to tend towards being more practical with recent additions like system time.
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…
But isn't requests built off of urllib?
The thing I like about python is it gives tools for library writers to build things without going too low level.
Application writers will always write with better libs, but don't have to worry about third party lib compatiblity on platforms because of the stdlib serving as a virtual machine (most of the time)
Re: The Rust Platform
#184I agree with the others here. I like rust the way it is and I think it's fine to leave it alone :)
Re: The Rust Platform
#185Earlier 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…
But isn't requests built off of urllib? The thing I like about python is it gives tools for library writers to build things without going too low level. Application writers will always write with better libs, but don't have to worry about third party lib compatiblity on platforms because of the stdlib serving as a virtual machine (most of the time)
requests is built on urllib3, and it includes its own version of urllib3 (to avoid dependency problems).
If I'm not mistaken, the stdlib contains urllib and urlib2, but not urllib3.
The fact that there 3 "urllib" packages show that the Python way is not so good.
Re: The Rust Platform
#186Earlier 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.…
One of the things I love above all about Python and Ruby are the kitchen-sink standard libraries. The node ecosystem is deeply frustrating in this respect.
It has been a while since I did anything with Python, but I did like its standard library. It was reasonably comprehensive without feeling bloated, and the documentation was pretty good (mostly).
Having a good standard library also makes deployment easier. (In Go, OTOH, I tend to care less, even though its standard library is quite good, because thanks to static linking, deployment is always easy, no matter how many third-party libraries I use.)
Re: The Rust Platform
#187Earlier quoted context omitted.
But C didn't have competitors with large standard libraries, so it didn't suffer as much for it.
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.
Re: The Rust Platform
#188Earlier quoted context omitted.
> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P
> You seem to be overlooking the ultimate counterexample: C. :P I think one reason (of many) that C++ has replaced C almost completely for new development is the STL. Of course, the STL fundamentally depends on the language feature of templates, which you can only approximate in C, but considering that Java and Objective-C, among other languages, lasted pretty long with no generics and only non-type-safe containers,…
FWIW, the last time I cooked up something in C, I liked Judy very much: http://judy.sourceforge.net/
It has slightly awkward but very simple API, and it's very fast.
Re: The Rust Platform
#189Earlier quoted context omitted.
Go isn't immune to the problem either. See the `flag` package, which is something that new users are encouraged to avoid in favor of e.g. https://github.com/jessevdk/go-flags .
I am a Go programmer and I've never seen anyone anywhere encouraging people to use anything over the flag package. How did you get such impression?
Docker, for example, say "seriously just don't use it".
http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...
Re: The Rust Platform
#190Earlier quoted context omitted.
> We have one string type defined in std The standard library also includes Path/PathBuf and OsStr/OsString. And third-party libraries also use [u8] for bytestrings. It'd be nice to improve handling for user-supplied text where you can't assume UTF-8. For instance, git2-rs provides the contents of diffs as [u8], because it can't assume the diffed files use UTF-8. That led to this commit today: https://github.com/ogha…
> 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.