4 ms·

I have written a lot of Go (hundreds of thousands of LOC), and appreciate Go's approach to both of these. I disagree that these are major issues. A bigger iss

by cle 7y ago

I have written a lot of Go (hundreds of thousands of LOC), and appreciate Go's approach to both of these. I disagree that these are major issues. A bigger issue, IMO, is that people coming to Go from other languages expect it to have similar features to what they're used to. Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages.

whateveracct 7y ago
Go necessitates so much handrolling. Loops, concurrency patterns, resource management. You can't abstract over much, so you end up doing these things by hand constantly. Therefore you rely on brainpower, ad hoc linters (if one exists), and tests to not blow things up. Go has its benefits and reasons to use it (especially the network effects around it). But when it comes to the three things I mention, Go is truly pathetic compared to a language like Haskell. It's amazing how much effort is wasted on those activities. I can see why a corporation would not care, but as an engineer I can do better with my time and effort for my personally-owned endeavors.
- cle 7y ago
  As an individual, many of Go's benefits aren't as useful. It's optimized for team settings, emphasizing consistency, readability, explictness, and low cognitive overhead, which are all major weaknesses of Haskell, and major reasons it's not widely used in industry.
  - whateveracct 7y ago
    For many applications, Go has higher cognitive overhead than Haskell. Modulo learning Haskell of course, but still. Go is made to treat people as Resources. Full stop. That explains everything about it's benefits.
- deleted 7y ago
  [deleted]
RandyRanderson 7y ago
"I have written a lot of Go (hundreds of thousands of LOC)..." Go only appeared about 10 years ago. The industry standard is 50 lines of production code a day. 50/day * 250 working days a year = 12.5k loc/year. So it would take you how many continuous years to write 200k LOC?
- dewey 7y ago
  There's probably a very big difference between "industry standard" and working with a new language at a startup where a lot of things are written from scratch in a short amount of time. 50 lines of code on average for a year won't get you very far if you work on greenfield project. The industry standard is probably very heavily biased by big corporate code bases where refactoring / architecture takes a lot more time than implementing the actual changes afterwards. Doesn't seem like a very useful calculation you are trying to do there to proof the previous poster wrong.
  - RandyRanderson 7y ago
    "There's probably a very big difference between" - that is precisely my point. I have a lot of time playing ms flight sim and so obviously I know how to design airplanes is his argument. Writing "greenfield" applications that no one (comparatively) is using is relatively easy. Creating systems that have four+ 9's availability, integrate with various disparate APIs, don't lose data, and,and etc is where, IMO, the learning is. Once one has this experience, watching this micro services "movement" is, in my mind, related to global warming - like watching someone jump out of a plane with no parachute, smiling.
flavio81 7y ago
>Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages. No, they aren't. They are the same as languages from 40 years ago: We have had channels, coroutines, and good garbage collectors from long, long ago. Plus the syntax is directly borrowed from Algol 68 (from 1968). Go looks nice because it fills a niche (a high performance garbage collected language that is easier to learn than Java and provides faster compilation times than C++), but there's absolutely nothing different here. For "pretty different from mainstream" see Forth, Prolog, Erlang, etc.

by cle 7y ago

whateveracct 7y ago

Go necessitates so much handrolling. Loops, concurrency patterns, resource management. You can't abstract over much, so you end up doing these things by hand constantly. Therefore you rely on brainpower, ad hoc linters (if one exists), and tests to not blow things up. Go has its benefits and reasons to use it (especially the network effects around it). But when it comes to the three things I mention, Go is truly pathetic compared to a language like Haskell. It's amazing how much effort is wasted on those activities. I can see why a corporation would not care, but as an engineer I can do better with my time and effort for my personally-owned endeavors.

cle 7y ago
As an individual, many of Go's benefits aren't as useful. It's optimized for team settings, emphasizing consistency, readability, explictness, and low cognitive overhead, which are all major weaknesses of Haskell, and major reasons it's not widely used in industry.
- whateveracct 7y ago
  For many applications, Go has higher cognitive overhead than Haskell. Modulo learning Haskell of course, but still. Go is made to treat people as Resources. Full stop. That explains everything about it's benefits.
deleted 7y ago
[deleted]

RandyRanderson 7y ago

"I have written a lot of Go (hundreds of thousands of LOC)..." Go only appeared about 10 years ago. The industry standard is 50 lines of production code a day. 50/day * 250 working days a year = 12.5k loc/year. So it would take you how many continuous years to write 200k LOC?

dewey 7y ago
There's probably a very big difference between "industry standard" and working with a new language at a startup where a lot of things are written from scratch in a short amount of time. 50 lines of code on average for a year won't get you very far if you work on greenfield project. The industry standard is probably very heavily biased by big corporate code bases where refactoring / architecture takes a lot more time than implementing the actual changes afterwards. Doesn't seem like a very useful calculation you are trying to do there to proof the previous poster wrong.
- RandyRanderson 7y ago
  "There's probably a very big difference between" - that is precisely my point. I have a lot of time playing ms flight sim and so obviously I know how to design airplanes is his argument. Writing "greenfield" applications that no one (comparatively) is using is relatively easy. Creating systems that have four+ 9's availability, integrate with various disparate APIs, don't lose data, and,and etc is where, IMO, the learning is. Once one has this experience, watching this micro services "movement" is, in my mind, related to global warming - like watching someone jump out of a plane with no parachute, smiling.

flavio81 7y ago

>Go is small and conceptually simple, but its ideas and philosophy are pretty different from most mainstream languages. No, they aren't. They are the same as languages from 40 years ago: We have had channels, coroutines, and good garbage collectors from long, long ago. Plus the syntax is directly borrowed from Algol 68 (from 1968). Go looks nice because it fills a niche (a high performance garbage collected language that is easier to learn than Java and provides faster compilation times than C++), but there's absolutely nothing different here. For "pretty different from mainstream" see Forth, Prolog, Erlang, etc.