3 ms·

Other reasons to like go:- Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces -

• BrandonM 15y ago
  > Bold, delicious digression from oop - there literally is no relation between objects by identity, only by behaviour via interfaces - not your usual crappy java/c#/etc. interfaces, but rather 'true' interfaces, which are implicitly implemented by dint of a type fulfilling them. This is surprisingly powerful and the simplicity of it helps move you away from thinking about complexities you get with oop that have nothing to do with the problem at hand. I think you're referring to duck typing, which Python has leveraged heavily for over a decade (http://en.wikipedia.org/wiki/Duck_typing#History http://en.wikipedia.org/wiki/Duck_typing#History).
  • robfig 15y ago
    I'm not sure if what Go is doing is "Duck Typing", but there's a huge difference from Python. In Go, something implements an Interface by virtue of having the right method. No "implements" declaration is necessary. This is statically typed and safe at compile time, while Python is not. Does anyone know what this feature/pattern is called? As far as I know, Go is the first language to have this feature. Seems different from "Duck Typing" to me.. Reference: http://golang.org/doc/go_faq.html#types http://golang.org/doc/go_faq.html#types Rather than requiring the programmer to declare ahead of time that two types are related, in Go a type automatically satisfies any interface that specifies a subset of its methods. Besides reducing the bookkeeping, this approach has real advantages. Types can satisfy many interfaces at once, without the complexities of traditional multiple inheritance. Interfaces can be very lightweight—having one or even zero methods in an interface can express useful concepts. Interfaces can be added after the fact if a new idea comes along or for testing—without annotating the original types. Because there are no explicit relationships between types and interfaces, there is no type hierarchy to manage or discuss.
    • BrandonM 15y ago
      You're exactly describing duck typing. Resolving it at compile time in a static, "safe" way is a useful feature to be sure, but that doesn't mean it's not duck typing. Replace "Go" with "Python" in your final paragraph and it's just as true. Implement __setitem__(key, value) and you can use it in a dict-like way such that you can say "foo[bar] = baz" where foo is an object of your defined type. Define __iter__ on your type and you can now say "for x in foo: ..."
      • deleted 15y ago
        [deleted]
      • singular 15y ago
        It's a more restricted version of duck typing and requires an interface specifically to be set up for the type, though not for the type to explicitly implement it, so it's not quite the same thing.
        • BrandonM 15y ago
          Ahh... thanks for the clarification
    • zem 15y ago
      sounds more like ocaml's structural typing than python's duck typing.
• billmcneale 15y ago
  > extremely fast compiles - you miss this when you go back to languages that compile more slowly. It allows for rapid prototyping and trying stuff out without having to worry about a massive build time. You're paying a price for this speed: the Go compiler is single pass, which considerably cripples the language and imposes a lot of weird asymmetric features. And the compilation difference is really still in the ballpark of Java or C#, so it should definitely not be a factor in your decision. Odd that it was a design goal for Pike and his team, but everything is Go seems to indicate that the last language they programmed seriously in was C++ in the late 90's.
  • uriel 15y ago
    > the Go compiler is single pass, which considerably cripples the language and imposes a lot of weird asymmetric features. What evidence do you have that it cripples the language? And can you point to a single 'asymmetric feature' (whatever that means) caused by this? If you read any of the interviews with Rob, he clearly points out that the compile speed has little to do with it being 'single pass', and all to do with the package system. In my subjective experience the compiler is way faster than Java or C# compilers, and they still have plenty of room to optimize compiler speed (for example, there is plenty of stuff the compiler could do in parallel but at the moment doesn't because they have tried to keep the toolchain as simple as possible specially while the language is changing so fast.)
  • singular 15y ago
    > You're paying a price for this speed: the Go compiler is single pass, which considerably cripples the language and imposes a lot of weird asymmetric features. That's just not true - go is not single pass (as I understand it). There are separate passes performed for top-level types and code blocks, for example, and you can forward reference all you like. Actually, I've made a couple contributions to the language so have played with the internal implementation, and in fact the parse is done in one pass, setting up internal representations of the types/names/etc. before type-checking of top-level types is performed in a separate pass, then variable assignments, then function bodies. I can't see how this is single-pass, e.g. src/cmd/gc/lex.c:238:- // Process top-level declarations in three phases. // Phase 1: const, type, and names and types of funcs. // This will gather all the information about types // and methods but doesn't depend on any of it. // Phase 2: Variable assignments. // To check interface assignments, depends on phase 1. // Phase 3: Function bodies. defercheckwidth(); for(l=xtop; l; l=l->next) if(l->n->op != ODCL && l->n->op != OAS) typecheck(&l->n, Etop); for(l=xtop; l; l=l->next) if(l->n->op == ODCL || l->n->op == OAS) typecheck(&l->n, Etop); resumetypecopy(); resumecheckwidth(); for(l=xtop; l; l=l->next) if(l->n->op == ODCLFUNC) funccompile(l->n, 0); if(nerrors == 0) fninit(xtop); while(closures) { l = closures; closures = nil; for(; l; l=l->next) funccompile(l->n, 1); } dclchecks(); Unless I'm missing the point - what is crippled and where are the weird asymmetric features? One thing that go avoids is weird syntactic conflicts which require big lexer/parser hacks to work around. C# has quite a few of those, e.g. Foo<Bar<Baz>>> - that's emphatically not the same thing as a single-pass compiler. Actually Rob has talked about this[1] and highlights dependency management as the most important factor. I use C# in my day job and find the go compiler considerably quicker, incidentally. [1]:http://www.infoq.com/interviews/pike-google-go http://www.infoq.com/interviews/pike-google-go