One perception I have about Go philosophy:
- 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.
Em segunda-feira, 28 de junho de 2010 10:43:48 UTC-3, Mayuresh Kathe
escreveu:
>
> Like the UNIX philosophy (below);
> 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?
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
