13 ms·

I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. That's the problem

by zer8k 3y ago

I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. That's the problem with Go in general I think. Much like my experience with Ruby on Rails it seems like once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. Great for bottom-tier devs and unmotivated people working on corporate TPS reports. Bad for the motivated engineer. Opportunities like this (to introduce a new idea into the go concurrency ecosystem) are basically impossible.

Philip-J-Fry 3y ago
>I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. What's the issue with making Go good for the lowest common denominator developer? This is fantastic for businesses as they can get new developers productive within a few days. It's great for the ecosystem because the barrier of entry is low. Just because it's made simple and easy to pick up doesn't mean you can't write complex software with it. It's a programming language, you can write whatever you want with it. If it makes writing complex software easier, then that's a good thing. The only reason why someone would think that's not a good thing is their ego because $FAVOURITE_LANGUAGE has 10x as many language features and 10x as many ways to do the exact same thing. What is this walled garden you think exists that prevents motivated engineers from doing good work? I like to think of myself as motivated and Go is the reason for that. It made writing complicated concurrent software so much easier for me, and it made reasoning about them so much easier. I do not understand this criticism of Go.
- didntcheck 3y ago
  I can't help but feel that the reason why new developers reach parity with existing ones so quickly is not due to the productivity of Go, but because the productivity ceiling has been intentionally lowered so that everyone is equally constrained. Having to keep reading reinvented wheels because the language is intentionally poorly expressive is a burden on getting work done. There maybe is only one way to do a thing, and everyone has to keep doing it, rather than being able to write it once and build an abstraction Compare say Java 5 code written with raw servlets implementations and JDBC calls versus modern Spring code. The implementation of the former is easier to understand because everything is very explicit, but the intent of the latter is far easier to understand, since the boilerplate is mostly gone, allowing the actual business logic (what you care about 90% of the time) to be obvious. And you can of course see the implementation if you need to
  - erik_seaberg 3y ago
    Every time I hear “our experts’ code can look like our beginners’ code” I cringe, because experts’ time is much more valuable and they should be communicating concisely. A beginner’s job is to become an expert.
throwaway894345 3y ago
I don’t think this is a bad thing. Most developers think of themselves as more advanced than they are and end up making a mess trying to do abstraction beyond both their ability to do it well and beyond what the problem requires. And even the truly advanced developers very often prefer simpler tooling because it allows them to concentrate their resources on the complexities of the problem and not those of the tool. Further, the idea that Go is somehow bad for motivated engineers doesn’t match my experience and it doesn’t explain the proliferation of interesting tools and services (much of the container / devops ecosystem). I think your mistake is assuming that the only kind of motivation/creativity/etc involves tinkering with language runtimes and that someone who is building original things like Docker, Terraform, or Kubernetes must be “unmotivated”.
jdndxkcofn 3y ago
Hot-take from a bottom-tier dev that thinks running off and creating a bunch of bullshit nobody else can support is a good idea^tm.
- zer8k 3y ago
  I wouldn't call myself a bottom tier dev. I've done plenty of Go programming in a corporate-ish environment. It's restrictive, which is nice, because the ceiling for expert is basically on the floor. It's the Ruby on Rails of programming languages. A perfect walled garden, lead by a benevolent dictator (Google), who will guide us all to the promised land. Would I recommend Go to someone as a first language? Absolutely not. Would I professionally recommend Go to a company in order to lower the skill ceiling to floor, keep seniors+ in check, and keep juniors safe? Yes. That is all it is good at. Everything else it offers another language does better. I have about a decade and a half of experience as a software engineer. In almost every case, over a long enough time period, a centrally dictated constrained system is almost never ideal. I've ported more companies off Ruby on Rails onto something sensible than I can keep count of. I imagine I will be able to charge $150/hr to do that for companies who bought into Go in about 10 years as well. Once you need to reach outside that box to do a very bespoke task your company needs you're stuck. With RoR I found this to be the case with ActiveRecord. With Golang I imagine it'll either be the concurrency model or the stiff parameters for nearly every aspect of the language. My present company is already at that stage. Their answer was to build around it. So now we have a hodge-podge of tooling in a couple languages and all benefits of a centrally governed language have gone out the window. These days I generally recommend most people run Python as it seems the most future proof. I've also recommended a few companies move back to Java due to constraints Python could not solve for.
jjtheblunt 3y ago
Pike said that.
bborud 3y ago
One thing 4 decades of writing code has taught me that when experienced programmers get cocky, code quality suffers because a) cocky programmers tend to not be as smart as they think, yet take risks that will sooner or later trip up even themselves, and b) nobody but you gives a shit how clever your code is and clever code is really just a burden and a liability. It is not a problem that Go manages more developers to perform well. It is a clear advantage. Thinking it is a problem says something about lack of maturity.
namaria 3y ago
If I could only collaborate with and work on stuff built by better programmers then me, I wouldn't mind grokking whatever language/tooling to do it. Since I'm probably very average, I'd rather be safe from having to deal with the mess left by bellow average work. So for me it goes Go for work, and a lot of Forth, Lisp (Scheme and Racket mostly), Elixir/Erlang on my own time. Whatever doesn't need to touch other people's work can be malleable as possible. If it gets publicly pawed at, I need carbon steel rails thank you very much.
Vanclief 3y ago
I don't think that its bad for the motivated engineer, its just a trade off between expressiveness and simplicity. I personally find myself choosing go because I feel I am way more productive with the language. By keeping me constrained, I have less choices to make on how I solve the problem, and focus more on solving the problem.
- frakt0x90 3y ago
  I agree about the constraints. That was my biggest complaint when I learned Scala. Every single thing I built there were 10 different ways I could do it and it really slowed me down. I'm sure if I stuck with the language I would get a feel for the idiomatic ways over time but... I'd rather just make stuff.
  - CuriousSkeptic 3y ago
    I suspect I would agree with this today, but just for the contrast. At the time (about 12 years ago now I think) coming from Java it felt like someone lifted the ceiling, suddenly I no longer felt like always bumping into the lid of the jar when trying to abstract away repetitive code.
  - kaba0 3y ago
    Then go with java which is just an all around better language.
philosopher1234 3y ago
This is so condescending, but I'm glad you're not pretending to have some other motivation. Go was designed for new devs (per pike, i dont think kernighan ever said this) and that is good for all devs, even those with overinflated egos. Making your software easy to understand and think about is good, and effective engineers will get more done working with simple code than complex code that memorializes their useless brainpower.
- didntcheck 3y ago
  Don't shoot the messenger, the condescension is Go and Pike's. He pretty much explicitly said he wrote Go to solve the problem of programmers who he considered too stupid to program anything else properly, and his behaviour (both in personal conduct and decision making) has continued this trend of treating his users like idiot sheep who can't be trusted with any language features much beyond 80s imperative programming. It all feels a bit "old man spiteful at kids these days"
  - trane_project 3y ago
    Rob Pike once told me I was a moron (not those exact words) but that intent when I asked a question in some performance Golang slack about how big a Golang map is in memory (as in the total bytes used by it internally). He went to a previous commit from the one I had linked, saw my stupid attempt at estimating it, and proceeded to go on a rant in which he simultaneously called me an idiot and pointed to the answers in the runtime code. Pretty entertaining. Of course, the code was stupid because I wrote it knowingly so, just so I could fill the function with compilable code and go debug something else. I guess not writing a comment is on me for not knowing Rob Pike was going to go out of his way to find it the next day. Fun day at the office, that one. So yeah, I am not the greatest fan of Go or him either. But that was from way before when I had to write a JSON-LD parsing library and cast stuff to `interface{}` everywhere. I write personal stuff in Rust now, but would happily do it in any other language with a proper toolchain and type system. Go has only one of those, so I don't dislike it. Just don't really enjoy it.
  - philosopher1234 3y ago
lelanthran 3y ago
I think you're incorrect. It's good for the motivated engineer, because instead of running off and creating architecture astronautical wonders of over-engineering, they are getting down to business and making progress to a goal. Your bottom-tier engineers aren't going to be any better in Go than they are going to be in Java.
- kaba0 3y ago
  Copy pasting code definitely helps you grow as an engineer.. also, the more often you write err != nil, the better the code will be, right?
  - lelanthran 3y ago
    I didn't assert either of those things.
  - bsaul 3y ago
    Generics , although kept simple, definitely reduced the amount of copy pasting in go. I actually think go generic’s system is the best i’ve seen because they managed to provide enough features to remove the stupid parts of the language, while not changing the general feeling and encourage devs to build abstraction monsters.
- littlestymaar 3y ago
  > instead of running off and creating architecture astronautical wonders of over-engineering Maybe in theory, in practice you get people writing their own implementation of generics with codegen and Canadian aboriginal syllabics…
  - philosopher1234 3y ago
    Did that happen more than once?
    - littlestymaar 3y ago
      That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. Another famous example is how k8s, dealt with the lack of generics: https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i...
api 3y ago
This is the central fallacy of developer culture: that complexity is a sign of intelligence and that complex systems are superior. Simplicity is much harder than complexity. Anyone can add and anyone can subtract recklessly, but it takes genius to subtract without losing too much in the process. The genius is in identifying the essential complexity in a problem and finding ways to dispense with incidental complexity. I've personally been using Rust more lately for various reasons, but I really do like Go and think its choices are excellent for its niche. In any case simplicity can be practiced in any language by choosing the most straightforward way to achieve things and avoiding over-engineering. Rust has a lot of features and paradigms but I can be productive in it by remembering that just because it's there doesn't mean you always have to use it.
- throwaway894345 3y ago
  The problem with complex languages is that while you can choose to eschew complexity in the code you write, you very often have to deal with the complexity in the libraries you use. So in languages like Rust and C++ you tend to have a high degree of complexity (at least by way of high degrees of abstraction) in the standard library and the wider ecosystem because abstraction (and thus complexity) are valued and idiomatic in their respective ecosystems—it makes it very hard to opt out of. For example, at least for a good while, there wasn’t a great JSON parser library except serde which is immensely complex and I would spend a lot of time troubleshooting errors in the macro expansions for things that would Just Work in Go’s encoding/json (of course, there are plenty of legitimate grievances with encoding/json, but these are mostly orthogonal to the simplicity/complexity discussion).
- kaba0 3y ago
  People should really watch Hickey’s talk — simple is not easy. Plenty (if not most) problems are complex (otherwise why would we bother with computers?), and complexity can’t be reduced just by “taking it apart”. The composition of two functions can have an entirely different complexity than what they have differently. Abstraction is the only way we can combat complexity (and as mentioned, most of that complexity is essential that can’t be reduced further), so if a given language sucks at it, it sucks.
fuzztester 3y ago
As someone else here said, it may not be Kernighan who said that, but Rob Pike. And he didn't say lowest common denominator developer, he said something like junior Google developer. And IIRC he said it somewhere in his blog, called command-central.blogspot.com or some such.
- throwaway894345 3y ago
  He was also contrasting it with C++ which has many dozens of features and a developer has to understand the interplay between all of them to use the language effectively.
  - fuzztester 3y ago
    Right, I remember, and in this case, "a developer" applied to not just future junior Googlers, but also him and some of his project mates, and in that same post he said they hated or at least disliked those issues with C++.
    - fuzztester 3y ago
      Not sure if this post below is the same as that post mentioned above, since it's some years since I first read the above one, but the one below is interesting anyway: Less is exponentially more: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
cube2222 3y ago
> once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. > Bad for the motivated engineer. Sounds to me like it's really just bad for the engineer who wants to show off how smart they are through the overcomplicated custom abstractions they build. Condescending response to condescending comment aside, I understand that those custom abstractions can occasionally be great and have their place, but in practice their value usually starts reversing (yes, reversing, not diminishing) once you need to onboard many engineers frequently (junior or senior alike), which is the case for a big part of tech projects (think big tech, high growth startups, but also open source projects where you want first-time contributors to be able to dive in and solve their issue quickly). And I'm saying this as a motivated engineer who loves playing with various languages but uses Go for most serious things.
- c_crank 3y ago
  For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply because Go doesn't have the tools for them. So long as you stay away from Spring Boot and Hibernate, Java doesn't have to be all about BeanFactories. (Funny aside - somehow, Google managed to turn Rust into abstraction hell: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/factory/factory_store_providers/src/main.rs https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...)
  - bborud 3y ago
    But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".
    - c_crank 3y ago

by zer8k 3y ago

Philip-J-Fry 3y ago

>I don't mean this in a sarcastic way but Go was explicitly designed for the lowest common denominator developer. Kernighan said it himself. What's the issue with making Go good for the lowest common denominator developer? This is fantastic for businesses as they can get new developers productive within a few days. It's great for the ecosystem because the barrier of entry is low. Just because it's made simple and easy to pick up doesn't mean you can't write complex software with it. It's a programming language, you can write whatever you want with it. If it makes writing complex software easier, then that's a good thing. The only reason why someone would think that's not a good thing is their ego because $FAVOURITE_LANGUAGE has 10x as many language features and 10x as many ways to do the exact same thing. What is this walled garden you think exists that prevents motivated engineers from doing good work? I like to think of myself as motivated and Go is the reason for that. It made writing complicated concurrent software so much easier for me, and it made reasoning about them so much easier. I do not understand this criticism of Go.

didntcheck 3y ago
I can't help but feel that the reason why new developers reach parity with existing ones so quickly is not due to the productivity of Go, but because the productivity ceiling has been intentionally lowered so that everyone is equally constrained. Having to keep reading reinvented wheels because the language is intentionally poorly expressive is a burden on getting work done. There maybe is only one way to do a thing, and everyone has to keep doing it, rather than being able to write it once and build an abstraction Compare say Java 5 code written with raw servlets implementations and JDBC calls versus modern Spring code. The implementation of the former is easier to understand because everything is very explicit, but the intent of the latter is far easier to understand, since the boilerplate is mostly gone, allowing the actual business logic (what you care about 90% of the time) to be obvious. And you can of course see the implementation if you need to
- erik_seaberg 3y ago
  Every time I hear “our experts’ code can look like our beginners’ code” I cringe, because experts’ time is much more valuable and they should be communicating concisely. A beginner’s job is to become an expert.

throwaway894345 3y ago

I don’t think this is a bad thing. Most developers think of themselves as more advanced than they are and end up making a mess trying to do abstraction beyond both their ability to do it well and beyond what the problem requires. And even the truly advanced developers very often prefer simpler tooling because it allows them to concentrate their resources on the complexities of the problem and not those of the tool. Further, the idea that Go is somehow bad for motivated engineers doesn’t match my experience and it doesn’t explain the proliferation of interesting tools and services (much of the container / devops ecosystem). I think your mistake is assuming that the only kind of motivation/creativity/etc involves tinkering with language runtimes and that someone who is building original things like Docker, Terraform, or Kubernetes must be “unmotivated”.

jdndxkcofn 3y ago

Hot-take from a bottom-tier dev that thinks running off and creating a bunch of bullshit nobody else can support is a good idea^tm.

zer8k 3y ago
I wouldn't call myself a bottom tier dev. I've done plenty of Go programming in a corporate-ish environment. It's restrictive, which is nice, because the ceiling for expert is basically on the floor. It's the Ruby on Rails of programming languages. A perfect walled garden, lead by a benevolent dictator (Google), who will guide us all to the promised land. Would I recommend Go to someone as a first language? Absolutely not. Would I professionally recommend Go to a company in order to lower the skill ceiling to floor, keep seniors+ in check, and keep juniors safe? Yes. That is all it is good at. Everything else it offers another language does better. I have about a decade and a half of experience as a software engineer. In almost every case, over a long enough time period, a centrally dictated constrained system is almost never ideal. I've ported more companies off Ruby on Rails onto something sensible than I can keep count of. I imagine I will be able to charge $150/hr to do that for companies who bought into Go in about 10 years as well. Once you need to reach outside that box to do a very bespoke task your company needs you're stuck. With RoR I found this to be the case with ActiveRecord. With Golang I imagine it'll either be the concurrency model or the stiff parameters for nearly every aspect of the language. My present company is already at that stage. Their answer was to build around it. So now we have a hodge-podge of tooling in a couple languages and all benefits of a centrally governed language have gone out the window. These days I generally recommend most people run Python as it seems the most future proof. I've also recommended a few companies move back to Java due to constraints Python could not solve for.

jjtheblunt 3y ago

Pike said that.

bborud 3y ago

One thing 4 decades of writing code has taught me that when experienced programmers get cocky, code quality suffers because a) cocky programmers tend to not be as smart as they think, yet take risks that will sooner or later trip up even themselves, and b) nobody but you gives a shit how clever your code is and clever code is really just a burden and a liability. It is not a problem that Go manages more developers to perform well. It is a clear advantage. Thinking it is a problem says something about lack of maturity.

namaria 3y ago

If I could only collaborate with and work on stuff built by better programmers then me, I wouldn't mind grokking whatever language/tooling to do it. Since I'm probably very average, I'd rather be safe from having to deal with the mess left by bellow average work. So for me it goes Go for work, and a lot of Forth, Lisp (Scheme and Racket mostly), Elixir/Erlang on my own time. Whatever doesn't need to touch other people's work can be malleable as possible. If it gets publicly pawed at, I need carbon steel rails thank you very much.

Vanclief 3y ago

I don't think that its bad for the motivated engineer, its just a trade off between expressiveness and simplicity. I personally find myself choosing go because I feel I am way more productive with the language. By keeping me constrained, I have less choices to make on how I solve the problem, and focus more on solving the problem.

frakt0x90 3y ago
I agree about the constraints. That was my biggest complaint when I learned Scala. Every single thing I built there were 10 different ways I could do it and it really slowed me down. I'm sure if I stuck with the language I would get a feel for the idiomatic ways over time but... I'd rather just make stuff.
- CuriousSkeptic 3y ago
  I suspect I would agree with this today, but just for the contrast. At the time (about 12 years ago now I think) coming from Java it felt like someone lifted the ceiling, suddenly I no longer felt like always bumping into the lid of the jar when trying to abstract away repetitive code.
- kaba0 3y ago
  Then go with java which is just an all around better language.

philosopher1234 3y ago

This is so condescending, but I'm glad you're not pretending to have some other motivation. Go was designed for new devs (per pike, i dont think kernighan ever said this) and that is good for all devs, even those with overinflated egos. Making your software easy to understand and think about is good, and effective engineers will get more done working with simple code than complex code that memorializes their useless brainpower.

didntcheck 3y ago
Don't shoot the messenger, the condescension is Go and Pike's. He pretty much explicitly said he wrote Go to solve the problem of programmers who he considered too stupid to program anything else properly, and his behaviour (both in personal conduct and decision making) has continued this trend of treating his users like idiot sheep who can't be trusted with any language features much beyond 80s imperative programming. It all feels a bit "old man spiteful at kids these days"
- trane_project 3y ago
  Rob Pike once told me I was a moron (not those exact words) but that intent when I asked a question in some performance Golang slack about how big a Golang map is in memory (as in the total bytes used by it internally). He went to a previous commit from the one I had linked, saw my stupid attempt at estimating it, and proceeded to go on a rant in which he simultaneously called me an idiot and pointed to the answers in the runtime code. Pretty entertaining. Of course, the code was stupid because I wrote it knowingly so, just so I could fill the function with compilable code and go debug something else. I guess not writing a comment is on me for not knowing Rob Pike was going to go out of his way to find it the next day. Fun day at the office, that one. So yeah, I am not the greatest fan of Go or him either. But that was from way before when I had to write a JSON-LD parsing library and cast stuff to `interface{}` everywhere. I write personal stuff in Rust now, but would happily do it in any other language with a proper toolchain and type system. Go has only one of those, so I don't dislike it. Just don't really enjoy it.
- philosopher1234 3y ago

lelanthran 3y ago

I think you're incorrect. It's good for the motivated engineer, because instead of running off and creating architecture astronautical wonders of over-engineering, they are getting down to business and making progress to a goal. Your bottom-tier engineers aren't going to be any better in Go than they are going to be in Java.

kaba0 3y ago
Copy pasting code definitely helps you grow as an engineer.. also, the more often you write err != nil, the better the code will be, right?
- lelanthran 3y ago
  I didn't assert either of those things.
- bsaul 3y ago
  Generics , although kept simple, definitely reduced the amount of copy pasting in go. I actually think go generic’s system is the best i’ve seen because they managed to provide enough features to remove the stupid parts of the language, while not changing the general feeling and encourage devs to build abstraction monsters.
littlestymaar 3y ago
> instead of running off and creating architecture astronautical wonders of over-engineering Maybe in theory, in practice you get people writing their own implementation of generics with codegen and Canadian aboriginal syllabics…
- philosopher1234 3y ago
  Did that happen more than once?
  - littlestymaar 3y ago
    That particular example of course no, but people writing overengineered beasts to overcome go's limitation happens all the time. Another famous example is how k8s, dealt with the lack of generics: https://medium.com/@arschles/go-experience-report-generics-in-kubernetes-25da87430301 https://medium.com/@arschles/go-experience-report-generics-i...

api 3y ago

This is the central fallacy of developer culture: that complexity is a sign of intelligence and that complex systems are superior. Simplicity is much harder than complexity. Anyone can add and anyone can subtract recklessly, but it takes genius to subtract without losing too much in the process. The genius is in identifying the essential complexity in a problem and finding ways to dispense with incidental complexity. I've personally been using Rust more lately for various reasons, but I really do like Go and think its choices are excellent for its niche. In any case simplicity can be practiced in any language by choosing the most straightforward way to achieve things and avoiding over-engineering. Rust has a lot of features and paradigms but I can be productive in it by remembering that just because it's there doesn't mean you always have to use it.

throwaway894345 3y ago
The problem with complex languages is that while you can choose to eschew complexity in the code you write, you very often have to deal with the complexity in the libraries you use. So in languages like Rust and C++ you tend to have a high degree of complexity (at least by way of high degrees of abstraction) in the standard library and the wider ecosystem because abstraction (and thus complexity) are valued and idiomatic in their respective ecosystems—it makes it very hard to opt out of. For example, at least for a good while, there wasn’t a great JSON parser library except serde which is immensely complex and I would spend a lot of time troubleshooting errors in the macro expansions for things that would Just Work in Go’s encoding/json (of course, there are plenty of legitimate grievances with encoding/json, but these are mostly orthogonal to the simplicity/complexity discussion).
kaba0 3y ago
People should really watch Hickey’s talk — simple is not easy. Plenty (if not most) problems are complex (otherwise why would we bother with computers?), and complexity can’t be reduced just by “taking it apart”. The composition of two functions can have an entirely different complexity than what they have differently. Abstraction is the only way we can combat complexity (and as mentioned, most of that complexity is essential that can’t be reduced further), so if a given language sucks at it, it sucks.

fuzztester 3y ago

As someone else here said, it may not be Kernighan who said that, but Rob Pike. And he didn't say lowest common denominator developer, he said something like junior Google developer. And IIRC he said it somewhere in his blog, called command-central.blogspot.com or some such.

throwaway894345 3y ago
He was also contrasting it with C++ which has many dozens of features and a developer has to understand the interplay between all of them to use the language effectively.
- fuzztester 3y ago
  Right, I remember, and in this case, "a developer" applied to not just future junior Googlers, but also him and some of his project mates, and in that same post he said they hated or at least disliked those issues with C++.
  - fuzztester 3y ago
    Not sure if this post below is the same as that post mentioned above, since it's some years since I first read the above one, but the one below is interesting anyway: Less is exponentially more: https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

cube2222 3y ago

> once you want to go venture outside the safety of the walled garden you can't. The language is specifically designed to keep you as safe as possible. > Bad for the motivated engineer. Sounds to me like it's really just bad for the engineer who wants to show off how smart they are through the overcomplicated custom abstractions they build. Condescending response to condescending comment aside, I understand that those custom abstractions can occasionally be great and have their place, but in practice their value usually starts reversing (yes, reversing, not diminishing) once you need to onboard many engineers frequently (junior or senior alike), which is the case for a big part of tech projects (think big tech, high growth startups, but also open source projects where you want first-time contributors to be able to dive in and solve their issue quickly). And I'm saying this as a motivated engineer who loves playing with various languages but uses Go for most serious things.

c_crank 3y ago
For serious work, Java has a bigger list of features, both on the primitive side and the abstract, that let you handle a lot more use cases than Go simply because Go doesn't have the tools for them. So long as you stay away from Spring Boot and Hibernate, Java doesn't have to be all about BeanFactories. (Funny aside - somehow, Google managed to turn Rust into abstraction hell: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/factory/factory_store_providers/src/main.rs https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/s...)
- bborud 3y ago
  But do you really need those features? Or is it just force of habit? Learning how to express oneself consistently and with no more fluff than is strictly needed is much harder than people think. I admire people who can solve complex problems by simple means. I'm not terribly impressed by people whose obsessions drive them to write code with low readability. What features does Java have, and Go lack, which represent a real problem? With emphasis on the word "real".
  - c_crank 3y ago