6 ms·

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird

by krylon 9y ago

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that language. And don't get me wrong, I like both of these languages. But with Go, my intuition what I think a given piece of code should mean is nearly always in line with the language specification. The only other language I had this level of rapport with is Python. There are many things I miss in Go, but all in all, I think it is simplicity done right. BUT if Go had not also gotten the things right that you mention, it probably would not have become this popular.

nine_k 9y ago
Go does have brilliant simplicity! It's the simplicity of Pascal I used in middle school, and of Modula-2 I used on my freshman year, with basically the same syntax. I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, an easier way to combine simple things into complex things. They pay for that by higher resource consumption, of course. I do fondly remember a PDP-11 Pascal compiler reporting "15 KB used" after compiling my program; you can't get a Python process with these constraints. But by now we have _vastly_ more computing power.
- TheOtherHobbes 9y ago
  Go has human-sized simplicity. Programming language complexity is limited by human cognitive limitations, and Go has a small cognitive load. This makes it feel like a very intuitive language. That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems. Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned language, with some bumps under the floorboards where useful things were hammered down to make them go away, instead of being fully solved.
  - krylon 9y ago
    There is a good chance you are right. But as long as it is humans writing most/all Go code, fitting a human brain well is a valid design choice. Yes, it has its fair share of problems. But for now, I find it preferable to anything else we have got.
- pjmlp 9y ago
  > I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. Sadly it feels more like Oberon-07 than Modula-2, feature wise.
tetraodonpuffer 9y ago
> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work If you dig a bit it is completely understandable why it doesn't given how interfaces are laid out in memory, but from an intuitive standpoint you'd think that since you can do it in the scalar case you should be able to do it in the slice case too... This is a very minor nitpick, I do agree that compared to many other languages golang is very easy to mentally parse, at the expense of some expressivity at times. Whenever I code in it, which these days is pretty much all the time, I do miss some conveniences from other languages (generics, list comprehensions, ...) but of course every language has its tradeoffs, I most certainly miss golang's strengths every time I have to write some C or python.
- terminalcommand 9y ago
  IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see where some interface is declared and if/which interface is implemented, you have to rely on comments and resort to manual search to find out more. That may be easy in smaller codebases or worthy of effort in important codebases such as Go standard library. But all an all this ambiguity does not fit with Go's discipline to prevent human errors by making everything uniform and explicit as possible. Just for the sake of providing an example, let's look at time.go under https://golang.org/src/time/time.go https://golang.org/src/time/time.go, we can see in the comments of several functions that the programmer states a particular interface is implemented. Line 1112 of the aforementioned file is as follows: // MarshalBinary implements the encoding.BinaryMarshaler interface. func (t Time) MarshalBinary() ([]byte, error) { Now where is encoding.BinaryMarshaler declared? There is a package called encoding, maybe there? But the package has many many files, where would I find where BinaryMarshaler is defined? I'd have to resort to manual search. Now imagine that this is not an interface in the standard library, but rather an interface in some mediocre codebase that you're handed for the first time... Tl;dr All I'm saying is that runtime errors due to empty interfaces are not the only flaw of Golang. Interfaces as implemented in Go could in some cases present a serious threat to code structure.
johndubchak 9y ago
> I write in my free time to relax (sounds weird, I know) Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain. I suspect there are many many more who do the same.
- krylon 9y ago
  Huh. That are exactly the reasons I would give if I had to explain that hobby to somebody. ;-) Feels kind of good to know that I am not the only one doing this. When it goes really well, programming is akin to what I think meditation must be like. But explaining that to people who have never programmed themselves is hard.
insulanian 9y ago
> sounds weird, I know No, it doesn't.
- krylon 9y ago
  That is a relief. I know other people meet a similar purose by knitting or solving crossword puzzles, but explaining to them the trancendetal nature of their favorite pastime is quite difficult.
mioelnir 9y ago
> But something about is very compatible with the way my mind works. Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code. For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.

by krylon 9y ago

nine_k 9y ago

Go does have brilliant simplicity! It's the simplicity of Pascal I used in middle school, and of Modula-2 I used on my freshman year, with basically the same syntax. I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, an easier way to combine simple things into complex things. They pay for that by higher resource consumption, of course. I do fondly remember a PDP-11 Pascal compiler reporting "15 KB used" after compiling my program; you can't get a Python process with these constraints. But by now we have _vastly_ more computing power.

TheOtherHobbes 9y ago
Go has human-sized simplicity. Programming language complexity is limited by human cognitive limitations, and Go has a small cognitive load. This makes it feel like a very intuitive language. That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems. Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned language, with some bumps under the floorboards where useful things were hammered down to make them go away, instead of being fully solved.
- krylon 9y ago
  There is a good chance you are right. But as long as it is humans writing most/all Go code, fitting a human brain well is a valid design choice. Yes, it has its fair share of problems. But for now, I find it preferable to anything else we have got.
pjmlp 9y ago
> I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon. Sadly it feels more like Oberon-07 than Modula-2, feature wise.

tetraodonpuffer 9y ago

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work If you dig a bit it is completely understandable why it doesn't given how interfaces are laid out in memory, but from an intuitive standpoint you'd think that since you can do it in the scalar case you should be able to do it in the slice case too... This is a very minor nitpick, I do agree that compared to many other languages golang is very easy to mentally parse, at the expense of some expressivity at times. Whenever I code in it, which these days is pretty much all the time, I do miss some conveniences from other languages (generics, list comprehensions, ...) but of course every language has its tradeoffs, I most certainly miss golang's strengths every time I have to write some C or python.

terminalcommand 9y ago
IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see where some interface is declared and if/which interface is implemented, you have to rely on comments and resort to manual search to find out more. That may be easy in smaller codebases or worthy of effort in important codebases such as Go standard library. But all an all this ambiguity does not fit with Go's discipline to prevent human errors by making everything uniform and explicit as possible. Just for the sake of providing an example, let's look at time.go under https://golang.org/src/time/time.go https://golang.org/src/time/time.go, we can see in the comments of several functions that the programmer states a particular interface is implemented. Line 1112 of the aforementioned file is as follows: // MarshalBinary implements the encoding.BinaryMarshaler interface. func (t Time) MarshalBinary() ([]byte, error) { Now where is encoding.BinaryMarshaler declared? There is a package called encoding, maybe there? But the package has many many files, where would I find where BinaryMarshaler is defined? I'd have to resort to manual search. Now imagine that this is not an interface in the standard library, but rather an interface in some mediocre codebase that you're handed for the first time... Tl;dr All I'm saying is that runtime errors due to empty interfaces are not the only flaw of Golang. Interfaces as implemented in Go could in some cases present a serious threat to code structure.

johndubchak 9y ago

> I write in my free time to relax (sounds weird, I know) Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain. I suspect there are many many more who do the same.

krylon 9y ago
Huh. That are exactly the reasons I would give if I had to explain that hobby to somebody. ;-) Feels kind of good to know that I am not the only one doing this. When it goes really well, programming is akin to what I think meditation must be like. But explaining that to people who have never programmed themselves is hard.

insulanian 9y ago

> sounds weird, I know No, it doesn't.

krylon 9y ago
That is a relief. I know other people meet a similar purose by knitting or solving crossword puzzles, but explaining to them the trancendetal nature of their favorite pastime is quite difficult.

mioelnir 9y ago

> But something about is very compatible with the way my mind works. Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code. For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.