4 ms·

I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be bea

by aomix 9y ago

I appreciate the ruthless design choices behind Go. Crafting a language so there are as few ways as possible, and preferably one, to solve a problem must be beautiful at a large scale organization. In my experience java codebases in big companies are nightmare factories because of the freedom you get from more similar languages. The Go dream of having a single decent solution to a problem instead of 20 that range from bizarre to really clever sounds like heaven. I wish I had more time to take a serious stab at learning it.

deleted 9y ago
[deleted]
flavio81 9y ago
>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.
peoplewindow 9y ago
I think you've misdiagnosed things here. Large Java codebases in giant companies are often very poor because: 1. Giant non-software companies often have low hiring bars for their software teams. 2. They are full of bored programmers working on boring software, these people then find ways to make their lives more interesting and kill the time by over-engineering things. 3. These codebases are often very large, old, and have suffered many requirements changes with little or no time allocated to clearing technical debt. There's nothing in Go that'd make any of these things better. It may superficially appear this way because Go is, in the grand scheme of things, still quite new and hardly used in the enterprise (because it doesn't solve anything better than Java), and as such there aren't any large enterprise codebases written in it. But if you compare the language features, it's hard to explain what would make Go result in better quality software than Java and easy to find things that'd make it worse.

by aomix 9y ago

deleted 9y ago

[deleted]

flavio81 9y ago

>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.

peoplewindow 9y ago

I think you've misdiagnosed things here. Large Java codebases in giant companies are often very poor because: 1. Giant non-software companies often have low hiring bars for their software teams. 2. They are full of bored programmers working on boring software, these people then find ways to make their lives more interesting and kill the time by over-engineering things. 3. These codebases are often very large, old, and have suffered many requirements changes with little or no time allocated to clearing technical debt. There's nothing in Go that'd make any of these things better. It may superficially appear this way because Go is, in the grand scheme of things, still quite new and hardly used in the enterprise (because it doesn't solve anything better than Java), and as such there aren't any large enterprise codebases written in it. But if you compare the language features, it's hard to explain what would make Go result in better quality software than Java and easy to find things that'd make it worse.