6 ms·

Go is designed as a language for the average. Average programmer doing averagely complex things in the current average environment (ie web services, slinging pr

by rswail 6y ago

Go is designed as a language for the average. Average programmer doing averagely complex things in the current average environment (ie web services, slinging protobufs or equivalent). That is its specific design goal for Google. It's designed to be simple, to be boilerplate, to be easily reviewable/checkable by coding teams. Not sure why Go and Rust are always the compared languages. Go is designed to replace Java/RoR/Python in Enterprise-land, not to replace C/C++. Rust is designed to replace C/C++ in system-land, embedded, kernel, thick app components (browsers are probably the most complex apps running these days on end user systems). The entire focus is zero-cost abstractions.

piva00 6y ago
Because for a long time people were trying to shove Go into use cases that before were covered by C applications. Some infrastructure has been developed in Go (Kubernetes being quite prominent) and so the overlap between systems programming and web/enterprise got muddy. Rust can't cover the enterprise use-cases of Go the same way that Go won't ever cover what Rust can do on systems/embedded level but there is enough overlap in some cases to confuse people into trying to compare them directly.
- pjmlp 6y ago
  You mean like the USB Armory security key running Go bare metal? https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
  - piva00 6y ago
    I don't follow what you mean by that, care to elaborate?
    - pjmlp 6y ago
      That is a use case that many would assert should be written in C, yet F-Secure decided that given the security scenario, bare metal Go was the way.
      - piva00 6y ago
        Ah! Yes, that is a case that I would consider could have an overlap between Go/Rust and C. Thanks for sharing it, had no idea it was implemented in bare metal Go, will check it out :)
vlads_ 6y ago
This is pretty much correct, except for 2 minor gripes: Firstly, Go was meant to replace C++ in server-land. The fact that it ended up being a suitable alternative for Java/Python in many cases was a happy accident. Secondly, I don't think the fact that Go making the opposite trade-offs in terms of (let's say) programmer effort vs. CPU clock cycles means it is a "language for the average". Go is great for any number of interesting high-level server-side components where it being done in half the time is better than it being 15% faster.
pjmlp 6y ago
Because originally Go was designed while Pike and others were waiting on C++ builds and he couldn't grasp why C++ developers don't jump of joy into adopting Go. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
entha_saava 6y ago
Wait... I have seen average programmers who can write less dumbed down code than the most succinct code possible in Go. I have seen below average programmers who understand how to use generic data structures / programs in C++ / Java / C# etc.. > It's designed to be simple, to be boilerplate, to be easily reviewable/checkable by coding teams. Boilerplate and easily reviewable are at the odds. Unless Enterprise style java is the bar, it is hard for anyone to say that. Go is too much boilerplate than average programmer's python code, for example. Don't tell me python is dynamic. The average programmer doesn't do metaclass magic. Being so much boilerplate and verbose `if err != nil` and no generics and no methods/functions for common operations like finding the index of an element in an array. All this leads to for-loop-inside-while-loop-inside-for-loop attrocities where it is harder to decipher what the intention is. Compare to python where you have methods on collections to carry out common manipulations, and list comprehension in python is so cleaner than 4 line imperative go code. Go seems to miss why python/JS/ruby are so popular. It is because so much is built in that you can communicate __intent__ clearly without getting bogged down in details. Compared to any modern language that's not C and not mediaeval C++, Go is so much more verbose. Even java has enough shortcuts to do these common things. And don't start telling me this leads to incomprehensible code. Coding standards are there. What's unreadable is 8 level indented imperative attrocity of blue collar language Go. > Not sure why Go and Rust are always the compared languages. They both emerged at same time and have some overlapping scope - eg static native compilation, memory safety etc.. but there similarities end. However, there is lack of a a popular, succinct natively compiled language which gets out of the way to write software. Everyone knows expressive languages need not be slow or difficult to deploy. Some people have to write Go in dayjob and the sibling rust, having quality-of-life improvements that anyone expects in a post-2000 language [0], seems to be a closer candidate to comparison (even though rust isn't the optimal language for the things Go is used for, given it is a systems language with static memory management) Others like D and Nim have a fraction of users. Of course there are also some vocal rust fanboys who think crab god is not popular because world is anti intellectual.
- geodel 6y ago
  Well you have seen lot of things which I guess is fine. Others may have seen different things. In my last 10 workplaces and dozens of projects I have seen code which would be at least 5-10 times more verbose than an equivalent Go code. I also differentiate verbosity of individual expression vs verbosity of overall project due to dependencies, code arrangement and other associated files/ resources etc to produce a deliverable. > Go seems to miss why python/JS/ruby are so popular. Not sure what is there to miss especially since Go is pretty popular for its age. Considering it is not even mandated or officially supported like Swift by Apple, or Dart/Kotlin by Google/Android.
kevincox 6y ago
I'm just going to comment on one point of your comment: > to be easily reviewable/checkable by coding teams. I strongly disagree with this. I find Go code to be incredibly difficult to read. This is because of two main reasons. The first is that the lack of expressive power in the language means that many simple algorithms get inlined into the code instead of using an abstraction with a simple and understandable name. I find that the first pass of the code is me reading over the lines (each of which is very simple and understandable) and virtually abstracting it into what the code actually does. I find that the interesting business logic is lost in all of the boilerplate. out := []int{} for _, v := range input { number, err := fetchData(v) if err != nil { return nil, err } if math.Abs(float64(number)) <= 2 { continue } out = append(out, v) } return out vs input.iter() .map(|&v| fetch(v)) .filter_ok(|number| number.abs() > 2) .collect() As I said, every line in the Go is simple (except maybe for append, but generics can help with that). However the actual business logic is lost in the boilerplate. In the second example (Rust with one existing and available helper function) the boilerplate is much less and each line basically expresses a point in the business logic. There are really two bits of boilerplate here `filter_ok` instead of `filter` to handle the errors from `fetch` and the `collect` to turn the iterator into a collection (although maybe you could improve the code by returning an iterator instead of a collection and simplify this function in the process). Secondly the "defaults are useful" idea is in my opinion the worst mistake the language made. They repeated The Billion Dollar Mistake from C. I have seen multiple expensive production issues as a result of it and it makes code review much harder because you need to check that something wasn't uninitialized or nil. It is absolutely amazing in Rust that I don't have to worry about this for most types (depends on your exact coding style, in the above example there is never a variable that isn't "complete"). So while Go may be quick to write. I think the understandably is deceiving. Yes, I can understand every line, but understanding the program/patch as a whole becomes much more difficult because of the lack of abstraction. Humans can only hold so much in our head, making abstraction a critical tool for understandable code. So while too much of the medicine can be worse that the disease I think Go aimed - and hit - far, far below the ideal abstraction level.
- vlads_ 6y ago

by rswail 6y ago

piva00 6y ago

Because for a long time people were trying to shove Go into use cases that before were covered by C applications. Some infrastructure has been developed in Go (Kubernetes being quite prominent) and so the overlap between systems programming and web/enterprise got muddy. Rust can't cover the enterprise use-cases of Go the same way that Go won't ever cover what Rust can do on systems/embedded level but there is enough overlap in some cases to confuse people into trying to compare them directly.

pjmlp 6y ago
You mean like the USB Armory security key running Go bare metal? https://www.f-secure.com/en/consulting/foundry/usb-armory https://www.f-secure.com/en/consulting/foundry/usb-armory
- piva00 6y ago
  I don't follow what you mean by that, care to elaborate?
  - pjmlp 6y ago
    That is a use case that many would assert should be written in C, yet F-Secure decided that given the security scenario, bare metal Go was the way.
    - piva00 6y ago
      Ah! Yes, that is a case that I would consider could have an overlap between Go/Rust and C. Thanks for sharing it, had no idea it was implemented in bare metal Go, will check it out :)

vlads_ 6y ago

This is pretty much correct, except for 2 minor gripes: Firstly, Go was meant to replace C++ in server-land. The fact that it ended up being a suitable alternative for Java/Python in many cases was a happy accident. Secondly, I don't think the fact that Go making the opposite trade-offs in terms of (let's say) programmer effort vs. CPU clock cycles means it is a "language for the average". Go is great for any number of interesting high-level server-side components where it being done in half the time is better than it being 15% faster.

pjmlp 6y ago

Because originally Go was designed while Pike and others were waiting on C++ builds and he couldn't grasp why C++ developers don't jump of joy into adopting Go. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

entha_saava 6y ago

Wait... I have seen average programmers who can write less dumbed down code than the most succinct code possible in Go. I have seen below average programmers who understand how to use generic data structures / programs in C++ / Java / C# etc.. > It's designed to be simple, to be boilerplate, to be easily reviewable/checkable by coding teams. Boilerplate and easily reviewable are at the odds. Unless Enterprise style java is the bar, it is hard for anyone to say that. Go is too much boilerplate than average programmer's python code, for example. Don't tell me python is dynamic. The average programmer doesn't do metaclass magic. Being so much boilerplate and verbose `if err != nil` and no generics and no methods/functions for common operations like finding the index of an element in an array. All this leads to for-loop-inside-while-loop-inside-for-loop attrocities where it is harder to decipher what the intention is. Compare to python where you have methods on collections to carry out common manipulations, and list comprehension in python is so cleaner than 4 line imperative go code. Go seems to miss why python/JS/ruby are so popular. It is because so much is built in that you can communicate __intent__ clearly without getting bogged down in details. Compared to any modern language that's not C and not mediaeval C++, Go is so much more verbose. Even java has enough shortcuts to do these common things. And don't start telling me this leads to incomprehensible code. Coding standards are there. What's unreadable is 8 level indented imperative attrocity of blue collar language Go. > Not sure why Go and Rust are always the compared languages. They both emerged at same time and have some overlapping scope - eg static native compilation, memory safety etc.. but there similarities end. However, there is lack of a a popular, succinct natively compiled language which gets out of the way to write software. Everyone knows expressive languages need not be slow or difficult to deploy. Some people have to write Go in dayjob and the sibling rust, having quality-of-life improvements that anyone expects in a post-2000 language [0], seems to be a closer candidate to comparison (even though rust isn't the optimal language for the things Go is used for, given it is a systems language with static memory management) Others like D and Nim have a fraction of users. Of course there are also some vocal rust fanboys who think crab god is not popular because world is anti intellectual.

geodel 6y ago
Well you have seen lot of things which I guess is fine. Others may have seen different things. In my last 10 workplaces and dozens of projects I have seen code which would be at least 5-10 times more verbose than an equivalent Go code. I also differentiate verbosity of individual expression vs verbosity of overall project due to dependencies, code arrangement and other associated files/ resources etc to produce a deliverable. > Go seems to miss why python/JS/ruby are so popular. Not sure what is there to miss especially since Go is pretty popular for its age. Considering it is not even mandated or officially supported like Swift by Apple, or Dart/Kotlin by Google/Android.

kevincox 6y ago

I'm just going to comment on one point of your comment: > to be easily reviewable/checkable by coding teams. I strongly disagree with this. I find Go code to be incredibly difficult to read. This is because of two main reasons. The first is that the lack of expressive power in the language means that many simple algorithms get inlined into the code instead of using an abstraction with a simple and understandable name. I find that the first pass of the code is me reading over the lines (each of which is very simple and understandable) and virtually abstracting it into what the code actually does. I find that the interesting business logic is lost in all of the boilerplate. out := []int{} for _, v := range input { number, err := fetchData(v) if err != nil { return nil, err } if math.Abs(float64(number)) <= 2 { continue } out = append(out, v) } return out vs input.iter() .map(|&v| fetch(v)) .filter_ok(|number| number.abs() > 2) .collect() As I said, every line in the Go is simple (except maybe for append, but generics can help with that). However the actual business logic is lost in the boilerplate. In the second example (Rust with one existing and available helper function) the boilerplate is much less and each line basically expresses a point in the business logic. There are really two bits of boilerplate here `filter_ok` instead of `filter` to handle the errors from `fetch` and the `collect` to turn the iterator into a collection (although maybe you could improve the code by returning an iterator instead of a collection and simplify this function in the process). Secondly the "defaults are useful" idea is in my opinion the worst mistake the language made. They repeated The Billion Dollar Mistake from C. I have seen multiple expensive production issues as a result of it and it makes code review much harder because you need to check that something wasn't uninitialized or nil. It is absolutely amazing in Rust that I don't have to worry about this for most types (depends on your exact coding style, in the above example there is never a variable that isn't "complete"). So while Go may be quick to write. I think the understandably is deceiving. Yes, I can understand every line, but understanding the program/patch as a whole becomes much more difficult because of the lack of abstraction. Humans can only hold so much in our head, making abstraction a critical tool for understandable code. So while too much of the medicine can be worse that the disease I think Go aimed - and hit - far, far below the ideal abstraction level.

vlads_ 6y ago