Hacker News Reader

> It seems in principle to be no more or less dangerous than something like "apt-get install libcairo-dev ; make" but that would only be true if there was a trusted repository system.

Not that this is really a response one way or another, but given the way that Go currently works, you effectively place the same amount of trust in each individual library maintainer as you do with the collective trusted repository maintainers in other approaches.

If someone were to decide to start curating repositories and forking/maintaining them, people could choose to trust that individual. So the possibility for a trusted repository exists, but as far as I know nobody has fully stepped up to create such a thing at this point.

> Can someone from Go comment on the ability to create and manage trusted repositories?

You basically just need to throw up a HTTP-accessible HTML page with some <meta> tags that describe how to fetch the actual code with a variety of source control systems. Anyone can create their own trusted repositories.

[docs] http://golang.org/cmd/go/#hdr-Remote_import_path_syntax

When you install a package with `apt-get`, that package can potentially change your system in any way it pleases. Running `go get` will download and compile code, but there is no security risk until you run or use that code without checking it first.

You're comparing things that are different. When you install a package with apt-get:

- it comes from a repository that has been signed by the distributor.

- the package has been tested and has a good level of integration with the system (ie different distributions may package things differently).

- depending on the distribution, there may be a commitment to API/ABI stability (ie. Debian backports security fixes most of the time).

That said... running "go get" is very convenient if you control the code repository where you're fetching the code, but it's not a good idea when using 3rd party software that is in active development.

EDIT: formatting

If you don't trust your package manager & distribution supplied packages (read: your whole operating system), the security risk between an 'apt-get' and 'go get' is most likely not the most important thing to worry about.

> Bill Joy was convinced that it was possible to give the class loader the ability to statically analyze a class and determine whether or not it would work with the code that was trying to invoke it.

Here, 'work' must mean 'has the methods and other stuff the client code is looking for with the types the client code expects', except the Java type system isn't really expressive enough to do a very good job of that, especially if there are any generics involved (such that a lot of stuff has been hammered down to type Object). But Java didn't have generics that long ago, did it? Something like Eiffel, with design-by-contract and automated contract checking, would be able to make more use of the concept.

Pretty trivial, especially if you can rely on the compiler to do dead code elimination before checking to see what the client code is expecting. I don't know if javac (as opposed to the JIT) does dead code elimination, though.

The actual explicit definition of work was 'not throw a ClassCompatibility Exception' because the JVM was convinced that the method it was about to call was the same semantically as the method had been when the calling class was compiled.

The idea was to create a 'semantic message digest' (I don't know if such a thing exists or not) which could be computed at class load time and checked/validated at method invocation time. The canonical case for the talking point was you have a class Foo with methods doA, doB, and doC if you change doB incompatibly but the client only calls doA and doC the class is still 'compatible' (in a call contract context) with the class even though the class is 'different' in an incompatible way. Guy Steele and Bill came up with a pretty interesting list with things like methods added, methods missing, more parameters, fewer parameters, additional fields, fewer fields, additional constructors, Etc. All the ways you might mutate a Class and yet for a class of callers it would still work just fine.

If one can do this, another interesting feature is better capability type systems. Those systems have to deal with changes that may change the capability represented by a method even though it is still semantically compatible.

But it does not protect you from the guy who changes his API without changing the signature of the method ("off with these pesky empty lists, let's return null instead").

Thats correct, and ultimately these were the rocks I flailed against for a few months before giving up. There are ways that you can change what something does that don't look semantically different to the compiler. That means you can't capture a semantic signature completely.