4 ms·

>because of the freedom you get from more similar languages. Is this lack of freedom a good thing?

ashark 9y ago
The size of the language and the (more or less) one-way-to-do-things style mean that reading someone else’s go—say, from a library you’re depending on—is really easy. The chance you’ll run into language features you aren’t familiar with (which can happen even to long-time writers of some larger languages) or one of several competing and possibly now-deprecated 3rd party bolted-on features making up for painful deficiencies in the base language (ahem, JavaScript) or some nutty flow-obscuring “helpful” nonsense is low.
cloverich 9y ago
I can see it being a good thing in many organizations. I've worked in organizations with very sharp people who did not care to limit one another, allowing a smorgasbord of languages, frameworks, idioms, etc. Watching them smartly tackle the wide variety of idiosyncrasies that came with each language and framework was frustrating because, while they solved a great many problems, delivering robust working software was not one of them. I don't think everyone would have that problem. But I'd wager a great many would (do).
catnaroek 9y ago
Naturality (i.e., the absence of either artificial constraints or artificial degrees of freedom) is a good thing.
aomix 9y ago
Unless there is a strong mandate from the top to take time for maintaining and reviewing code I'd say absolutely. Even if those were in place I'd say a strong maybe. Ignoring competency some people just have wildly divergent ways to doing the same thing because of their background. Languages like Java and C++ allow for it because they allow you to do so much. So I agree with the basic tenant of Go that having one way to solve a problem is a huge win for code maintainability and readability. If the one way is clunky and kind of ugly I'm still down for it.

The size of the language and the (more or less) one-way-to-do-things style mean that reading someone else’s go—say, from a library you’re depending on—is really easy. The chance you’ll run into language features you aren’t familiar with (which can happen even to long-time writers of some larger languages) or one of several competing and possibly now-deprecated 3rd party bolted-on features making up for painful deficiencies in the base language (ahem, JavaScript) or some nutty flow-obscuring “helpful” nonsense is low.

cloverich 9y ago

I can see it being a good thing in many organizations. I've worked in organizations with very sharp people who did not care to limit one another, allowing a smorgasbord of languages, frameworks, idioms, etc. Watching them smartly tackle the wide variety of idiosyncrasies that came with each language and framework was frustrating because, while they solved a great many problems, delivering robust working software was not one of them. I don't think everyone would have that problem. But I'd wager a great many would (do).

catnaroek 9y ago

Naturality (i.e., the absence of either artificial constraints or artificial degrees of freedom) is a good thing.

aomix 9y ago

Unless there is a strong mandate from the top to take time for maintaining and reviewing code I'd say absolutely. Even if those were in place I'd say a strong maybe. Ignoring competency some people just have wildly divergent ways to doing the same thing because of their background. Languages like Java and C++ allow for it because they allow you to do so much. So I agree with the basic tenant of Go that having one way to solve a problem is a huge win for code maintainability and readability. If the one way is clunky and kind of ugly I'm still down for it.