6 ms·

What an interesting article, thanks for the writeup. Are you using Docker for containers? As a language neophyte I found this far more persuasive than argumen

What an interesting article, thanks for the writeup. Are you using Docker for containers? As a language neophyte I found this far more persuasive than arguments over emergent behaviour[1], because it talks about actual practice, as opposed to talking in abstractions (which rarely leads to fruitful discussion). The attraction of Go to me is in its commitment to simplicity, at the expense of some power or terseness it becomes easy to read, easy to extend, and hard to use to create monstrous complexity. It feels like an improved C rather than building on the traditions of C++ say. The package system, import system, composition and no inheritance, and extensive use of interfaces all encourage simplicity above all. Composition - it's harder to create huge taxonomies which all depend on a common root. Packaging - encourages very simple small components rather than huge frameworks which are hard or even impossible to understand all at once or separate into components. Godep[2] looks interesting here, thanks for the link. Interfaces - similar to many other languages, but without the boilerplate of declarations (this sort of decision is where controversies start - what some see as boilerplate others see as important contracts, same goes for header files). It is of course missing a few things which would be nice, but nothing should stop people trying it out today - if you value simplicity above all, Golang will probably appeal. 1. https://news.ycombinator.com/item?id=7653164 https://news.ycombinator.com/item?id=7653164 2. https://github.com/tools/godep https://github.com/tools/godep

azth 13y ago
> It feels like an improved C rather than building on the traditions of C++ say. I do feel that Go is an improved C (perhaps Java-lite). If you want a better C++, you might want to check out Rust.
- NateDad 13y ago
  Please don't call it java lite. Yes, it targets many of the same projects you might write in java, and it has garbage collection, but it's very different from java in the feel and the resultant code, and nothing "lite" about it.
  - pron 13y ago
    Not to get into an argument, but I find Go and (modern) Java almost identical. Not in exact features (they treat interfaces and exceptions differently), but in the general philosophy of the language (i.e. "blue collar") and the level of abstraction. Go is simpler than Java, so I agree with the "lite" as well. I would use Go for simple, relatively small, self-contained projects, and Java for bigger, heavy-duty stuff. The languages are so similar that I hardly feel it when I switch from one to the other. Obviously, you can't compare small Go projects to huge Java monstrosities that were written in the old Java style (lots of XML configuration etc.), but modern Java and Go are hardly distinguishable (in approach; not syntax). Maybe I'm particularly prone to this view because I've implemented true fibers (goroutines) and channels for the JVM, so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such).
    - azth 13y ago
      > so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such). How does performance compare?
      - pron 13y ago
        As usual, that depends. Java performs better on function calls (because of the JVM's inlining JIT) and garbage collection. But because fibers are not native to the JVM, they do incur some overhead. If the fibers perform no work, then you're essentially just measuring the overhead, and Go would perform better. The more work is done, the more the advantage goes to Java. With regards to IO, fiber-blocking IO currently uses the JVM's asynchronous NIO (which uses epoll/kqueue) under the covers, unchanged. But Java's async NIO is intended to be thread-safe, so there is lots of unnecessary synchronization going on there. The result is about 7% slower than Go. Again, the more computation work you do, the more the performance swings in favor of Java. We can do much better with IO by plugging our own NIO provider (Java's dynamic linking everywhere is awesome), but because the performance is really good as it is, it's not a top priority for us at the moment. EDIT: the reason I would use Java over Go for all the "serious stuff" isn't primarily performance, though. It's the incredible monitoring and profiling capabilities, hot code swapping and other stuff that's possible with full dynamic linking.
peferron 13y ago
Go's simplicity didn't stop me from ending up with a messy, bloated and monolithic project on my first try, but static typing and good test coverage makes refactoring relatively painless.
- jweir 13y ago
  I reckon there is no language that can prevent a bloated and messy code base. Avoiding that comes from both understanding the solution and how to write the solution with the language.
  - krakensden 13y ago
    Indeed- languages without bloated and messy codebases are languages without serious users.
- deleted 13y ago
  [deleted]

azth 13y ago

> It feels like an improved C rather than building on the traditions of C++ say. I do feel that Go is an improved C (perhaps Java-lite). If you want a better C++, you might want to check out Rust.

NateDad 13y ago
Please don't call it java lite. Yes, it targets many of the same projects you might write in java, and it has garbage collection, but it's very different from java in the feel and the resultant code, and nothing "lite" about it.
- pron 13y ago
  Not to get into an argument, but I find Go and (modern) Java almost identical. Not in exact features (they treat interfaces and exceptions differently), but in the general philosophy of the language (i.e. "blue collar") and the level of abstraction. Go is simpler than Java, so I agree with the "lite" as well. I would use Go for simple, relatively small, self-contained projects, and Java for bigger, heavy-duty stuff. The languages are so similar that I hardly feel it when I switch from one to the other. Obviously, you can't compare small Go projects to huge Java monstrosities that were written in the old Java style (lots of XML configuration etc.), but modern Java and Go are hardly distinguishable (in approach; not syntax). Maybe I'm particularly prone to this view because I've implemented true fibers (goroutines) and channels for the JVM, so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such).
  - azth 13y ago
    > so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such). How does performance compare?
    - pron 13y ago
      As usual, that depends. Java performs better on function calls (because of the JVM's inlining JIT) and garbage collection. But because fibers are not native to the JVM, they do incur some overhead. If the fibers perform no work, then you're essentially just measuring the overhead, and Go would perform better. The more work is done, the more the advantage goes to Java. With regards to IO, fiber-blocking IO currently uses the JVM's asynchronous NIO (which uses epoll/kqueue) under the covers, unchanged. But Java's async NIO is intended to be thread-safe, so there is lots of unnecessary synchronization going on there. The result is about 7% slower than Go. Again, the more computation work you do, the more the performance swings in favor of Java. We can do much better with IO by plugging our own NIO provider (Java's dynamic linking everywhere is awesome), but because the performance is really good as it is, it's not a top priority for us at the moment. EDIT: the reason I would use Java over Go for all the "serious stuff" isn't primarily performance, though. It's the incredible monitoring and profiling capabilities, hot code swapping and other stuff that's possible with full dynamic linking.

peferron 13y ago

Go's simplicity didn't stop me from ending up with a messy, bloated and monolithic project on my first try, but static typing and good test coverage makes refactoring relatively painless.

jweir 13y ago
I reckon there is no language that can prevent a bloated and messy code base. Avoiding that comes from both understanding the solution and how to write the solution with the language.
- krakensden 13y ago
  Indeed- languages without bloated and messy codebases are languages without serious users.
deleted 13y ago
[deleted]