Hawaiʻi's Technology 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?
Update 5/13/11: Go has introduced signal constructs called Defer, Panic and Recover that provide a form of exception handling. I haven't yet decided if I like them better than exception handling in Java / C#.
Ikayzo - Design • Build • Localize | Web • Desktop • Mobile
Views: 139
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. :)
-
-
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.
-
-
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 "
-
-
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.
-
-
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.
-
-
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.
-
-
Tim Dysinger: "but what about super class constructors and concrete (non-abstract) methods?" this is OO thinking.
Yes, it is. I think the complete rejection of OO concepts by folks purely on the functional side is a bit premature.
Everything new coming out of language research is moving away from OO and towards functional programming.
Well... its certainly fashionable ;-) I think there are a lot of interesting concepts in the new (and not so new) functional languages, but there are many tasks that lend themselves better to OO systems (UI libraries, for example.) Also, languages like C# 4 are evolving in interesting ways, incorporating concepts from functional programming and other approaches. There is plenty happening outside of functional programming. I think you will see many systems that use a hybrid. We already see this with Facebook and Ginx.
"The lack of generics." It's pretty generic to not have Types.
I'm assuming you know this, but I was referring to the ability to do things like specify the type constraints for elements in a datastructure.
"The lack of exceptions" exceptions are just message-passing - you can pass errors back to callers in Erlang without exception classes.
You could say that nearly everything (method calls, operations, assignments, etc.) are "just message-passing". Exceptions are messages that are routed and handled in a structured, predefined manner designed for error handling.
© 2025 Created by Daniel Leuck.
Powered by
You need to be a member of TechHui to add comments!
Join TechHui