Hawaii's Science, Technology and New Media Community
Google Go
I just read through the language spec and memory model for Go, Google's new language (thank you for the link Scott.) There are a lot of things l like about the language, such as its approach to concurrency, heavy use of type inference (which we also see in C# and Java 7), ruby-like array and map manipulation syntax, etc., but I'm not entirely sold on the type system. Go has no concept of inheritance, which they cite as a good thing because Go types are "light". From the Go docs: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.Um... OK, so you have this sort of loosey-goosey approach to interfaces (if I have the methods, I satisfy the interface), but what about super class constructors and concrete (non-abstract) methods? I'm having trouble imagining libraries such as UI toolkits (WPF, Flex, Swing, etc.), which effectively make heavy use of relatively deep inheritance trees, being written in as elegant a manner in Go. Those super classes are doing a lot of work, and the type hierarchies provide a nice taxonomy for the API. Perhaps Go is advocating the use of a different paradigm to accomplish the same thing, but it doesn't seem to be readily evident from the docs.
Two areas where I think they are definitely making a mistake:
- The lack of exceptions. I guess they don't like the whole concept of signals.
- The lack of generics. The docs say they may get around to generics, but that it isn't a priority.
Thoughts?
Ikayzo - Design • Build • Localize | Web • Desktop • Mobile
Tags: go, google go, programming language
Comment
-
Comment by Daniel Leuck on November 21, 2009 at 5:57pm -
Tim Dysinger: I program my scheme in lisp. I program my editor in lisp (elisp). I program my java in lisp (clojure). I program my erlang in lisp (LFE).
This sounds like a great talk for one of the local coder groups.
-
Comment by J. David Beutel on November 21, 2009 at 12:44pm - The lack of exceptions is a deal-breaker for me. I hated handling them in-band with C.
-
Comment by Boris Ning on November 20, 2009 at 7:13pm -
I had a difficult time learning Scheme in school.
I did enjoy learning about dynamic typing, tail recursion, S-expressions, and manipulating lambda expressions but it didn't come very natural to me.
OO came fairly natural to me. It is true that OO solves a lot of problems very elegantly but there are times when it is not necessary. I typically stick to C/C++ and there are times when sticking to a procedural way of solving a problem leads to more efficient code and better code maintainability.
Of course, I do enjoy learning other languages. It's nice to see comparisons and benchmarks between languages to see how effective it is at solving a particular problem.
Although I prefer C++ over other languages, I don't see myself writing the same C++ in 20 years.
If the C++ committee ever get their act together, we might see a new C++ (C++0x) sometime in 2012.
-
Comment by Tim Dysinger on November 20, 2009 at 4:42pm - True other languages do give you meta-programming abilities. From what I have seen, the meta-programming abilities pale in comparison to lisp. Also what I don't like is that every language besides lisp (and what turns me off from wanting to learn Go and other new languages) is that they all have a limited ridged set of new special forms for the core language. To me language design hit a high point 50 years ago (lisps). :) That's my $0.02. I program my scheme in lisp. I program my editor in lisp (elisp). I program my java in lisp (clojure). I program my erlang in lisp (LFE). It's pretty easy to flip back and forth between them also. I love it. :)
-
Comment by Daniel Leuck on November 19, 2009 at 2:39pm
-
Hi Tim - I agree that functional languages like Erlang lend themselves to systems with heavy concurrency requirements such as Facebook's chat, switching systems, etc.
Lisp certainly has its charms, although its not the only language with the meta-programming capabilities you mentioned. There is a lot of movement in the LOP (language oriented programming) community, including numerous tools and meta-languages for creating DSLs (domain specific languages.)
There is state strewn everywhere in OO apps and shared-state threading tools in OO rely on locks to make sure you don't have threads clobbering each other's shared state. It's very difficult for the average programmer not to hang him/herself.
True. Concurrent programming is hard, and Java's approach certainly has its drawbacks.
To me this is Java and C# and co are antiquated and why I don't code in OO langs anymore very much.
I think we will have to agree to disagree on this. Thats OK - forums are boring if everyone agrees :-) I think OO solves a lot of problems very elegantly. It really depends on the domain.
argh no prevews before posts
I agree - this is annoying. Hopefully it will be rectified soon.
-
Comment by Tim Dysinger on November 19, 2009 at 8:54am
- argh no prevews before posts :/ It should read " When your world is concurrency " and " To me this is why Java and C# and co are antiquated "
-
Comment by Tim Dysinger on November 19, 2009 at 8:51am
-
dan:
I spent a long time as Java programmer (11 years - time I wish I could have back now). What I meant by not being able to safely write an app for 256 cores is that Java and C# and OO in general don't give you the tools to not hang yourself.
There is state strewn everywhere in OO apps and shared-state threading tools in OO rely on locks to make sure you don't have threads clobbering each other's shared state. It's very difficult for the average programmer not to hang him/herself. When you world is concurrency and not GUI widgets, OO is a downer.
To me this is Java and C# and co are antiquated and why I don't code in OO langs anymore very much. In fact in the last 18 months, other than a few ruby scripts, I have not written any OO code - only lisp. My whole team does lisp full time. I don't think I'll ever move off of lisps now that I have a solid taste. There's no new syntax ever - I love it. If the language doesn't have it, you should be able to add what you need and not be corralled into what the language designer decided was enough. Lisp is the only language that really gives you that power (IE, CLOS was added to Common Lisp as a library when OO was all the rage).
I was joking about generics ;)
There is a reason why even MicroSoft has a small army of Haskell programmers in the back rooms.
I read this a while back http://en.wikipedia.org/wiki/Linguistic_relativity and as the theory applies to linguistics in spoken language, it also applies to comp. sci. - it's so important to keep challenging assumptions and learning new ways of thinking. I love it. Haskell is next for me.
-
Comment by Daniel Leuck on November 19, 2009 at 12:54am
-
Brian - Well said.
Boris - Generics refer to types that take type parameters rather than types in general. For example, if Go supported generic programming I could construct an instance of a class called Set that only accepts colors as elements:
colors := new(Set<Color>);
Go has this concept for the built-in slice and map type as seen in their example:m := map[string]int{"one":1 , "two":2}, but you can't define your own generic types (types that have type parameters.)
The Go docs have this to say about generics:
Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. Generics are convenient but they come at a cost in complexity in the type system and run-time... (clip) ...This remains an open issue.
-
Comment by Boris Ning on November 18, 2009 at 7:43pm
-
Hmm... "Go" does praise itself as a language in between Python and C++.
Without any solid benchmarking, it's quite difficult to see whether or not there is a huge performance increase between using Go and other programming languages. According to the official Go demonstration video (http://www.youtube.com/watch?v=rKnDgT73v8s), Go's performance is within 10 - 20% of C. However, I don't think that's really trust-worthy until we get some performance benchmarks.
As for the syntax, it is a mix of C and Python.
The only thing generic that Go provides seems to be "interface".
It's pretty much the same thing as an abstract class.
Other than that, it is lacking in terms of generics.
I do agree, Brian, that it depends on which language fits the job best, rather than what the overall best is.
That being said, I probably wouldn't try out Go until there are more reviews on it.
-
Comment by Brian Russo on November 18, 2009 at 4:53pm -
Oh and I just have to throw in my dig about functional programming. We've been told that procedural programming has been dying for years. Academia has always been infatuated with functional languages (Lisp, Haskell, etc). We've been told that OO is imperfect and would die. I think the RDBMS was killed off by intellectual years ago in favour of OODBMS, etc.. You can go on.
Fact is that the reason we have multiple languages, etc - there is no one size fits all solution. People are always inventing and reinventing paradigms. The real kicker is knowing which tool fits which job - not debating endlessly about what the end-all "best" is.
© 2010 Created by Daniel Leuck
You need to be a member of TechHui to add comments!
Join TechHui