Go's power is in emergent behavior
onebigfluke.com
onebigfluke.com
For reference, here's the exact same thing in Rust:
// Define trait Foo, this is the equivalent of an interface
pub trait Foo {
fn foo(&self, x: int) -> int;
}
// Define a newtype called FooFunc
pub struct FooFunc(fn(x:int) -> int);
// Explicitly implement the trait on FooFunc
impl Foo for FooFunc {
fn foo(&self, x: int) -> int {
let &FooFunc(f) = self; // unwrap the newtype
f(x)
}
}
// This is a method that uses a Foo, analogous to http.Handle()
pub fn doFoo<T: Foo>(f: T) {
println!("foo(42) = {}", f.foo(42));
}
// Here's our function that we want to wrap
fn MyFoo(x: int) -> int {
x+1
}
fn main() {
// Call the function, just like http.Handle using http.HandlerFunc
doFoo(FooFunc(MyFoo));
}
I would gladly trade for the verboseness of making these relationships explicit if it let me typecheck and refactor with ease.
You're also missing one of the best parts of implicit interfaces - you can use other people's types in your own functions with interfaces that didn't even exist when they wrote their type. To do that in languages with explicit interfaces, you have to write ugly wrapper classes around the other person's type for zero benefit.
var f = function(){ console.log('called'); };
f.callMe = function(){ this(); };
/* Also, from the blog:
> Nowhere in this code did we ever declare a relationship between MyType and Answer.
"Answer" isn't in the example. Was this something from an earlier draft? */
Add a MarshalText() (text []byte, err error) function and it can now be used anywhere that expects a encoding.TextMarshaler.
Furthermore, your type can be used in someone's else code which has defined its own MarshalTextCloser interface.
I believe this is what the OP means by emergent. You wrote a type that has two methods, within your own package called "goku.Sayan", and it accidentally satisfies the interface "picard.MarshalTextCloser" which you'll never know about. "Sayan" was never built to satisfy _any_ interface. You just needed a Close and MarshalText function, but none the less, "Sayan" satisfies 3 distinct interface (which could be represented by an unlimited number of names)
I realise accidental sounds dangerous, but the only real risk is that the methods don't do what you think they should. But I don't see how that's different from explicit interfaces; in both cases the intent is only implied by the name. Overall, as the OP says, it's quite powerful when dealing with simple 1 or 2 function interfaces. I think most Go developers see this naturally emerge in their own code: they favor small interfaces specifically for this type of re-use.
The primary benefit that structural interfaces give you, IMO, is less typing. Which has plenty of value, don't get me wrong; it's awesome that Go has successfully reduced the amount of syntactic overhead needed to implement interfaces. But I think the benefits of it shouldn't be overstated.
Or if your refactoring and decide to split an interface so what was X is now Y and Z. Consider adding unkillable NPC's to a game. Rather than having special code to handle MOB's that you can't kill you remove HP's from the MOB interface and add a killable interface and now the type system helps you refactor your code by complaining when you try to harm something without HP's. At the same time you don't have to change any existing objects.
1. A and B were defined in separate libraries. In this case, the arguments about the likelihood of two types happening to define two methods with the same name and signature apply equally well to the likelihood of the two interfaces having a common subset at all.
2. A and B were defined in the same library. Here, I suspect most library authors in a language with explicit interfaces would notice this and factor out the common methods in A and B into a separate interface that A and B derive from. You might argue that the library writer could forget to do this, but I think it's not much more probable than the scenario in which A and B have no structural subset because the common functionality has a different names, or has a different return type, or has the arguments in a different order.
You might have Name and Location where Location is (latitude longitude altitude). Now you want to map things, while existing objects Trucks with Name and Location are easy you want also map stuff with a name and address. You can get a latitude and longitude from an address, but not altitude and adding meaningless altitude is IMO a bug waiting to happen.
Ok like we have Close(). One could have Commit(), or MtxDeterminant() or Launch() things like that, where just a lots of people using same terminology in a domain are just bound to create collisions (on individual names!). Now high likely it is that a combination of those would be hit, not very sure on that.
The problem goes away with less ambiguous naming conventions (e.g. DrawGun() and DrawPicture()), but overloading is so gosh darn convenient, and thinking of unambiguous names is quite difficult. C# is really the only mainstream language that gets this right with explicit interface implementations.
In fact it's probably not that far away from where Go is now. Go already has something very similar for implicit composition / mixins. Now, if you do something like this:
type Foo struct {
Bar
}
If you then have:
type Foo struct {
Bar
Baz
}
Of course, this is slightly different to interface disambiguation, but there's no reason why you couldn't have two function definitions with the same name and some added interface qualifier - the functions would then only be callable if the object is cast to an interface. In Go, casting to an interface is a bit like boxing, as it creates a separate vtable for that object's methods to match the interface ABI.
Hence, you could have say:
a := Foo(foo)
b := Bar(foo)
On the other hand, there would be no foo.foo() method unless one were declared separately without any interface qualifier.
In languages that place more emphasis on type deduction and composition it's much more likely you're calling draw to tell it what to draw on, and the aggregate type information once you introduce an argument or two is actually quite rich.
Which leaves you with things like Close(), which, let's be honest, we don't need 30 interfaces that all just have Close in them just because the base language didn't happen to include one. The concept is simple and relatively unambiguous and almost always has to do with some kind of disposal of resource.
You'd never do this:
cb := cowboy.New()
screen.Paint(cb)
Also, would you not test your code? Like, at least run it and make sure it doesn't do crazy stuff? Maybe write some unit tests?
There can always be edge cases where functions don't work precisely as you expect, but that happens without interfaces, too. Pass an array into a sorting function and it turns out to sort by string length not alphabetically.... the programmer bears some small responsibility for actually understanding what the functions that he calls actually do.
For instance, in JDBC there is a PooledConnection.close() method and a Connection.close() method. Both Connection and PooledConnection are interfaces. They are semantically related but it's not a polymorphic relationship. PooledConnection does not extend Connection.
PooledConnection.close() must always close the actual physical connection to the database because PooledConnection is used by the connection pool itself. The Connection interface is used by the application and hence Connection.close() may close the connection or return it to a connection pool.
JDBC drivers usually come with implementations of both interfaces where the Connection implementation wraps an instance of a PooledConnection implementation. Arguably, being able to formally declare which interface a particular close method belongs to is beneficial in cases like this.
You're right that simply having this formal reference doesn't solve all problems that could possibly arise. But there's one form of confusion that is much less likely to arise.
As is so often the case, more flexibility comes with more opportunity for screw-ups.
I've used it around a Stats interface which required a single method: Statistics() map[string]string and have been able to hook up otherwise independent code into a common logger. Speaking of loggers, the fact that the built-in log package doesn't expose an interface has always been an annoyance to me specifically because I can't build my own code and know that it'll satisfy a log.Logger interface in other projects.
Don't forget "with the same semantics".
Go's approach is theoretically more error prone. It relies on names matching in a way that can happen by coincidence. The important part of explicit interfaces here is referencing a common declaration site, that could e.g. give informal requirements in the form of comments. I doubt Go's approach is particularly error prone in practice, though.
First of all, I agree that the accidental argument is not very convincing (two developers writing a method Launch(), one that launches a football and another that launches nuclear missiles).
However, we lose two important things with implicit interfaces:
- Code readability. It becomes much harder for a human to interpret what types are actually implemented.
- More importantly, it severely limits the tooling available since the compiler has a lot less knowledge about the types you are dealing with. Automatic refactorings are all but impossible with structural typing.
Overall, I really don't see the harm in saying explicitly "My type is called Account and it implements Serializable and Entity" as opposed to me having to guess by reading all its methods and also having to remember which methods are necessary to be an Entity or a Serializable.
Particularly, this is extremely wrong when talking about structural typing:
> - More importantly, it severely limits the tooling available since the compiler has a lot less knowledge about the types you are dealing with. Automatic refactorings are all but impossible with structural typing.
The compiler has as much information in structural typing as it does in nominal typing. The type of an object is determined at compile time either way, it's just that in structural typing Account implements Serializable and Entity because a subset of its methods match the definitions of Serializable and Entity, not because you said it does.
type foo = ...
impl hashable(foo) = ...
impl hashable(int) = ... // yep, adding to a builtin type
This means that my library can define a new trait and implement it on, say, int. Or I can define a new type and implement a pre-existing trait on it. But it prevents me from implementing pre-existing traits on pre-existing types, which is important for the compiler to be able to answer the question "does type A implement trait B" without having the answer change when a new library is linked.
They are if you use them in conjunction with immutable classes, such as Guava's immutable collections.
Unfortunately, immutability is only a promise and not typed. But in practice, having a member that is final and of an immutable class works well.
public interface FooBar
{
int foo();
int bar();
}
public Afob implements FooBar {...}
public interface Foo { int foo() }
public interface Bar { int bar() }
public interface FooBar extends Foo, Bar {}
interface FooBar extends Foo, Bar {}
interface Foo extends FooBar {
default int bar() { throw new UnsupportedOperationException(); }
}
Foo f = () -> 3;
But, assuming method
void doSomething(FooBar x) { ... }
doSomething(() -> 3);
doSomething((Foo)() -> 3);In Go, they can both declare the same interface or even skip formally declaring it and just agree to implement the same methods. Furthermore, if one of them decides to implement a new method, the other can just copy the method signature and they stay compatible. This makes it a lot easier to coordinate API changes.
That's a feature, not a bug. Say we're using implicit interfaces and have library A that provides an interface Foo and an application B that uses A and passes a Foo to some callback system. Now A gets updated and adds a method to Foo, but existing B binaries still call A with an implementation of the old version of Foo, and things fall apart.
Java's model (and COM's and MS-RPC's) model here is better because it enforces good interface hygiene: incompatible types get incompatible names. Then you can choose whether to support the old name as well as the new name, but you're at least consciously making that choice. D's model worries me because it feels like it's easier to accidentally break things.
One solution is for B to redeclare the same interface (even if it's the same at first). Then when A adds a method, B's interface is unchanged but it's a compatible subset, so nothing breaks.
Also, the specific form of breakage you mention can't happen in Go because Go has no binary shared libraries; all binaries are statically linked and libraries are distributed as source. If there's a compatibility break then a Go developer somewhere will get a compile error. With implicit interfaces you're very likely to be able to fix the problem yourself, without having to coordinate across separate organizations.
The explicit interfaces in Java and especially COM (with its GUID's) were designed to make binary compatibility between shared libraries easy to preserve, so the designers made different tradeoffs.
This is what defender methods in Java 8 are for.
Let's say I have a function A that depends on concrete type B, and that I only use a subset of B's functionality. Now say I decide, hey, I'd actually really like to be able to swap a different implementation of B at runtime.
With traditional interfaces, I would have to either:
a) define a subset of B's functionality as interface I and change B to implement I, or
b) define a subset of B's functionality as interface I and define a wrapper that implements I in terms of B.
If I choose (a) and many other callers end up doing the same thing to B, then B implements a mess of little micro-interfaces that it really should have no reason to care about. If I choose (b) then the implementation of A is way more complex than it seems like it ought to be.
===
One place this comes up all the time is testing: Object A relies on a subset of the interface exposed by service S, and service S is hard to create in test environment. With Go interfaces, A just defines an interface for the subset of S that it needs, and the test code for A implements that interface. S doesn't need to know anything about it.
The basic rule is you can implement a trait on a type if you declared either the trait or the type yourself. You just can't implement someone else's trait on someone else's type.
But Obj-C also allows for the same thing. You can declare @protocol (interface) conformance in a class category, and you can declare your own category on someone else's type.
No, why is it necessary?
In Java 8:
public interface Handler {
void serveHTTP(ResponseWriter w, Request r);
}
public class MyApplication {
public static void myHandler(ResponseWriter w, Request r) {
w.write("An even easier webserver?");
}
public static void main(String... args) {
Http.handle("/", MyApplication::myHandler);
}
}
Or even:
public class MyApplication {
public static void main(String... args) {
Http.handle("/", (w, r) -> w.write("An even easier webserver?"));
}
}
But if the HTTP library would directly accept a function, you could then just pass a function without that trick. Go doesn't mandate you use interfaces for callbacks (like Java did until 1.8), you can also define an API that accepts functions directly, provided they have a certain signature.
Also, the standard library hides this little trick from you, and just exposes the HandleFunc method, that lets you register plain functions as handlers. as in this example: http://golang.org/pkg/net/http/#ListenAndServe
I was not a fan of auto-unboxing for ints, for the same reasons.
There are a lot of good features in Java 8, but I'm not a fan of this particular one. Even if it saves a line of typing.
Kind of. The truth is that something absolutely barking mad goes on in the compiler, and then extra magic is injected at runtime:
http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...
But it behaves exactly as if there were little classes which implement interfaces. Just more efficient.
Edit: To clarify I mean if you had a Java X app deployed how hard is it to upgrade to Java 8? One thing I like, maybe naively, about Go is static binaries.
I mean sure, you have to install the new JVM, but if you don't have a system in place for making changes to your servers then you've got bigger problems than which language you're using. And honestly I think the JVM with its classpath approach solves the library problem better than most platforms; upgrading the JVM binary occasionally is no great hardship, and aside from that everything is just jars, dynamic but not getting in the way of each other unless you want them to. What happens when security holes are found in Go libraries, do you have to recompile anything that depends on them?
However, most of the work involved in doing that is paving the road so that version upgrades are faster. I would anticipate that moving from 7 to 8 will be much faster than moving from 6 to 7.
However this blog post is about how good core language design leads to unplanned patterns that are useful, like HandlerFunc and the private interface hack.
These things are a testament to how safe and simple Java is as a language.
Not having massive crappy code bases is a negative sign in terms of how reliable and easy to understand a language is.
Also known as...a class. Honestly, this is why classes exist: they are able to support both public and private interfaces, while interfaces and type classes are only able to support public interfaces. The closest we get to this essential aspect of OO programming in the H & M world is via existential types.
Here's just one example:
I have a post here of how you can partially define structure to be filled in by the consumer of the API: http://bitemyapp.com/posts/2014-04-11-aeson-and-user-created...
Can't do this without polymorphism and higher-kinded types.
It continually amazes me that people are willing to put up with Java.
Java as a language though was a primary response to over-correct and over-optimize for secure, correct, safe code based on the history of C's shortcomings. There's are many other lessons that have been learned since.
Java is really hard to beat apart from specialized formal methods verifiers (coq, CVC4), strongly-typed functional languages Haskell and similar derivatives for embedded industrial systems. If you're involved in safety critical systems, you should be using the simplest and easiest to understand formal methods tools as possible. If something's too esoteric, fewer people will be able to double-check the work.
For wider participation, it's a tradeoff to use one of the more popular languages that lack correctness aspects because of the absence of a learning curve.
Go has a few nice things going for it but its type system was clearly designed by people who stopped paying attention to type theory and compiler design in the late 90's.
By that line of reasoning, C is a great language. Better type systems exist to prevent many types of bugs. That Go ignores decades of good PL research is a valid point of critique.
Instead of beating around the bush, would you care to name a few essential, modern features the type system of Go is missing and which could prevent bugs in everyday programming tasks?
To be read as if chanted by some cheerleaders to a rather bored crowd at this point.
How about starting with old features that it are missing, since Go is literally decades behind PL research?
- Parametric polymorphism (plus constraints e.g. in the form of type classes).
- Algebraic data types
- Pattern matching (with non-exhaustiveness checks).
- Enforcing purity via the type system.
- No null pointers.
No, these are not esoteric Haskell features, but have been around in ML since the 70ies. Also, the claim that Go's designers want to keep the language simple is not a strong argument. A language such as ML is simple.
Also, many old(er) imperative languages adopted some of these type system features, such as Ada, C++, Java, and D.
It's also a bit like working with first-order propositional logic - well-founded and with its own unique simplicity, but you can't say everything with it and have alternatives.
So yes, I'd say that the type system of Go doesn't suck. It's not very good, and there are so many better things out there (rust, I'm looking at you), but it's a long way from being a disaster.
Go is not in that world. It isn't even in the same star system.
Not too bad when it's all in one source file, but get a few megabytes of code spread through a few thousand source files, and you've got a formula for chaos and heartburn.
So, it does happen a lot, or you are making duplicate code.
Yes I know about Erlang, no I won't touch Erlang again.
Static compilation and compilation speed make Go very attractive for large projects.
http://learnyousomeerlang.com/dialyzer
( not sure if Elixir supports it though, but it seems so:
It's just optional, and therefore doesn't get used much on open source projects. So the average quality of code suffers.
Whereas something like Go where extra import are hard errors, making best-practices mandatory keeps code to certain standard and it's zero work to setup.
Haven't heard of mandatory dialyzer type coverage yet. It would be kind of commit hook of sort, still external to the compiler though...
Convention > configuration
The easier it is to get going and contribute, the more people will use it. (Haskell pushed hard on this later on and has really benefited. Node did it early.)
Curious, what makes you say that?
At the time, there was no good binary<->string utf8 libraries, not sure what the state of the art is now.
Check it out :)
In Go, interfaces are small, and focused more on the function rather than the type. The function defines the methods it needs. So you can have a hundred small interfaces with one or two methods each, and a small handful of types that implement some percentage of those interfaces. Small interfaces makes your functions a lot more flexible. If all you need is a Read() method and a Close() method, instead of a huge number of potentially type-specific methods, then your method that takes a ReadCloser can be used by a lot more types.
You can do that in languages with explicitly implemented interfaces, but it means you need to write down that your type implements these 40 interfaces... and that's a hassle that isn't really needed or useful.
naively, if i define a non-implementable public interface as described in the article inside `foo.go` and put some test code next to it in `foo_test.go` that attempts to implement the interface with a special test version, then as we might expect, that doesn't work. if i put test code inside `foo.go` itself, `go test` doesn't appear to collect the test.
(i have no experience with go, apologies if i am missing something very obvious)
I wonder if make sense to merge the julia multi-methods + GO interfaces.
It's an uncommon thing to need to do, but this example shows that you can do it.