Go : Philosophy
Mayuresh Kathe
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
Is there a philosophy to writing Go programs?
Eric Clark
Do not communicate by sharing memory; instead, share memory by
communicating.
Mayuresh Kathe
Would you please elaborate?
This is for that collaborative work on the Go book.
Your name and contribution will be included in the book.
Peter Bourgon
<kathe.m...@gmail.com> wrote:
> Thank you.
> Would you please elaborate?
> This is for that collaborative work on the Go book.
> Your name and contribution will be included in the book.
This and many other zen-like proverbs on the topic of Go are present
in the Go Tutorial and Effective Go documents, freely available at
http://www.golang.org. It would make sense to me that somebody
compiling a book on the subject should be fairly familiar with those
two documents as a sort of prerequisite.
Also, I think it would be to everybody's benefit if book-related
discussions were moved to a separate discussion group.
Mayuresh Kathe
Peter, I believe, for the benefit of those who aren't Go programmers
yet, or who haven't understood Go as well as its creators, or even for
those who are good Go programmers and would like to become better,
having this and other book-related (concentrated) discussion on this
list would be essential, else, it might fragment the community.
You could always ignore these discussions, I intend to put up a better
subject line (Go : Book : ...) hence forth.
About the many other Zen-like proverbs, I'm not really going to push
the documentation into a spiritual experience and all that, the reason
I started this "Philosophy" discussion is because without it, people
mostly wouldn't understand the theory behind certain code
presentation.
So while they might code in a particular way, they wouldn't be aware
of why they are doing so.
Lastly, I've not referred to the document you suggested, simply
because, those documents was written by experts for experts, or
migrants from other similar programming languges.
What about those who are starting afresh?
If I refer those documents, I'll be writing from the perspective of
someone who already knows a lot about the language.
No offense against you or anyone else who thinks otherwise, but I
intend to continue this discussion and others like it over a period of
time till I've myself not got a clear picture about what I'm doing
vis-a-vis Go programming, and that's the essence which I intend to put
in the collaborative Go book.
Best.
Mayuresh Kathe
---
No offense against you or anyone else who thinks otherwise, but I
intend to continue this discussion and others like it over a period of
vis-a-vis Go programming, and that's the essence which I intend to put
in the collaborative Go book
adam_smith
based on looking at the package library. So I might be wrong, the
creators know better what their own philosophy behind it was of
course.
Okay so IMHO Go follows similar philosophy as found in the Unix C
programming community. There seems to be a more data oriented design
philosophy. First design the data structures and then the algorithms
fall in place afterwards. A willingness to not hide the data behind
too much abstraction as is common especially in the Java school of
thought. If you look at the packages source code you will see that a
lot of data structures are not encapsulated in any way.
Naming seems to follow what Rob Pike and Brian Kernighan writes about
in "The Practice of Programming":descriptive names for globals, short
names for locals. Names are quite terse and more abbreviations are
used than what would be common in say the Java and Smalltalk world.
"Clarity is often achieved through brevity" as they say in the book.
David Jones
Whenever there are two ways, go for the easier one. Don't think how,
think what. Don't race, talk.
I don't know how others see this, but for me this is the feeling of
golang.
tiago...@gmail.com
- Don't create futile abstractions;
- Prefer not create abstractions if they will increase the quantity of code needed for the problem.
Example of these are the missing generic type system. People from other schools of thought (eg: Java) tend to prefer generic abstractions like collections. I not saying specificaly collections abstractions are futile, I just saying in Golang they are considered unecessary.
A common case example:
Golang:
index := 4
list = append(list[0:index], newItem, list[index:])
Java:
int index = 4;
list.insert(4, newItem);
Seeing that code shows exactly what the Golang is doing to insert the item in the list. In java code that implementation is dependent.
One example of futile abstractions are tests:
On Java, JUnit have tons of methods to assert an infinite possibilities of types. Eg: assertEquals, assertNotEquals, etc.
assertEquals("expected", result);
In Go, the standard test library has only the Fail (and some few others) method. The testing by itself are made of "if"s structures. Eg:
if result != "expected {
t.Fail("result " + result + " not expected")
}
Even if Java style is somewhat smaller (in fact, there is as miracle code black hole in golang where all projects are commonly 30% smaller than Java counterparts), the Golang style is immediately readable as something obvious without the need to navigate in the inner classes of a framework like JUnit.
Once you get the philosophy stuck in your head, there is no way back.
Annotations, Context injection and configuration files are considered evil in Golang, where lambda-receiving-functions, Normal "constructors" (I know there is no real constructor, just common functions that play that role), and simple go code used for configurations are considered the norm. Eg:
Java:
@Transaction
public void savePerson(Person person) {
persistence.save(person)
}
Golang:
func savePerson(p model.Person) {
tr = transaction.NewTransaction()
tr.OnTransaction(func() {
persistence.save(p)
});
}
The Golang code is easier to debug. Just need to browse to OnTransaction function. In Java is somewhat more dificult to know where the call is intercepted and the transaction is inserted.
Java:
@WebServlet(name="myServlet", urlPatterns="/myServlet")
Golang:
http.Handle("/myPath", myHandler)
So in golang magic configuration are not well received. Its not that easy to see how a Servlet is configurated in a Java container, that knowlegde is given as granted by an framework/container. In Golang it is easily common to see how the things work under the hood.
In Golang a balance between performance and readability tends more to the side of performance than in other languages.
Eg: In Java abstraction and readability are the norm above all other things. Only when things get really ugly, tunning and performance are dealed on. Don't let me start about Hibernate/JPA!!
I use Java as a counter example because is what I work with. I love both languages with their strenghts and weakenesses. They are fundamentally contrary in terms of philosophy.
Java = formality, abstractions, frameworks always that IS possible.
Golang = simplicity, economy of resources, speed, NOT use frameworks always that is possible.
