
Rust libraries that need to be written - steveklabnik
https://mail.mozilla.org/pipermail/rust-dev/2014-June/010139.html
======
unwind
I don't work with Rust, but in general this is a very nice way to present a
project's needs, in order to request contributors to help. I hope it works for
them.

I also like the pragmatic approach, instead of saying "date APIs are hard, so
we'll think until we've cracked it" they just explicitly plan on copying a
popular one (the Joda-Time Java API, [http://www.joda.org/joda-
time/](http://www.joda.org/joda-time/)).

~~~
higherpurpose
As of now, copying an API is illegal, no?

[http://www.reuters.com/article/2014/05/09/us-oracle-
google-r...](http://www.reuters.com/article/2014/05/09/us-oracle-google-
ruling-idUSBREA480KQ20140509)

~~~
ben0x539
It's not _illegal_ , it's just apparently impacted by copyright. Since Joda-
Time is available under the Apache 2.0 license, that doesn't seem like an
unsurmountable obstacle.

~~~
jasode
I'm not a legal scholar but it seems like Joda-Time's Apache 2.0 license can
be rendered irrelevant if Joda copies API spellings from Oracle Java.

For example, Joda has a member function called .getYear(). Oracle
java.util.date also has a .getYear(). At the time the author created Joda, the
type of restrictive API copyright ruling that Oracle won wasn't part any
programmer's mindset. If it was, maybe Joda would have called it .getAnnum()
or .getOffsetfromZeroCE() or .getYYYYComponent().

If a company gets to release their API first with a .ToString() ... the next
company has to call it something else such as .ReifyAsString() and then then
next company after that has to name their API with yet another synonym such as
.Stringify().

Continuing that scenario, could one even publish a blog post listing the
_complete_ 1-to-1 translation of Company A's API to Company B's API? Could one
legally write a program that automatically converts one source code listing's
API calls to another? Would those rosetta stone type of publications and dev
tools be in violation of API copyrights?

Joda-Time doesn't copy 100% java.util.date but I don't know what the threshold
is.

~~~
chc
Also not a lawyer, but IIRC Oracle won on the grounds that the "structure,
sequence and organization" of their API was a creative and copyrightable work,
not just the odd descriptive name here and there.

~~~
groovy2shoes
One of the circuit court's stated reasons for ruling that the SSO holds for
the Java API was because of the names:

    
    
      The evidence showed that Oracle had "unlimited options as to the selection
      and arrangement of the 7000 lines Google copied." Appellant Br. 50.  Using
      the district court's "java.lang.Math.max" example, Oracle explains that the
      developers could have called it any number of things, including
      "Math.maximum" or "Arith.larger."  This was not a situation where Oracle was
      selecting among preordained names and phrases to create its packages.  As
      the district court recognized, moreover, "the Android method and class names
      could have been different from the names of their counterparts in Java and
      still have worked." Copyrightability Decision, 872 F. Supp. 2d at 976.
      Because "alternative experessions [we]re available," there is no merger.
      See Atari, 975 F.2d at 840.
    

[http://www.cafc.uscourts.gov/images/stories/opinions-
orders/...](http://www.cafc.uscourts.gov/images/stories/opinions-
orders/13-1021.Opinion.5-7-2014.1.PDF)

pp. 30-31.

~~~
chc
This is a broader point than "it was because of their names." As I understand
it, the court is saying that Google copied the whole package structure of
Java, including a whole tree of associated names. It's not just that some
names happened to match up, but that the whole structure of the Java libraries
was considered a creative work and Google copied that whole creative work. The
names are a component of that, but you can't point at a name and say "That was
the copyrighted thing," because it was the aggregate API that the court
considered copyrightable.

(Again, not a lawyer or legal advice. This is just my layman's understanding.)

~~~
groovy2shoes
Yeah, I think you're right. It's the wholesale copying of a large chunk of the
Java API rather than just the name of one thing.

Tangentially, I really disagree with the ruling. First, we have to figure out
where to draw the line: if you can copyright a big API, can you copyright a
small one (like, say, Iterable)? Second, there's legal precedent for allowing
partial copies in cases where it's necessary for interoperability (Sega v.
Accolade). Finally, the appeal for Lotus v. Borland allowed for wholesale copy
of a command hierarchy for _user interfaces_ , which has parallels to
_application programming interfaces_ that I think any programmer would find
obvious. My favorite quote from that case:

    
    
      [51] That the Lotus menu command hierarchy is a "method of operation" becomes
      clearer when one considers program compatibility. Under Lotus's theory, if a
      user uses several different programs, he or she must learn how to perform the
      same operation in a different way for each program used. For example, if the
      user wanted the computer to print material, then the user would have to learn
      not just one method of operating the computer such that it prints, but many
      different methods. We find this absurd. The fact that there may be many
      different ways to operate a computer program, or even many different ways to
      operate a computer program using a set of hierarchically arranged command
      terms, does not make the actual method of operation chosen copyrightable; it
      still functions as a method for operating the computer and as such is
      uncopyrightable.
    

[http://www.law.cornell.edu/copyright/cases/49_F3d_807.htm](http://www.law.cornell.edu/copyright/cases/49_F3d_807.htm)

Anyway, I know you didn't ask for my opinion on the ruling but I just wanted
to rant a little :) The circuit's ruling really pissed me off. Programming is
hard enough without having to worry about whether or not our APIs are covered
by an existing copyright.

------
yoodenvranx
I come from an image and signal processing background so for me one of the
most important library features is a) a good support of largish one and
multidimensional arrays, b) support for FFT and c) some support for linear
algebra.

~~~
StefanKarpinski
If those are your big requirements, you may want to try Julia. Those are the
most mature parts of the Julia standard library are very stable, not to
mention fast. Steven Johnson, the author of FFTW, which is _the_ FFT library
wrote the Julia FFT code and is Julia core developer. I think that it's safe
to say for doing FFTs and linear algebra, there's no better system out there.

------
leorocky
> We've previously made the decision not to distribute any crypto with Rust at
> all, but this is probably not tenable since crypto is used everywhere.

This is pretty much why I haven't used Rust for any serious application
development. Any HTTP or TCP connection I'd want to make would be over TLS and
there are better options than importing c crypto libraries in Rust.

I get what they're trying to do, and the conservative nature is admirable but
I just want to "get things done" and while Rust is nice not having crypto is
as is mentioned not tenable for application developers.

Crypto is very critical. Many people do not want their application to send
their critical data in the clear.

~~~
tinco
Did you read to the end of the paragraph where they say that they're going to
implement crypto?

They're not insecure about being able to make a workable crypto api. They are
aware that it's not a good idea to implement crypto in a high level language
that's not been engineered for security yet.

Their solution is to wrap a proven C crypto library, which is probably what
good Go and JVM languages do also (I wouldn't trust one that doesn't) and it's
probably going to be ready within a month or two.

edit: just an aside, why would you terminate your SSL in Go/Java, it's good
practice to have a proxy like nginx or haproxy do that for you.

~~~
leorocky
> Did you read to the end of the paragraph where they say that they're going
> to implement crypto?

I did, they said it would take a very long time.

> Their solution is to wrap a proven C crypto library

This is good. I don't have a problem with that, because that's what you'd have
to do yourself right now if you wanted to do any kind of basic crypto with
rust, include a C library and wrap it with boiler plate just to get it
working.

> which is probably what good Go and JVM languages do

Nope, Go implemented their own crypto:

[http://golang.org/src/pkg/crypto/elliptic/p224.go](http://golang.org/src/pkg/crypto/elliptic/p224.go)

[http://golang.org/src/pkg/crypto/](http://golang.org/src/pkg/crypto/)

~~~
tptacek
Golang had subject matter experts to do that work.

------
InclinedPlane
This is like a checklist of all the most horrific libraries to write. I wish
them luck.

~~~
xienze
With the exception of HTTP, I'd say it's more that the libraries are unsexy,
not horrific.

~~~
hga
Time is pretty horrific; I've been using the Clojure wrapping over Joda-Time,
and while it's nice, this is an intrinsically _extremely_ messy field. E.g.
one that requires frequent updates for Daylight Savings Time changes.

~~~
kybernetikos
Yeah, even at the fundamental level, there are fudge factors that vary from
year to year and can only be worked out by astronomical observation.

Just measuring what is meant by 'year' is a tricky problem:
[https://en.wikipedia.org/wiki/Year#Sidereal.2C_tropical.2C_a...](https://en.wikipedia.org/wiki/Year#Sidereal.2C_tropical.2C_and_anomalistic_years)

------
jfaucett
looking at these libraries that are non-extant makes me think that Rust won't
be production ready for quite a time still...

The List:

1\. HTTP

2\. Crypto

3\. Unicode

4\. I18n & Localization

5\. Date/Time

6\. Generic SQL

These are things you can't just throw together quickly, it takes years to do
these things right.

EDIT: I see your points guys, wrapping up C code will make some of these
things go pretty quickly, and your also right about a lot of production apps -
at least low level systems stuff - not dependening on hardly any of these. I
suppose I was thinking of this as an app developer, and if your talking about
creating desktop apps in Rust, like a Browser or a SQL-Editor etc, every one
of these libs has to be at least pretty darn good - otherwise its just a
headache for you as a dev.

~~~
pcwalton
I wouldn't go so far as to say Rust will not be production ready until we have
all of this. First of all, not all apps need all of these things; especially
systems-level apps don't need most of this. Second, you can easily bind to C
libraries that provide these things, making Rust just as production-ready as C
is.

Of course, that isn't to diminish the importance of having high-quality, safe,
idiomatic implementations of these things, but that shouldn't stop you from
using Rust in production.

------
seanewest
This is very effective because it basically creates a land-grab for any of
those libraries. Most people make a prediction that a library they are
thinking of writing will be needed/popular, this outright states it, creating
a low risk incentive. (Of course it still has to be well written, which is
hard).

------
rdmcfee
Poor date/time libraries are a major source of long term pain for developers.
Hopefully Rust will get this right early on!

------
pkulak
It amazes me that this language was supposedly written to be the groundwork
for an entirely new html engine and yet there has never been a really nice
HTTP library; built in or third party. Look at some of the last language hype
parties: Node and Go; they both didn't even hit alpha stage before they had
fantastic HTTP/networking libraries built in.

I get that Rust is targeting low-level, "systems" programming, but I really
don't see how you can't also be a very performant server language.

~~~
kibwen

      > they both didn't even hit alpha stage before they had 
      > fantastic HTTP/networking libraries
    

Rust is not yet alpha. It's still pre-alpha.

~~~
brson
In fairness though, it's very unlikely that Rust will be distributing an
official HTTP library by 1.0 - it's a big, difficult, library, the type which
deserves to prove itself in for awhile before settling on. For these types of
libs my planned trajectory is to integrate with Servo, make them installable
via the package manager, let them stew in the wild until we're confident, then
'flip a switch' and declare them official.

~~~
glenjamin
Given that people are working on a high quality package manager, what do you
gain when you "flip the switch" and make it official, rather than just having
it be the most used HTTP package?

~~~
brson
You don't gain much at that point, and that's the aim: a process that allows
the best libraries to smoothly progress from community projects to official
components, without any major disruptive events along the way.

------
rch
SqlAlchemy core _is_ a good system to learn from. Great, in fact. It should be
fairly easy to preserve the idioms in a way that feels natural in Rust too.

------
zellyn
You should talk to the golang core folks about time - I believe they have
well-informed opinions.

~~~
frowaway001
Looking at their language design – probably not.

