10 ms·

Less is exponentially more (2012)

67 points by tpaschalis 6y ago

free_rms 6y ago
Pike's take is pretty unfair to C++11, given how ideas like 'rvalue references' held up REALLY well. Yes, they were introducing even more complexity to a complex language, but how else are they supposed to incorporate better ways of doing things while maintaining backwards compatibility? I suppose one could always just build a new language that doesn't have the historical cruft, but in this case that's Rust and not Go.
jasode 6y ago
Previous discussion since the HN "past" link doesn't bring up the prior thread because tld was ".de" instead of ".com" : https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319
ses1984 6y ago
>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?
- ChrisSD 6y ago
  To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class-based" languages, not anything to do with types in general.
  - ses1984 6y ago
    Yeah but it feels almost like a strawman, it feels out of place.
  - fernmyth 6y ago
    > To be honest programmers have a habit of being very loose with language. I wish this weren't true. It's quite damning. It's less bad in a real-time conversation, with fast feedback about how well we're being understood. But it still hints that we don't have the concepts clear in our own minds.
- dhsksndjsb 6y ago
  OOP involves a type hierarchy, which is a prerequisite for giving meaning to the idea of inheritance. You can't talk about classes without actually talking about types, and inheritance creates a type hierarchy. From golang documentation: "Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes). Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java."
  - pjmlp 6y ago
    Nope, it depends pretty much on the OOP language, there are a couple of CS variants to chose from.
- acarl005 6y ago
  Yes, he has conflated generics with inheritance/hierarchies. You can have generics without the mess that is inheritance.
hyperman1 6y ago
A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-assed language. I dumped it, tried rust, and even with its slow compile times I couldn't be happier. Now a few releases later, they fixed sort so I can only implement compare. Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A is source code generation, a clear indication go isn't enough on its own. I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. It was a near miss, though. SOme things are clearly correct. I want to look again when they finally have generics, and some basic collections. I hope that day comes and I can give it a new chance. But until then, less was simply not enough .
- spyspy 6y ago
  The sort library has been massively upgraded since you used it. There are a lot more helpers so you don’t need to reimplement the swap and less functions for each slice type.
- jahaja 6y ago
  > I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it. I really have no idea why some people so often need to use generics, and similar, beyond the built-in map and slice/array, when I seemingly do not, even though I write Go as my full-time job. Sure there a lot of difference between apps/domains, but the bulk of the code is usually not that different.
  - hyperman1 6y ago
kenforthewin 6y ago
Please tag this with the date, 2012. Great but old blog post.
abjKT26nO8 6y ago
Needs "(2012)" in the title.
nobleach 6y ago
While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.
- LandR 6y ago
  I feel the same, we are starting to use Go now and I really don't like it. Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go. And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go. I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.
  - tpaschalis 6y ago
    I think you're right regarding the verbosity, but I personally find this is outweighed by the fact that my code is 2x more likely to run correctly on the first try, and do what I expect it to.
    - goatlover 6y ago
      2x more compared to ... C++, Java, Python/PHP/JS/Ruby, Haskell? Which kind of language is the comparison?
  - eriktate 6y ago
    > And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features. If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.
pot8n 6y ago
Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.
- ggregoire 6y ago
  Isn't Golang as simple as Python while being as powerful* as Java? * I guess many people will disagree for the lack of generics (among other things), but the compiler and static types are powerful tools.
- pjmlp 6y ago
  Go is basically Limbo combined with Oberon-2 method syntax, two very successful programming languages from Bell Labs and ETHZ respectively, hence why Go was such a guaranteed success.
  - AnimalMuppet 6y ago
    First, combining two successful languages in no way guarantees success. (Imagine combining Lisp with C++ syntax.) There are lots of ways to do it where the whole is less than either of the parts. Second, you seem to have a strange definition of "success". Limbo was a success? Well, some people used it, and some software got written in it, and some people used the software. Not much software and not many people, though, in the grand scheme of things. Same with Oberon-2. Even if you consider those two languages to have been successes, Go is a far greater success - it's successful in a way that neither Limbo nor Oberon-2 ever were.
    - pjmlp 6y ago
      Exactly, that is why it was needed to add the Google branding into the mixing potion. Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences. You missed the sarcasm on my comment.
vorpalhex 6y ago
I code in Javascript/Node, and I also code in Go. They're both very useful tools and they're useful in different ways. I find Go to be a good tool when I know what I'm writing and I have clear forms in each step.
FpUser 6y ago
"People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more." I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.
api 6y ago
I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language. I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not). IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.
- wahern 6y ago
  Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They prefer explicit and awkward concurrency constructs, perhaps because until Go, mainstream languages like JavaScript, C#, and Python implemented hacks largely because of implementation constraints, so it's all they know. They say thinks like, "I prefer knowing exactly when I might block". Yet you never hear them bemoan the fact that the OS hides process scheduling and VM paging; they don't complain that they can't hook into this at all, let alone be forced to do it 100% of the time for even the simplest code. They never ask that their language force them to be explicit about how and when a simple function call will setup a new stack frame. All of these things were, decades ago, the equivalent of fibers (or more generically asymmetric stackful coroutines). People were likewise skeptical about those things, but today these innovations--function calls, preemptive scheduling, virtual memory--are ubiquitous and invisible and the notion of doing away with them completely or even as default semantics, for all basic programming, would be inconceivable. What small cost they impose upfront by being the default (and often only) construct is vastly outweighed by their power; they're undeniably the correct way to model the vast majority of computing problems at the level with which they're concerned. I agree, goroutines (or perhaps something a little more generic that doesn't conflate stack reification with scheduling) are absolutely the correct abstraction, and this will be proven in a few decades time. But until then we're stuck with people rationalizing the limitations of async constructs in their favorite languages; constructs primarily chosen because of quirky design constraints, principally C interop and C-based VM implementations that leak the semantics of the C ABI stack.
greendave 6y ago
> What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages, but it'll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer. I really like go, and I daresay it makes many things easy to implement and understand, but I do find the flexibility/lack of sophistication allows one to end up writing what amounts to improved C. Great for smaller projects, but surprisingly difficult to manage as it grows.
DLA 6y ago
I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity. IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go. The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You. The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory. Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects. I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing. So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib. And most of all we get a platform that understands and managed complexity in a favorable way. $0.02. Ok, maybe $0.05 (inflation).
acarl005 6y ago
Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.
- ansible 6y ago
  > I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.
  - tonyedgecombe 6y ago
    Swift is nice but I don't see it making much sense outside of the Apple ecosystem.
    - winrid 6y ago
      It's a wonderful language. I'd love to work with it server side it I found said job.
nshepperd 6y ago
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles! (And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)
- jatone 6y ago
  because generics generally are unncessary. there is a very small subset of programs where they are useful if you have arrays and maps already available. there was no need to rush an implementation of generics.
- autarch 6y ago
  I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy. But that has nothing to do with having an expressive type system and generics. We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.
- cannabis_sam 6y ago
  The explanation is actually simple: «Rob Pike doesn’t know what type theory is or why it is useful» Look at his latest statement on «generics» in Go: https://evrone.com/rob-pike-interview https://evrone.com/rob-pike-interview He acknowledges that parametric polymorphism is a good thing that Go is gonna get, but then repeats his ignorant view on types by conflating type theory with shitty OOP inheritance and class hierarchies.
oftenwrong 6y ago
This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive. For example, in Java one can trivially create a class like `Maybe<T>` with a method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.
MereInterest 6y ago
For any new language that I learn, my go-to thing to try is to implement 4th-order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language. * C++, easily doable with templates. * Python, easily doable with duck typing. * Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input. * Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply() * Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading. Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.
smoorman1024 6y ago
I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary. https://github.com/protocolbuffers/protobuf-go/blob/master/internal/pragma/pragma.go#L29 https://github.com/protocolbuffers/protobuf-go/blob/master/i... Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.
westicecoast32 6y ago
I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project? The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now
dang 6y ago
See also: https://news.ycombinator.com/item?id=16548684 https://news.ycombinator.com/item?id=16548684 (2018) https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319 (2013) Discussed at the time: https://news.ycombinator.com/item?id=4158865 https://news.ycombinator.com/item?id=4158865

67 points by tpaschalis 6y ago

Pike's take is pretty unfair to C++11, given how ideas like 'rvalue references' held up REALLY well. Yes, they were introducing even more complexity to a complex language, but how else are they supposed to incorporate better ways of doing things while maintaining backwards compatibility? I suppose one could always just build a new language that doesn't have the historical cruft, but in this case that's Rust and not Go.

jasode 6y ago

Previous discussion since the HN "past" link doesn't bring up the prior thread because tld was ".de" instead of ".com" : https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319

ses1984 6y ago

>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive. Whoa, hold it there... inheritance and subclassing are OOP, types is a different subject, right?

ChrisSD 6y ago
To be honest programmers have a habit of being very loose with language. Terms like "OOP" and "types" have very context dependent meanings. Given the context, I took him to simply be talking about people coming from "class-based" languages, not anything to do with types in general.
- ses1984 6y ago
  Yeah but it feels almost like a strawman, it feels out of place.
- fernmyth 6y ago
  > To be honest programmers have a habit of being very loose with language. I wish this weren't true. It's quite damning. It's less bad in a real-time conversation, with fast feedback about how well we're being understood. But it still hints that we don't have the concepts clear in our own minds.
dhsksndjsb 6y ago
OOP involves a type hierarchy, which is a prerequisite for giving meaning to the idea of inheritance. You can't talk about classes without actually talking about types, and inheritance creates a type hierarchy. From golang documentation: "Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, even built-in types such as plain, “unboxed” integers. They are not restricted to structs (classes). Also, the lack of a type hierarchy makes “objects” in Go feel much more lightweight than in languages such as C++ or Java."
- pjmlp 6y ago
  Nope, it depends pretty much on the OOP language, there are a couple of CS variants to chose from.
acarl005 6y ago
Yes, he has conflated generics with inheritance/hierarchies. You can have generics without the mess that is inheritance.

hyperman1 6y ago

A few years ago I started to play with go. First impression was great. But a month or so in I started to having more and more doubts. As a Java/C++ programmer I was missing especially the generic collections. Slice and map are a good start, but not enough. Then one day I had to implement the swap operation for sorting. Again. And I thought that even C's qsort was better, and WTF am I wasting my time on this half-assed language. I dumped it, tried rust, and even with its slow compile times I couldn't be happier. Now a few releases later, they fixed sort so I can only implement compare. Sorry, it's not nearly enough. Essential parts are simply missing. Exhibit A is source code generation, a clear indication go isn't enough on its own. I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. It was a near miss, though. SOme things are clearly correct. I want to look again when they finally have generics, and some basic collections. I hope that day comes and I can give it a new chance. But until then, less was simply not enough .

spyspy 6y ago
The sort library has been massively upgraded since you used it. There are a lot more helpers so you don’t need to reimplement the swap and less functions for each slice type.
jahaja 6y ago
> I'm not working with an ecosystem where my human time is less important than the language philosophy. I want to express a repetitive pattern in the language, and then never think about dumb bureaucratics again. Writing code is not where time is spent. Repeating oneself, duplicating code, is fast and easy. Debugging someones code that felt like "expressing" themselves through it however, takes time, and a lot of it. I really have no idea why some people so often need to use generics, and similar, beyond the built-in map and slice/array, when I seemingly do not, even though I write Go as my full-time job. Sure there a lot of difference between apps/domains, but the bulk of the code is usually not that different.
- hyperman1 6y ago

kenforthewin 6y ago

Please tag this with the date, 2012. Great but old blog post.

abjKT26nO8 6y ago

Needs "(2012)" in the title.

nobleach 6y ago

While this philosophy has a lot of value, it just isn't for me. I did a few apps in Go, and fought my way to a decent level of proficiency. I got to a point where I could solve some problems without constantly consulting the docs. But in the end, I wasn't enjoying the experience. The speed was great, the compilation was great. All the selling points were true. But it was missing so many things that I enjoyed using from other languages. (Mostly methods for dealing with collections of data - everything in Go is a for loop). I did another project in Kotlin shortly after and wow, that language has everything AND the kitchen sink! But, I truly enjoyed myself more while working with it. So, this is not me saying Go is "bad". It's actually quite good. It's just not something I enjoy.

LandR 6y ago
I feel the same, we are starting to use Go now and I really don't like it. Things that in other languages I can do in half a dozen lines of code, I find I'm writing 4x time more in go. And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. There's too many missing features I use heavily in other languages that make my life easier that I really miss them in go. I will say I do like that its opinoinated on the formatting. Just takes away an entire tiresome argument.
- tpaschalis 6y ago
  I think you're right regarding the verbosity, but I personally find this is outweighed by the fact that my code is 2x more likely to run correctly on the first try, and do what I expect it to.
  - goatlover 6y ago
    2x more compared to ... C++, Java, Python/PHP/JS/Ruby, Haskell? Which kind of language is the comparison?
- eriktate 6y ago
  > And I find it pretty unreadable, it's not nearly as expressive as other languages I enjoy using. I tend to conflate higher expressiveness with being "clever" until you're really proficient in the language. I think Go's main value prop is that it performs well with very little ramp up time compared to languages with more powerful features. If you have a team of people who are really strong with something like OCaml or Scala, they'll be amazingly productive. But if you have a rotating team of engineers with varying backgrounds, it's hard to beat Go when you're talking about time-to-productivity.

pot8n 6y ago

Golang didn't succeed because it is simple or powerful or any of the, I apologize, nonsense your hear from the Gophers. Golang succeeded because it was the only available relevant option and alternative to the aging Python and Java when the cloud took off in the early 2010s.

ggregoire 6y ago
Isn't Golang as simple as Python while being as powerful* as Java? * I guess many people will disagree for the lack of generics (among other things), but the compiler and static types are powerful tools.
pjmlp 6y ago
Go is basically Limbo combined with Oberon-2 method syntax, two very successful programming languages from Bell Labs and ETHZ respectively, hence why Go was such a guaranteed success.
- AnimalMuppet 6y ago
  First, combining two successful languages in no way guarantees success. (Imagine combining Lisp with C++ syntax.) There are lots of ways to do it where the whole is less than either of the parts. Second, you seem to have a strange definition of "success". Limbo was a success? Well, some people used it, and some software got written in it, and some people used the software. Not much software and not many people, though, in the grand scheme of things. Same with Oberon-2. Even if you consider those two languages to have been successes, Go is a far greater success - it's successful in a way that neither Limbo nor Oberon-2 ever were.
  - pjmlp 6y ago
    Exactly, that is why it was needed to add the Google branding into the mixing potion. Had Go been created at Bell Labs or ETHZ, and it would have shared the same fate as its influences. You missed the sarcasm on my comment.

vorpalhex 6y ago

I code in Javascript/Node, and I also code in Go. They're both very useful tools and they're useful in different ways. I find Go to be a good tool when I know what I'm writing and I have clear forms in each step.

FpUser 6y ago

"People who are excited about C++11's new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more." I find Go too limiting and definitely not offering "so much more". The author is probably right mentioning "big teams". Sure if I have whole shebang of programmers each nibbling at small particular task and appropriate budget it will work. But comparing the amount of work per developer per time I can have with more sophisticated "traditional" languages does not put Go in any good standing in my opinion.

api 6y ago

I love Go for this reason. It minimizes it's own cognitive load, freeing the mind to spend more time thinking about being clever solving the problem rather than being clever with the language. I also adore goroutines and miss them in any other language. They are really fibers and let you do light concurrency without fiddling with async constructions. Async programming is just an ad hoc way of implementing fibers, and it imposes more cognitive load because now you have two different approaches to every problem in the same language (one async, one not). IMHO minimizing language-imposed cognitive load should be a core goal of any programming language. Human brains are finite, and programmers should spend the majority of their mental energy thinking about the problem being solved not the language.

wahern 6y ago
Unfortunately a substantial number of people seem to suffer from a type of concurrency Stockholm syndrome. They prefer explicit and awkward concurrency constructs, perhaps because until Go, mainstream languages like JavaScript, C#, and Python implemented hacks largely because of implementation constraints, so it's all they know. They say thinks like, "I prefer knowing exactly when I might block". Yet you never hear them bemoan the fact that the OS hides process scheduling and VM paging; they don't complain that they can't hook into this at all, let alone be forced to do it 100% of the time for even the simplest code. They never ask that their language force them to be explicit about how and when a simple function call will setup a new stack frame. All of these things were, decades ago, the equivalent of fibers (or more generically asymmetric stackful coroutines). People were likewise skeptical about those things, but today these innovations--function calls, preemptive scheduling, virtual memory--are ubiquitous and invisible and the notion of doing away with them completely or even as default semantics, for all basic programming, would be inconceivable. What small cost they impose upfront by being the default (and often only) construct is vastly outweighed by their power; they're undeniably the correct way to model the vast majority of computing problems at the level with which they're concerned. I agree, goroutines (or perhaps something a little more generic that doesn't conflate stack reification with scheduling) are absolutely the correct abstraction, and this will be proven in a few decades time. But until then we're stuck with people rationalizing the limitations of async constructs in their favorite languages; constructs primarily chosen because of quirky design constraints, principally C interop and C-based VM implementations that leak the semantics of the C ABI stack.

greendave 6y ago

> What you're given is a set of powerful but easy to understand, easy to use building blocks from which you can assemble—compose—a solution to your problem. It might not end up quite as fast or as sophisticated or as ideologically motivated as the solution you'd write in some of those other languages, but it'll almost certainly be easier to write, easier to read, easier to understand, easier to maintain, and maybe safer. I really like go, and I daresay it makes many things easy to implement and understand, but I do find the flexibility/lack of sophistication allows one to end up writing what amounts to improved C. Great for smaller projects, but surprisingly difficult to manage as it grows.

DLA 6y ago

I'm going to jump in and take a hard Pro-Go stance. Based on experience developing for more than 5 year with Go and deploying systems around the world--in-house hosted and cloud. I have immensely enjoyed the "less is exponentially more" philosophy with Go. In Go there is one or a small number of way to do something. Contrast that with C++ where there are any number of ways to do something and at least as many styles of coding. Too much choice results in complexity. IMO the generics debate is overblown. The systems I've build with go tend toward heavy data processing (ETL, correlation, extraction and the like) and service (JSON APIs supporting front-ends; event some front ends with Go Templates). Never once was I like "my life sucks because I don't have generics." Fair and balanced: Processing JSON in Go takes some getting used to, especially when the JSON structure changes. However, there are some good libs to help. It's just a friction point given the typed nature of Go. The operational simplicity of Go cannot be overstated. Go's production of a deployable binary with zero dependencies is a blessing. There's an amazing deploy tool you can use called: cp. Compare that to the library version hell that is C++ (and I'm also a C fan and very experienced dev). No. Thank. You. The cross compilation of Go code works beautifully. Just 2 weeks ago I had to demonstrate a tool to a customer and due to COVID it was virtual. We had problems with MS Teams connecting to our dev platform so literally 15 minutes before the demo I cross-compiled to a Win binary and moved it to the machine hosting the Teams call. Victory. Because of go fmt, all Go code looks the same. That's a massive advantage to read/understand/use OPC (other people's code). Ditto for the automatic documentation generation -- it looks the same and behaves the same across Go projects. I abhor the Java ecosystem for so many reasons I just don't have the energy to go into. It's my opinion, so not up for debate. If Java works for you, by all means have at it. Robust solid technology for sure. Not hating here; just choosing. So, my Go journey has been and continues to be fantastic. It is my preferred platform for pragmatic reasons--the same sort of reasons it was developed by Google in the first place. My team and I can get stuff done quickly. We can scale it. We can leverage all the CPUs on a box running big data processing flows. We can have automatic code-linked documentation and formatted code and can leverage the same from others. We have build in testing. We can make high performance services and servers with ease. We don't have to deal with ridiculous configuration nonsense. We get instant compilations. We get great tool support (vscode + Go for the win). We get a batteries very much included stdlib. And most of all we get a platform that understands and managed complexity in a favorable way. $0.02. Ok, maybe $0.05 (inflation).

acarl005 6y ago

Whenever the topic of generics comes up, especially in Go, things seem to devolve into a ragefest about inheritance and OOP. Why? I don't want the mess of inheritance any more than the next chap. I just want generics for algebraic types—a single definition for a List, Set, Map. I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. Algebraic types alone (without inheritance) make things an order of magnitude more expressive.

ansible 6y ago
> I wish the error-handling looked more like Rust's Result type instead of the double-return idiom. After this and a few other issues I had with Go's design, I just started learning Rust. Though I hear good things about Swift these days, hopefully they will provide full support for all popular platforms in the future.
- tonyedgecombe 6y ago
  Swift is nice but I don't see it making much sense outside of the Apple ecosystem.
  - winrid 6y ago
    It's a wonderful language. I'd love to work with it server side it I found said job.

nshepperd 6y ago

> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. > ...[rant about 'inheritance' and 'subclassing' and 'hierarchies']... > If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition. How do you get all the way through designing a programming language without realizing how incredibly wrong-headed this is? "Inheritance hierarchies are bad", so... you exclude generics (which are compositional, and have nothing to do with inheritance), and only support subtyping polymorphism via 'interfaces' (ie. inheritance)? That is the exact opposite of his claimed principles! (And then as a minor concession to programming usability, he adds generics anyway, but only for built in types (maps and arrays), so advanced data structures are still an exercise in void* wrangling.)

jatone 6y ago
because generics generally are unncessary. there is a very small subset of programs where they are useful if you have arrays and maps already available. there was no need to rush an implementation of generics.
autarch 6y ago
I was thinking exactly the same thing. I don't understand how you segue from generics to "too many types are bad" to "inheritance is bad". I totally agree with the last idea. Inheritance is not a great model for code and it quickly becomes unwieldy. But that has nothing to do with having an expressive type system and generics. We can look at Rust for an example. It's "OO model", such as it is, is fairly similar to Go's. You can define a thing that combines data and behavior. You can define traits/interfaces that objects can implement. You can use those trait/interface types in place of concrete types. But Rust also gives you generics, sum types, and pattern matching. IMO, that makes for much cleaner code than doing the equivalent in Go.
cannabis_sam 6y ago
The explanation is actually simple: «Rob Pike doesn’t know what type theory is or why it is useful» Look at his latest statement on «generics» in Go: https://evrone.com/rob-pike-interview https://evrone.com/rob-pike-interview He acknowledges that parametric polymorphism is a good thing that Go is gonna get, but then repeats his ignorant view on types by conflating type theory with shitty OOP inheritance and class hierarchies.

oftenwrong 6y ago

This does a poor job of justifying the claim that golang is more expressive despite having fewer features than similar languages. I agree to a certain extent that golang's simplicity is an advantage. However, its simplicity does actually make it less expressive. For example, in Java one can trivially create a class like `Maybe<T>` with a method `Maybe<R> map(Function<T, R> mapper)`. This can be used with any classes filling in the parameters. I believe golang is unable to express this.

MereInterest 6y ago

For any new language that I learn, my go-to thing to try is to implement 4th-order Runge-Kutta solving of an ODE. This implementation must be usable for both built-in types and user-defined types, and must have reasonable performance for the language. * C++, easily doable with templates. * Python, easily doable with duck typing. * Rust, doable, though with some restrictions. I needed to require the derivative function to return the same type as its input, rather than returning something that can be scalar multiplied and added to the same type as the input. * Java, not possible. Adding/multiplying of built-in types can be done with + and * , but user-defined types require .add() and .multiply() * Go, not possible. Go doesn't support generics, and I'm certainly not going to copy/paste a numeric method once for every system that I examine. Also, same issue as Java with no operator overloading. Complexity has to go somewhere. By aiming for a simple language, Go forces the complexity to be in the developer side instead.

smoorman1024 6y ago

I've been working in golang professionally for about a year now coming from a long career in C++. Although there is some simplicity to golang that can be appreciated things like this below make me think that the premise of less is more is fundamentally incorrect if you cannot accomplish everything that is necessary. https://github.com/protocolbuffers/protobuf-go/blob/master/internal/pragma/pragma.go#L29 https://github.com/protocolbuffers/protobuf-go/blob/master/i... Specifically the last one of embedding an empty array of mutexes into a struct prevents that struct from being copied. This is something that is easily and explicitly accomplished in C++ by making the constructors private.

westicecoast32 6y ago

I'm writing a language. I was wondering what you all suggest it have before you would seriously try it out? I don't think most people cares about syntax; does it need to be attached to a large project? The beta of the last language I wrote had maybe half a dozen fans. I threw away the compiler/language because I didn't really know how to write a compiler back then. I'm writing a new one now

dang 6y ago

See also: https://news.ycombinator.com/item?id=16548684 https://news.ycombinator.com/item?id=16548684 (2018) https://news.ycombinator.com/item?id=6417319 https://news.ycombinator.com/item?id=6417319 (2013) Discussed at the time: https://news.ycombinator.com/item?id=4158865 https://news.ycombinator.com/item?id=4158865