4 ms·

From what I can tell by reading what Go developers write, they like it precisely because it's not something to get excited over. It seems like the kind of lang

by dx87 7y ago

From what I can tell by reading what Go developers write, they like it precisely because it's not something to get excited over. It seems like the kind of language where once you learn it, you don't have to keep up with a bunch of blog posts detailing all the cool new things being added to it, and decisions over stuff like formatting are made for you. I primarily use Rust for hobby projects, and the steady stream of new features/libraries can get tiring. You don't have to use the new stuff in your own code, but if you want to use popular libraries, you'll probably be stuck using the new features. Making everything async seems to be the new hotness, and sometimes I wish the language would be nothing to get excited over.

stoicShell 7y ago
100% agreed, and you made me realize something. As someone who writes — I mean prose, whether fiction or not (mostly not: essays, technical, etc) — I had to come to terms quite early with the dichotomy you explain here. There is a place for the "beautiful language", the parts of it and the ways of using it that make it a pleasure, as a writer and as a reader. This, unsurprisingly, usually demands a whole lot of additional work on top of the 'direct meaning'. Then there's a place, in casual communication, in business, in marketing, in essays as well, in technical docs, in speeches, in a lot of places, for the 'direct meaning', or close to that. The efficient use of language, when all form recedes in favor of meaning, of concepts, of getting that 'other' to get what you mean. It's just that, in human language, you do it all with the same tools, we use formal or topical subsets of a vastly larger ensemble. In programming, we're more likely to use different languages [themselves subsets of human language if you think about it, but let's forget that for the sake of simplicity]. And there are programmers among us who love to dabble in the form, like some writers would spend 10%, twice, ten times the effort crafting just "better form" over an already well-defined idea/story. While other programmers, or at other times, just focus on getting things done. Cue the spectrum in-between. So it all depends what we put in our code, as programmers, as human beings I guess. Is that thing a personal statement? Or is it just garbage code to temporarily expedite some roadblock? How do we approach complexity, bottom-up from the simplest elements/code, or top-down with the most expressive almost-meta entities? Maybe some side-line out-of-the-box angle? See how we'd word all of these, in human languages, as in code. We just wouldn't say the same, nor code (select languages) the same. I don't know if I explained it well. But looking at it from a human language writer, it all seems clear now. The whole rat race of languages, the churches, the sheer effort put into form when meaning has already been solved 10 times by others, the strong NIH syndromes... it's all so common in traditional writers circles. We're all just writers, really!
SomaticPirate 7y ago
It also lends itself to patterns in code. One thing that learned about Python coming from Perl was there was a “Pythonic” solution. Go seems to take that idea further with gofmt and a small but powerful std lib. I can typically glance at how someone is configuring their http.Server and understand the intention of the code.
- idoubtit 7y ago
  The "pythonic" way was a mantra that has been obsolete for a long time. With Python, there are many (unsatisfying) ways to declare dependencies, many ways to format code (I hope "black" will prevail), many ways to format a string, many ways to create a struct/record... The lack of quality batteries included also leads to "there is more than one way to do it" through the choice of unofficial libraries. My experience is that the extensive standard library of Go brings more normalisation.
catalogia 7y ago
I think there can exist a happy middleground between constant churn and what Go currently provides. Some nice quality of life features like pattern matching and list comprehensions would go a long way towards making it a more pleasant language, without making developers feel like they're in a constant struggle to stay current.

by dx87 7y ago

stoicShell 7y ago

100% agreed, and you made me realize something. As someone who writes — I mean prose, whether fiction or not (mostly not: essays, technical, etc) — I had to come to terms quite early with the dichotomy you explain here. There is a place for the "beautiful language", the parts of it and the ways of using it that make it a pleasure, as a writer and as a reader. This, unsurprisingly, usually demands a whole lot of additional work on top of the 'direct meaning'. Then there's a place, in casual communication, in business, in marketing, in essays as well, in technical docs, in speeches, in a lot of places, for the 'direct meaning', or close to that. The efficient use of language, when all form recedes in favor of meaning, of concepts, of getting that 'other' to get what you mean. It's just that, in human language, you do it all with the same tools, we use formal or topical subsets of a vastly larger ensemble. In programming, we're more likely to use different languages [themselves subsets of human language if you think about it, but let's forget that for the sake of simplicity]. And there are programmers among us who love to dabble in the form, like some writers would spend 10%, twice, ten times the effort crafting just "better form" over an already well-defined idea/story. While other programmers, or at other times, just focus on getting things done. Cue the spectrum in-between. So it all depends what we put in our code, as programmers, as human beings I guess. Is that thing a personal statement? Or is it just garbage code to temporarily expedite some roadblock? How do we approach complexity, bottom-up from the simplest elements/code, or top-down with the most expressive almost-meta entities? Maybe some side-line out-of-the-box angle? See how we'd word all of these, in human languages, as in code. We just wouldn't say the same, nor code (select languages) the same. I don't know if I explained it well. But looking at it from a human language writer, it all seems clear now. The whole rat race of languages, the churches, the sheer effort put into form when meaning has already been solved 10 times by others, the strong NIH syndromes... it's all so common in traditional writers circles. We're all just writers, really!

SomaticPirate 7y ago

It also lends itself to patterns in code. One thing that learned about Python coming from Perl was there was a “Pythonic” solution. Go seems to take that idea further with gofmt and a small but powerful std lib. I can typically glance at how someone is configuring their http.Server and understand the intention of the code.

idoubtit 7y ago
The "pythonic" way was a mantra that has been obsolete for a long time. With Python, there are many (unsatisfying) ways to declare dependencies, many ways to format code (I hope "black" will prevail), many ways to format a string, many ways to create a struct/record... The lack of quality batteries included also leads to "there is more than one way to do it" through the choice of unofficial libraries. My experience is that the extensive standard library of Go brings more normalisation.

catalogia 7y ago

I think there can exist a happy middleground between constant churn and what Go currently provides. Some nice quality of life features like pattern matching and list comprehensions would go a long way towards making it a more pleasant language, without making developers feel like they're in a constant struggle to stay current.