Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust Platform

aturon.github.io

Post reply on HN
Print view View original

211–220 of 256 posts

Re: The Rust Platform

#211

Post by pjmlp »

rjsw wrote: post #205
pjmlp wrote: post #204

Earlier quoted context omitted.

Of course it made a difference. We only got to buy the compilers that were available on the computer local store, not always 100% original or find some magazine and order international via post. BBS access was only available to a few fortunate capable of paying the high connection rates and the modem in first place. We got to do with what was available to us and could afford to pay. Some of my first Assemblers were t…

It would help if you gave a hint on which technological backwater you are describing. It wasn't any harder to buy stuff in Western Europe in the early 80s than it was in the US.

Portugal late 70's, early 80's in a small town village.

Average salary would be around 300 euros when converted for today's currency

We had just gotten out of a dictatorship.

Re: The Rust Platform

#212

Post by skybrian »

timtadh wrote: post #206
themihai wrote: post #156

Earlier quoted context omitted.

The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag

If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher leve…

Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.

Re: The Rust Platform

#213

Post by [deleted] »

timtadh wrote: post #206
themihai wrote: post #156

Earlier quoted context omitted.

The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag

If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher leve…

[deleted]

Re: The Rust Platform

#214

Post by pcwalton »

rtpg wrote: post #74
pcwalton wrote: post #59

Earlier quoted context omitted.

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…

But if you have a large standard library and want to break the API, you can. If you have 100 different libs that are basically "standard" (who doesn't have `mtl` in their applications at this point), now you have to coordinate 100 different library updates roughly at the same time. If you forget even one of them, then you've broken everything. I think the argument for a large Prelude/standard lib is similar to Google…

> But if you have a large standard library and want to break the API, you can.

We have a policy of no breakage for stable libraries post 1.0 (as does Python, and Go, etc.). So no, we can't.

The size of the standard library has nothing to do with it.

Re: The Rust Platform

#215

Post by pcwalton »

JoshTriplett wrote: post #128
pcwalton wrote: post #59

Earlier quoted context omitted.

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

> That felt like a lot of boilerplate to abstract between str and [u8]. Is there a better way to solve that problem?

This doesn't have anything to do with large vs. small standard libraries, because all of these string types are defined in libstd.

Re: The Rust Platform

#216

Post by the_mitsuhiko »

skybrian wrote: post #212
timtadh wrote: post #206

Earlier quoted context omitted.

If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher leve…

Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.

The standard package cannot be changed.

Re: The Rust Platform

#217

Post by runeks »

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...)

    > This is exactly the main problem with Haskell.
    > A stunning language with a lousy standard library.
I dream of the day where we can say that the main problem of Haskell is which libraries are included in the standard library. To me, we would already have reached programming nirvana at that point.

Re: The Rust Platform

#218

Post by rspeer »

fnord123 wrote: post #197
_ZeD_ wrote: post #118

Earlier quoted context omitted.

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

Arrow seems particularly useless as it just wraps stdlib datetime and its awful 10 byte size rather than moving to an 8 byte representation like np.datetime64 uses.

Just because you haven't found a use for it doesn't mean it's useless.

The stdlib datetime class is terrible and desperately needs to be wrapped. Arrow is a good wrapper. I don't know what you're on about with counting bytes.

Re: The Rust Platform

#219

Post by [deleted] »

sitkack wrote: post #76
pcwalton wrote: post #59

Earlier quoted context omitted.

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…

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

[deleted]

Re: The Rust Platform

#220

Post by skybrian »

the_mitsuhiko wrote: post #216
skybrian wrote: post #212

Earlier quoted context omitted.

Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.

The standard package cannot be changed.

By "adjust to" I meant living with the standard library's decisions without changing them. Compatibility with GNU syntax doesn't seem very important.
Post reply on HN