Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
Thread beginning with comment 552189
To read all comments associated with this story, please click here.
Comment by kwan_e
by kwan_e on Tue 12th Feb 2013 01:48 UTC
kwan_e
Member since:
2007-02-18

It is blisteringly obvious in hindsight that enforcing visibility at the package level instead of the class level is the right way to do it. Who cares if the other class poking around in your class’s internals is your subclass or whatever?


Which you can already do in C++ and Java, etc. In C++, there's nothing to stop you declaring everything in a class public - which is what a struct is in C++.

The merits of why this is better can be debated, but just because he learnt it one way and never considered the alternative until he came across Go is a poor excuse.

Another example of Go’s modernity is the decision to make the directory the fundamental unit of packaging.


Java does this already.

For example, they straightened out the confusing mess of longs and shorts that had accumulated over thirty years with straightforward names: int8, int16, int32, and int64. There are also unsigned variants (uint8, etc.).


I quite like LLVM's IR for integers. i8, i16, i32 etc.

And what’s up with all the languages that claim all you need are linked lists? I’m sorry, this is not 1958, and you are not John McCarthy.


John McCarthy used lists, but the implementation need not be linked lists. Most LISPs these days don't claim "list only". Even with the traditional LISP list structure, you're not actually limited to linked lists. The ability to create trees with cons cells was realized early.

Reply Score: 4