3 ms·

I'm not surprised that the official Go survey showed: "..Go is the top language they'd prefer to use..." It doesn't really say much given the selection bias.

by leshow 8y ago

DC-3 8y ago
Wow, congratulations for spotting that bias. Really slaying monsters with that sort of statistical insight. Why can't you look for the value in the article instead of picking stupid holes in it?
- cdelsolar 8y ago
  Who micturated upon your toasted maize flakes?
ntnn 8y ago
The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting. Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.
- zzzcpan 8y ago
  > Go team knows that they aren't covering the needs of This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
- mynegation 8y ago
  As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and limited set of entities.
  - chessturk 8y ago
    Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?
    - mynegation 8y ago
      > What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
      - imetatroll 8y ago
        You can define methods on structs which is not unlike classes. You can define an interface with methods that allow objects to be processed in a more generic fashion. I think that more than anything it would require a change of mindset that people understandably don't want to deal with.
zzzcpan 8y ago
The point is to very roughly quantify that selection bias, no? Obviously, if Go neglects certain areas or doesn't fit well enough, people who consider those areas important don't use Go and are not represented in the survey.
politician 8y ago
Asking what languages people use at work or when not at work is an obvious place to start this sort of survey, it should be no surprise that Go is ranked highly among people who found it on the Go website, and it didn't surprise the authors of the survey either who pointed it out and quickly moved on to more meaningful statistics.

I'm not surprised that the official Go survey showed: "..Go is the top language they'd prefer to use..." It doesn't really say much given the selection bias.

by leshow 8y ago

I'm not surprised that the official Go survey showed: "..Go is the top language they'd prefer to use..." It doesn't really say much given the selection bias.

DC-3 8y ago

Wow, congratulations for spotting that bias. Really slaying monsters with that sort of statistical insight. Why can't you look for the value in the article instead of picking stupid holes in it?

cdelsolar 8y ago
Who micturated upon your toasted maize flakes?

ntnn 8y ago

The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting. Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.

zzzcpan 8y ago
> Go team knows that they aren't covering the needs of This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
mynegation 8y ago
As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and limited set of entities.
- chessturk 8y ago
  Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?
  - mynegation 8y ago
    > What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
    - imetatroll 8y ago
      You can define methods on structs which is not unlike classes. You can define an interface with methods that allow objects to be processed in a more generic fashion. I think that more than anything it would require a change of mindset that people understandably don't want to deal with.

zzzcpan 8y ago

The point is to very roughly quantify that selection bias, no? Obviously, if Go neglects certain areas or doesn't fit well enough, people who consider those areas important don't use Go and are not represented in the survey.

politician 8y ago

Asking what languages people use at work or when not at work is an obvious place to start this sort of survey, it should be no surprise that Go is ranked highly among people who found it on the Go website, and it didn't surprise the authors of the survey either who pointed it out and quickly moved on to more meaningful statistics.