5 ms·

1-7 of these features exist in C#, and in C# you get a real type system. C# isn't even my favorite language that has all these features, just the most mainstrea

1-7 of these features exist in C#, and in C# you get a real type system. C# isn't even my favorite language that has all these features, just the most mainstream. 8-10 are of dubious usefulness. It seems they break the principle of least astonishment[1], but maybe they're idiomatic in Go. So yeah, still waiting to see any reason to think Go's popularity is anything more than hype and fanboyism. [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

segmondy 7y ago
The article never said, 10 things unique to go. So what's your point?
- kerkeslager 7y ago
  I never said the article said that. So what's your point? I'm not criticizing the presentation, I'm criticizing Go.
Spivak 7y ago
Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right. C# has all these features because C# has every single feature and facility that every programming language has ever had thrown into a single ungodly soup of keywords and syntax. Don’t get me wrong, this means C# is bloody powerful but once you involve more than one dev you get into the problems of every dev understanding and/or preferring their subset of C#. Every PR is 50% policing style and structure desperately trying to keep the codebase grokable by everyone and politics about everyone’s favorite pet feature and design pattern. C# rewards cleverness with incredibly slick looking but utterly incomprehensible code unless you wrote it two minutes ago. Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task.
- dotancohen 7y ago
  I never thought that C# would become Perl.
- kerkeslager 7y ago
  > Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right. As a face-value claim, that's obviously untrue. Forth, by any reasonable metric, is a smaller language than Go, but I think you'd have a hard time claiming it's more productive. I'll generously assume that you mean that "languages with a carefully selected set of features are more productive", and there I'd agree with you. That's Python's "There should be one-- and preferably only one --obvious way to do it." But then the question becomes, "Which features?" A very key choice you have to make up-front is the type system, and it's obvious that Go's type-system choices are bad[1]. Weak static types[2] gives them the worst of both worlds: the types don't get out of your way like a dynamic type system and they don't catch errors like a strong/flexible type system. Single-pass compilation for speed is the only attempt at a justification for this choice, but it's a bad justification: 1) this is solved by partial recompilation for all but the largest use cases[1], and 2) if you're using `go generate` to solve the obvious problems with the type system, you're introducing a second pass that saves keystrokes in exchange for giving up even more type safety. So you add a linter: congratulations, now your single-pass compilation is three passes. This isn't a tradeoff, it's just giving away all benefits of types in exchange for a veneer of minimalist aesthetic. I'm not going to quote what you said on C#--I'll only respond by saying that if you read my post, you'll see I said it's not my favorite language. I'm not espousing it. > Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task. ...which is extremely short-sighted. The "only one right way to do it" only lasts as long as there's no NPM-like ecosystem of libraries. Look at Python: most projects pull in at least a few common dependencies, and there's immense pressure on Python to integrate these back into the language--a pressure to which they have succumbed in many cases (which isn't necessarily a bad thing). Most projects also pull in some section of really, really bad dependencies that should never have been released into the wild and probably never will be updated. There's no way around subsetting: at least if you use the wrong language features, they'll be supported and deprecated responsibly, unlike the average 0.0.2-versioned 5 line function imported from NPM or PyPy[3]. Ideally you have a set of core features and a strong standard library that don't push people to import a bunch of terrible libraries, which is why Python has fared so well despite some really awful limitations (i.e. the GIL). But again, Go isn't that. [1] They're probably not bad for Google: the people who made Go made it to solve Google's problems, and they're smart guys. But you are not Google (unless you are Google), and if you're operating at Google's scale, you can make your own programming language that solves your problems rather than Google's. [2] Go fanboys generally don't know that weak/strong and static/dynamic aren't the same thing, and like to claim that Go has a strong type system because it has a static type system. This reinforces my belief that people choose Go because they don't understand type systems. [3] NIH isn't even enforceable: good luck preventing people on your team from "importing" code from Stack Overflow using their keyboard's copy/paste function.
slx26 7y ago
well, this is probably not a good link in order to find why people like Go. But in general: - it's a simple language. pretty much as easy to use as languages like python or ruby. - decent performance (not the best, but pretty good for most use-cases (low-latency GC included)) - concurrency made simple (and the supported concurrency model is suitable for most use-cases) - typed (not the best, most expressive type system, but pretty good for most use-cases) - backed by a big company, mature enough for most use-cases so, it strikes a good balance between being painless and being useful.
- michaelcampbell 7y ago
  Not criticising, but I find it amusing that 2 things that people seem to point out about go; backed by a big company, and simple, are the same 2 things so many shit on Java for, for years. You didn't, but reading your post made me think of it.
  - slx26 7y ago
    well, reflecting about it now I'm not so sure that the "big company" argument is that positive. when a language is just starting, having resources is extremely helpful, but in the long run it's indeed possible that the company becomes a liability to the community. about simplicity, while I wouldn't say Java is a complex language, and I might even agree that the language itself is easy, it's also quite verbose, and it doesn't feel as light to use as golang. I would personally mention two things (besides the verbosity of Java): 1) the OOP in Java kinda leads me to start designing around classes, and I feel I need a solid design/plan right from the start, while in golang I feel a bit more like I'm working with a scripting language, but the interfaces and the way the language works makes it quite easy to refactor code and move things as I need it, and in practice I end up with good organization and modular code precisely because it's very easy to move things around. just that frame of mind is a big change (though this is extremely subjective). 2) when I write Java I feel like I need an IDE. yeah, again partly because of the verbosity and boilerplate, but I also feel the environment is more complex. with golang I just write a "package main; func main() { some code }" and then run "go run myprogram.go". that makes the language feel really light and easy to use. I'm not afraid to try to write a demo program and run it even with my eyes closed. with Java I don't feel so much in direct control, and I regularly end up confused about random configurations and things. I don't try to argue that Java is significantly more complex as a language (the typical programming environment is quite different), but it still feels much heavier and complicated than golang. well, I'll stop here or I'll end up sounding like a fanboy (I wasn't a big fan of many of the golang design choices at the start)
duxup 7y ago
A lot of features exist in a lot of languages. I'm not sure the fact that they do that is inherently meaningful in any way, pro, con, or whatever.

segmondy 7y ago

The article never said, 10 things unique to go. So what's your point?

kerkeslager 7y ago
I never said the article said that. So what's your point? I'm not criticizing the presentation, I'm criticizing Go.

Spivak 7y ago

Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right. C# has all these features because C# has every single feature and facility that every programming language has ever had thrown into a single ungodly soup of keywords and syntax. Don’t get me wrong, this means C# is bloody powerful but once you involve more than one dev you get into the problems of every dev understanding and/or preferring their subset of C#. Every PR is 50% policing style and structure desperately trying to keep the codebase grokable by everyone and politics about everyone’s favorite pet feature and design pattern. C# rewards cleverness with incredibly slick looking but utterly incomprehensible code unless you wrote it two minutes ago. Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task.

dotancohen 7y ago
I never thought that C# would become Perl.
kerkeslager 7y ago
> Because Go is taking a strong stance that smaller languages are more productive, and I think they’re right. As a face-value claim, that's obviously untrue. Forth, by any reasonable metric, is a smaller language than Go, but I think you'd have a hard time claiming it's more productive. I'll generously assume that you mean that "languages with a carefully selected set of features are more productive", and there I'd agree with you. That's Python's "There should be one-- and preferably only one --obvious way to do it." But then the question becomes, "Which features?" A very key choice you have to make up-front is the type system, and it's obvious that Go's type-system choices are bad[1]. Weak static types[2] gives them the worst of both worlds: the types don't get out of your way like a dynamic type system and they don't catch errors like a strong/flexible type system. Single-pass compilation for speed is the only attempt at a justification for this choice, but it's a bad justification: 1) this is solved by partial recompilation for all but the largest use cases[1], and 2) if you're using `go generate` to solve the obvious problems with the type system, you're introducing a second pass that saves keystrokes in exchange for giving up even more type safety. So you add a linter: congratulations, now your single-pass compilation is three passes. This isn't a tradeoff, it's just giving away all benefits of types in exchange for a veneer of minimalist aesthetic. I'm not going to quote what you said on C#--I'll only respond by saying that if you read my post, you'll see I said it's not my favorite language. I'm not espousing it. > Not saying Go is the answer or the way but I think it’s scratching a lot of people’s itches for something high level that’s restrictive enough that there’s only one or two “right” ways to accomplish a given task. ...which is extremely short-sighted. The "only one right way to do it" only lasts as long as there's no NPM-like ecosystem of libraries. Look at Python: most projects pull in at least a few common dependencies, and there's immense pressure on Python to integrate these back into the language--a pressure to which they have succumbed in many cases (which isn't necessarily a bad thing). Most projects also pull in some section of really, really bad dependencies that should never have been released into the wild and probably never will be updated. There's no way around subsetting: at least if you use the wrong language features, they'll be supported and deprecated responsibly, unlike the average 0.0.2-versioned 5 line function imported from NPM or PyPy[3]. Ideally you have a set of core features and a strong standard library that don't push people to import a bunch of terrible libraries, which is why Python has fared so well despite some really awful limitations (i.e. the GIL). But again, Go isn't that. [1] They're probably not bad for Google: the people who made Go made it to solve Google's problems, and they're smart guys. But you are not Google (unless you are Google), and if you're operating at Google's scale, you can make your own programming language that solves your problems rather than Google's. [2] Go fanboys generally don't know that weak/strong and static/dynamic aren't the same thing, and like to claim that Go has a strong type system because it has a static type system. This reinforces my belief that people choose Go because they don't understand type systems. [3] NIH isn't even enforceable: good luck preventing people on your team from "importing" code from Stack Overflow using their keyboard's copy/paste function.

slx26 7y ago

well, this is probably not a good link in order to find why people like Go. But in general: - it's a simple language. pretty much as easy to use as languages like python or ruby. - decent performance (not the best, but pretty good for most use-cases (low-latency GC included)) - concurrency made simple (and the supported concurrency model is suitable for most use-cases) - typed (not the best, most expressive type system, but pretty good for most use-cases) - backed by a big company, mature enough for most use-cases so, it strikes a good balance between being painless and being useful.

michaelcampbell 7y ago
Not criticising, but I find it amusing that 2 things that people seem to point out about go; backed by a big company, and simple, are the same 2 things so many shit on Java for, for years. You didn't, but reading your post made me think of it.
- slx26 7y ago
  well, reflecting about it now I'm not so sure that the "big company" argument is that positive. when a language is just starting, having resources is extremely helpful, but in the long run it's indeed possible that the company becomes a liability to the community. about simplicity, while I wouldn't say Java is a complex language, and I might even agree that the language itself is easy, it's also quite verbose, and it doesn't feel as light to use as golang. I would personally mention two things (besides the verbosity of Java): 1) the OOP in Java kinda leads me to start designing around classes, and I feel I need a solid design/plan right from the start, while in golang I feel a bit more like I'm working with a scripting language, but the interfaces and the way the language works makes it quite easy to refactor code and move things as I need it, and in practice I end up with good organization and modular code precisely because it's very easy to move things around. just that frame of mind is a big change (though this is extremely subjective). 2) when I write Java I feel like I need an IDE. yeah, again partly because of the verbosity and boilerplate, but I also feel the environment is more complex. with golang I just write a "package main; func main() { some code }" and then run "go run myprogram.go". that makes the language feel really light and easy to use. I'm not afraid to try to write a demo program and run it even with my eyes closed. with Java I don't feel so much in direct control, and I regularly end up confused about random configurations and things. I don't try to argue that Java is significantly more complex as a language (the typical programming environment is quite different), but it still feels much heavier and complicated than golang. well, I'll stop here or I'll end up sounding like a fanboy (I wasn't a big fan of many of the golang design choices at the start)

duxup 7y ago

A lot of features exist in a lot of languages. I'm not sure the fact that they do that is inherently meaningful in any way, pro, con, or whatever.