The Rust Platform • Hacker News Board

Re: The Rust Platform

#101

Post by glandium » Thu, Jul 28, 2016, 5:10 AM UTC

sitkack wrote: post #87

goodplay wrote: post #85

Earlier 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…

Plus, python's std lib is a mumbo jumbo of all sorts, there is no API coherence.

Re: The Rust Platform

#102

Post by glandium » Thu, Jul 28, 2016, 5:22 AM UTC

btown wrote: post #42

pcwalton wrote: post #22

Earlier quoted context omitted.

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…

And notably, C++11 actually moves in this direction, standardizing things like smart pointers [0][1]. It's a very smart move for Rust. Core or near-core library wars in the early days of adoption of a language leads to duplication of effort, and for those invested in seeing Rust gain a set of libraries to rival other languages, this is a great thing. [0] https://en.wikipedia.org/wiki/C%2B%2B11#C.2B.2B_standard_lib...…

Actually, C++'s STL is in a weird situation, compared to the standard library in other languages, because the STL is a spec, not an implementation. And there are as many implementations of the STL as there are compilers. This might arguably happen if there were multiple Rust compilers, though. Anyways, the result on the C++ STL is that in many cases, the same types have different performance characteristics on different platforms, or worse, different behavior/bugs.

Re: The Rust Platform

#103

Post by tibbe » Thu, Jul 28, 2016, 5:23 AM UTC

saghm wrote: post #77

kibwen wrote: post #72

Earlier 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

JS, too, right? Forget "large" standard library, there really isn't any standard library at all

You don't need a standard library to win if you don't have any competitors (in the browser). :)

Fitness for purpose is relative to the other options.

Re: The Rust Platform

#104

Post by tibbe » Thu, Jul 28, 2016, 5:24 AM UTC

bitmadness wrote: post #97

tibbe wrote: post #39

I wouldn't recommend following the Haskell approach. It hasn't worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…

This is exactly the main problem with Haskell. A stunning language with a lousy standard library. In my opinion, Haskell should offer arrays and maps as built-ins (like Go) and ship with crypto, networking, and serialization in the standard library (I know serialization is already there, but everyone seems to prefer Cereal, so...)

Agreed, except for the "like Go" part, which is unnecessarily ad-hoc.

Re: The Rust Platform

#105

Post by tibbe » Thu, Jul 28, 2016, 5:27 AM UTC

geekingfrog wrote: post #100

rcfox wrote: post #99

Earlier quoted context omitted.

Out of curiousity: what do the 5 string types do differently?

String: Linked list of Char. Nice for teaching, horrible in every other aspects. Text and lazy Text: modern strings, with unicode handling and so on. ByteString and lazy ByteString: these are actually arrays of bytes. Used to represent binary data. Because haskell is lazy by default, and sometimes you want strictness (mostly for performances), there are two variants of Text and ByteString, and going from one flavor t…

Risking to go off-topic a bit, I think the lazy versions of Text and ByteString wouldn't have been needed if we had nice abstractions for streams (lists are not, they cause allocation we cannot get rid of) so that you don't need to implement a concrete stream type (e.g. lazy Text and lazy ByteString) for every data type.

Rust does this well with iterators, for example.

Re: The Rust Platform

#106

Post by tibbe » Thu, Jul 28, 2016, 5:28 AM UTC

catnaroek wrote: post #83

tibbe wrote: post #81

Earlier quoted context omitted.

There can be more than one problem, including having a small standard library.

The lack of a standard library can be fixed relatively easily: write libraries! OTOH, the existence of anti-modular language features that are extensively used in several major libraries, is a more serious problem, because: (0) It means that libraries in general won't play nicely with each other, unless they're explicitly designed to do so. (1) It can't be fixed without throwing away code.

This whole thread is exactly about how "write libraries!" (if done outside the standard library) doesn't work (see my top post).

I do agree that lack of modularity features certainly doesn't help though.

Re: The Rust Platform

#107

Post by saghm » Thu, Jul 28, 2016, 5:33 AM UTC

tibbe wrote: post #103

saghm wrote: post #77

Earlier quoted context omitted.

JS, too, right? Forget "large" standard library, there really isn't any standard library at all

You don't need a standard library to win if you don't have any competitors (in the browser). :) Fitness for purpose is relative to the other options.

Well, JS was originally competing with Java applets in the browser, but, like you said, fitness for purpose is pretty significant!

My point (or rather, the point of the parent comment that I'm agreeing with) there's a lot more than just the presence and characteristics of a standard library that determine how widespread a language becomes

Re: The Rust Platform

#108

Post by legulere » Thu, Jul 28, 2016, 5:37 AM UTC

pcwalton wrote: post #59

tibbe wrote: post #39

I wouldn't recommend following the Haskell approach. It hasn't worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…

I don't think most of these are applicable to Rust. > - Conversions between our 5(!) string types are very common. > - Standard library I/O modules cannot use new, de-facto standard string types (i.e. `Text` and `ByteString`) defined outside it because of dependency cycle. We have one string type defined in std, and nobody is defining new ones (modulo special cases for legacy encodings which would not be worth pollut…

> We have one string type defined in std, and nobody is defining new ones (modulo special cases for legacy encodings which would not be worth polluting the default string type with).

There's also `inlinable_string`, `string_cache`, `tendril`, `intern` if you need inlining for performance.

The bigger problem is with other things like 2D/3D points which can be (f32, f32), [f32; 2] or a custom struct.

Re: The Rust Platform

#109

Post by EugeneOZ » Thu, Jul 28, 2016, 5:42 AM UTC

Good chance to see how Rust team will accept negative reaction to their idea. If they will.

Re: The Rust Platform

#110

Post by wyager » Thu, Jul 28, 2016, 5:42 AM UTC

tibbe wrote: post #39

I wouldn't recommend following the Haskell approach. It hasn't worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…

>Conversions between our 5(!) string types are very common.

All five of those string types do different things. This isn't a problem; we just have increased expressivity. We couldn't fix this by having a more coordinated standard library. 5 is also a very manageable number IMO.

>It's too difficult to make larger changes as we cannot atomically update all the packages at once.

That's what Stack is for, no?