11 ms·

> *Even if we are using a language that manages memory itself like Erlang, nothing prevents us from understanding how memory is allocated and deallocated. Unlik

> *Even if we are using a language that manages memory itself like Erlang, nothing prevents us from understanding how memory is allocated and deallocated. Unlike Go Language Memory Model Documentation Page that advices “If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don’t be clever.”, I believe that we must be clever enough to make our system faster and safer, and sometimes it doesn’t happen unless we dig deeper into what is going on.* I dunno, article seems right about this. Golang docs sound condescending.

blacktriangle 6y ago
Golang itself is condescending. It was basically invented as a way to get fresh CS grads productive ASAP with as little understanding as possible.
- brudgers 6y ago
  Google is an enterprise. Go is an enterprise language. For the usual enterprise reasons: bean counting, internal politics, and cubicles. It is a great language because it solves Google's problems. That's true of all Google tools and services. To the degree a person has the same problems as Google, their tools are great. Most people and organizations don't have Google's problems to a significant degree.
  - bsaul 6y ago
    "Most people and organizations don't have Google's problems to a significant degree" Except in this particular case, i believe the average junior Googler is far more capable of handling advanced language as the average junior employee of any regular corp. Which means go's tradeoff toward "simplicity" is probably the wisest for them as well.
    - blacktriangle 6y ago
      Honestly I'd argue that that is more of a Google/large corporate problem. The thing about junior devs is that in order to hire a bunch of them and get anything productive out of them, you need a ton of people above them. You need to spend more time on design to give them more clear requirements, you need more senior devs to provide mentorship, you need more management. Smaller dev shops don't have that, they can only bring on 1-2 juniors at a time and hope for the best.
    - waynesonfire 6y ago
      No, I'd argue that both are incapable, you can't teach experience. Junior Googlers are just more "dangerous" as they probably start their career on bigger problems and share with the average a similar set of "unknown unknowns". Enterprise languages, like Java and Go (in contrast to Scala or Perl) are designed to keep people on rails. This can be accomplished by for example, limiting the number of ways a problem can be solved by the primitives of the language. This is why the "most fast and break things" paradigm at Facebook didn't align with me. They basically announced that they're not concerned about these rails. Not to say it's a bad approach, FB is a very successful software company, just one that doesn't align with _my_ values. I think they've since moved away from this.
      - pjmlp 6y ago
        Except Go in 2021 is like Java in 2000, so a bit hard to put both on the same level.
        throwaway894345 6y ago
        I get that Go doesn't have generics and is generally in the C-family of languages, but beyond that there's not much to compare--I'm shocked that anyone would even make the assertion. Go has first class functions, value types, generic slice/hashmap/channels/etc, goroutines, and type inference, and it lacks inheritance and constructors. Those different feature sets predictably breed very different programming paradigms. Notably, I recall early Java was all about inheritance and distributing your object graph arbitrarily among constructors.
    - brudgers 6y ago
      To a first approximation comparing junior developers broadly is analogous to comparing +0, 0, and -0.
      - warmwaffles 6y ago
        For very large values of 0
  - pjmlp 6y ago
    Python, TypeScript, COBOL, VB.NET, Java and C# are all enterprise languages, yet all of them are PhD level as per Go advocacy.
    - brudgers 6y ago
      Python is one of the problems Go addresses. Three of the other languages are for Microsoft's Enterprise needs which significantly predate are distinct from Google's. COBOL solves a problem Google doesn't have: producing code that a non-technical person can learn to read and understand. The general. The CEO.
      - pjmlp 6y ago
        Yet the majority of Google's problems are solved with Python, Java, Kotlin, and C++, not Go. Go doesn't address any Python issue, besides AOT compilation, easily solved if PyPy had more community love.
        throwaway894345 6y ago
        > Yet the majority of Google's problems are solved with Python, Java, Kotlin, and C++, not Go. That's not very informative... Google had millions of lines of code in Python, Java, and C++ before Go hit 1.0 (to the extent that Kotlin enjoys wide adoption inside Google, it could be explained by compatibility with existing Java code, especially the Android niche). It would be more interesting to look at Greenfield projects which don't depend on existing Google libraries, although even then Go would have to be quite a lot better than the competition in order to get a team with a long history of proficiency in Java to migrate to a new, relatively unproven language. > Go doesn't address any Python issue, besides AOT compilation, easily solved if PyPy had more community love. Are you suggesting that if PyPy had more investment it would become an AOT compiler rather than a JIT compiler? Anyway, "if only the community invested in it more" is like the whole problem with the Python ecosystem. If the community invested in solving package management, Python wouldn't have such an abysmal package management story. If the community invested in a smaller C extension interface, PyPy could be fast and compatible and CPython would be freer to optimize without worrying about breaking compatibility. I've been working with Python professionally for ~15 years now and I'm pulling for it, but come on... The idea that Go is only better with respect to AOT (ignoring that AOT is not an end to itself) is out of touch with reality. Go is 2-3 orders of magnitude more performant than Python, it's statically typed (yes, mypy exists but it's still alpha quality and I'm happy to back up that assertion if necessary), it has a sane package management story (yes there are warts, but that's still far better than the Python package management story), documentation is much better in every respect (the tooling, the centralization, the readability, the accuracy, etc), etc. These aren't small things--I've seen projects fail for poor performance, and I've spent weeks trying to find a way to get fast, reproducible builds (before giving up). There are certainly areas where Python bests Go (e.g., data science ecosystem, web frameworks, etc), but the idea that Go only has AOT over Python is absurd.
- gh-throw 6y ago
  Golang isn't a language for the person writing code today—it's a language for the person who has to come along and take over their codebase after they leave. The farther away I get from "fresh CS grad", actually, the less I give a shit about catering to the person writing the code and helping them express themselves optimally, and the more I care about how much hair I'll lose trying to figure out someone's meta programming or shoehorned-in-because-it's-fashionable functional crap. Either of which I can write just fine, thank you very much, but god knows I'm sick of inheriting such codebases, to the point that these days I basically just won't do that anymore. You have a Rails "app" that's been through three development teams? Cool, good luck with that, next opportunity, thanks. You're not only using React, but your codebase is purely functional (I mean, your functions are objects, you know, but that's quibbling, OK, sure, it's purely functional conceptually-speaking) top-to-bottom and you've got all kinds of supporting libraries to make Javascript contort into kinda-halfway working for this pattern? And you're thinking about porting to Purescript so you can better express yourselves with types? That sounds very nice, but I'm sure it's just too smart for me, thanks for the offer. You're using Go, Typescript where you have to, and your mobile apps are boring, straightforward native code? Oh thank god. When do I start?
  - pjmlp 6y ago
    Not sure if TypeScript, Kotlin, Java, Objective-C and Swift aren't too way over their head for the typical Go user.
    - gh-throw 6y ago
      Of those only Java (and, by association, Kotlin, since you'll likely be interacting with Java) strikes me as often-hard-to-read, mostly because of the cultural love of using ten layers to do what two or three layers could. But the tools are good enough that it makes it merely annoying, rather than productivity-torpedoing.
      - pjmlp 6y ago
        Given that they are PhD level languages from Go developers point of view, maybe tooling alone won't be enough.
- cosmodisk 6y ago
  Possibly, but the other side of the spectrum doesn't look any prettier either: people need to spend nearly a decade in the industry just to ne able to have a decent grasp of some of the languages because someone, somewhere decided that bundling a bucket, rocket, anti-gravity device,and Stanley knife was a good idea. I've gone through majority of the comments in this thread and it's still the never ending search for the holy grail of programming languages.
tedunangst 6y ago
That's a very weird reference. The go memory model docs aren't describing garbage collector implementation behavior. I think they're correct that if you need to study up the happens before spec, you're on thin ice.
_rlh 6y ago
I think you are confusing memory management with memory model. Memory management is about garbage collection, RC, malloc / free, and allocations. Memory models are about what happens when you read and write to shared mutable memory. I'm not a Erlang programmer but in general the Actors concurrency model does not support shared mutable memory. Don't be clever.

blacktriangle 6y ago

Golang itself is condescending. It was basically invented as a way to get fresh CS grads productive ASAP with as little understanding as possible.

brudgers 6y ago
Google is an enterprise. Go is an enterprise language. For the usual enterprise reasons: bean counting, internal politics, and cubicles. It is a great language because it solves Google's problems. That's true of all Google tools and services. To the degree a person has the same problems as Google, their tools are great. Most people and organizations don't have Google's problems to a significant degree.
- bsaul 6y ago
  "Most people and organizations don't have Google's problems to a significant degree" Except in this particular case, i believe the average junior Googler is far more capable of handling advanced language as the average junior employee of any regular corp. Which means go's tradeoff toward "simplicity" is probably the wisest for them as well.
  - blacktriangle 6y ago
    Honestly I'd argue that that is more of a Google/large corporate problem. The thing about junior devs is that in order to hire a bunch of them and get anything productive out of them, you need a ton of people above them. You need to spend more time on design to give them more clear requirements, you need more senior devs to provide mentorship, you need more management. Smaller dev shops don't have that, they can only bring on 1-2 juniors at a time and hope for the best.
  - waynesonfire 6y ago
    No, I'd argue that both are incapable, you can't teach experience. Junior Googlers are just more "dangerous" as they probably start their career on bigger problems and share with the average a similar set of "unknown unknowns". Enterprise languages, like Java and Go (in contrast to Scala or Perl) are designed to keep people on rails. This can be accomplished by for example, limiting the number of ways a problem can be solved by the primitives of the language. This is why the "most fast and break things" paradigm at Facebook didn't align with me. They basically announced that they're not concerned about these rails. Not to say it's a bad approach, FB is a very successful software company, just one that doesn't align with _my_ values. I think they've since moved away from this.
    - pjmlp 6y ago
      Except Go in 2021 is like Java in 2000, so a bit hard to put both on the same level.
      - throwaway894345 6y ago
        I get that Go doesn't have generics and is generally in the C-family of languages, but beyond that there's not much to compare--I'm shocked that anyone would even make the assertion. Go has first class functions, value types, generic slice/hashmap/channels/etc, goroutines, and type inference, and it lacks inheritance and constructors. Those different feature sets predictably breed very different programming paradigms. Notably, I recall early Java was all about inheritance and distributing your object graph arbitrarily among constructors.
  - brudgers 6y ago
    To a first approximation comparing junior developers broadly is analogous to comparing +0, 0, and -0.
    - warmwaffles 6y ago
      For very large values of 0
- pjmlp 6y ago
  Python, TypeScript, COBOL, VB.NET, Java and C# are all enterprise languages, yet all of them are PhD level as per Go advocacy.
  - brudgers 6y ago
    Python is one of the problems Go addresses. Three of the other languages are for Microsoft's Enterprise needs which significantly predate are distinct from Google's. COBOL solves a problem Google doesn't have: producing code that a non-technical person can learn to read and understand. The general. The CEO.
    - pjmlp 6y ago
      Yet the majority of Google's problems are solved with Python, Java, Kotlin, and C++, not Go. Go doesn't address any Python issue, besides AOT compilation, easily solved if PyPy had more community love.
      - throwaway894345 6y ago
        > Yet the majority of Google's problems are solved with Python, Java, Kotlin, and C++, not Go. That's not very informative... Google had millions of lines of code in Python, Java, and C++ before Go hit 1.0 (to the extent that Kotlin enjoys wide adoption inside Google, it could be explained by compatibility with existing Java code, especially the Android niche). It would be more interesting to look at Greenfield projects which don't depend on existing Google libraries, although even then Go would have to be quite a lot better than the competition in order to get a team with a long history of proficiency in Java to migrate to a new, relatively unproven language. > Go doesn't address any Python issue, besides AOT compilation, easily solved if PyPy had more community love. Are you suggesting that if PyPy had more investment it would become an AOT compiler rather than a JIT compiler? Anyway, "if only the community invested in it more" is like the whole problem with the Python ecosystem. If the community invested in solving package management, Python wouldn't have such an abysmal package management story. If the community invested in a smaller C extension interface, PyPy could be fast and compatible and CPython would be freer to optimize without worrying about breaking compatibility. I've been working with Python professionally for ~15 years now and I'm pulling for it, but come on... The idea that Go is only better with respect to AOT (ignoring that AOT is not an end to itself) is out of touch with reality. Go is 2-3 orders of magnitude more performant than Python, it's statically typed (yes, mypy exists but it's still alpha quality and I'm happy to back up that assertion if necessary), it has a sane package management story (yes there are warts, but that's still far better than the Python package management story), documentation is much better in every respect (the tooling, the centralization, the readability, the accuracy, etc), etc. These aren't small things--I've seen projects fail for poor performance, and I've spent weeks trying to find a way to get fast, reproducible builds (before giving up). There are certainly areas where Python bests Go (e.g., data science ecosystem, web frameworks, etc), but the idea that Go only has AOT over Python is absurd.
gh-throw 6y ago
Golang isn't a language for the person writing code today—it's a language for the person who has to come along and take over their codebase after they leave. The farther away I get from "fresh CS grad", actually, the less I give a shit about catering to the person writing the code and helping them express themselves optimally, and the more I care about how much hair I'll lose trying to figure out someone's meta programming or shoehorned-in-because-it's-fashionable functional crap. Either of which I can write just fine, thank you very much, but god knows I'm sick of inheriting such codebases, to the point that these days I basically just won't do that anymore. You have a Rails "app" that's been through three development teams? Cool, good luck with that, next opportunity, thanks. You're not only using React, but your codebase is purely functional (I mean, your functions are objects, you know, but that's quibbling, OK, sure, it's purely functional conceptually-speaking) top-to-bottom and you've got all kinds of supporting libraries to make Javascript contort into kinda-halfway working for this pattern? And you're thinking about porting to Purescript so you can better express yourselves with types? That sounds very nice, but I'm sure it's just too smart for me, thanks for the offer. You're using Go, Typescript where you have to, and your mobile apps are boring, straightforward native code? Oh thank god. When do I start?
- pjmlp 6y ago
  Not sure if TypeScript, Kotlin, Java, Objective-C and Swift aren't too way over their head for the typical Go user.
  - gh-throw 6y ago
    Of those only Java (and, by association, Kotlin, since you'll likely be interacting with Java) strikes me as often-hard-to-read, mostly because of the cultural love of using ten layers to do what two or three layers could. But the tools are good enough that it makes it merely annoying, rather than productivity-torpedoing.
    - pjmlp 6y ago
      Given that they are PhD level languages from Go developers point of view, maybe tooling alone won't be enough.
cosmodisk 6y ago
Possibly, but the other side of the spectrum doesn't look any prettier either: people need to spend nearly a decade in the industry just to ne able to have a decent grasp of some of the languages because someone, somewhere decided that bundling a bucket, rocket, anti-gravity device,and Stanley knife was a good idea. I've gone through majority of the comments in this thread and it's still the never ending search for the holy grail of programming languages.

tedunangst 6y ago

That's a very weird reference. The go memory model docs aren't describing garbage collector implementation behavior. I think they're correct that if you need to study up the happens before spec, you're on thin ice.

_rlh 6y ago

I think you are confusing memory management with memory model. Memory management is about garbage collection, RC, malloc / free, and allocations. Memory models are about what happens when you read and write to shared mutable memory. I'm not a Erlang programmer but in general the Actors concurrency model does not support shared mutable memory. Don't be clever.