6 ms·

>> I love Go. In spite of all its quirks and foot guns ... programming in Go for ... a decade Why do so many go devs feel the need to make statements like this

>> I love Go. In spite of all its quirks and foot guns ... programming in Go for ... a decade Why do so many go devs feel the need to make statements like this. Go has issues, the are well known and easy to work with/around. Every language has these, every single one. Also GO, and rust (and zig for that matter) have all sort of found their lanes at this point. Candidly the constant comparisons between the two (when they are much more complimentary) is getting tired.

chrsig 3y ago
You're just experiencing time passing on the internet. Some discussions spring eternal, because there's a constant stream of people having it for the first time.
- georgespencer 3y ago
  Obligatory link to Eternal September: https://en.wikipedia.org/wiki/Eternal_September https://en.wikipedia.org/wiki/Eternal_September
lagniappe 3y ago
I think it is to pre-emptively dismiss inevitable common trope criticisms made about Go. I don't think they truly believe this, it's just the common pattern of speaking in intellectually adversarial discussions in 2020+. - Acknowledge the common criticism - Defeat it with appropriate common retort, or make a small concession - Proceed with the meat of the argument with your most common opponent "disarmed"
- zer00eyz 3y ago
  >> it's just the common pattern of speaking in intellectually adversarial discussions in 2020+. Is it? Because I dont see JS or python apologists? Did I miss a corresponding lament about rust compile times in the article?
  - mikepurvis 3y ago
    Ehh, those communities have their equivalent issues. At least for Python it's some combination of: I know Py3 was a nightmare and packaging in general is a dumpster fire, testing is a constellation of incompatible tools and practices, MyPy and progressive typing is an embarrassing half-baked mess, and deployment is only really possible when you bundle an entire system image into a container— but hey, developer productivity right?
  - lalskii 3y ago
    [flagged]
  - hot_gril 3y ago
    Mention how NodeJS has simple package management while Python doesn't, you'll find the Python apologists explaining why somehow it was an impossible task for Python to do packages right for legacy reasons, even though they got to force a whole breaking 2->3 version change. Also bring up the GIL, and you'll be told how Python is implementation-agnostic.
    - majoe 3y ago
      Packaging is indeed a weakness of Python, but to be fair, that Python packages are frequently wrapping C, C++ or Fortran code makes packaging a lot harder compared to nodejs.
      - hot_gril 3y ago
        There are NodeJS packages wrapping C code too. Probably less common than in Python, but that's not really a reason Python packages are so annoying.
- neonsunset 3y ago
  The sad thing is Go doesn’t need help - it won. It reached critical point where no matter how shitty it is in practice, it will be worked around and made work because engineers have no other choice - that’s what companies impose on them. Like with Python and ML. The optimal amount of bullying towards Go and its proponents is always “more”.
deleted 3y ago
[deleted]
okhugres 3y ago
It’s frustration at having to learn more than one programming language. At this time, due to the social integration of technology the number of people who interact with development has far out paced the number of people who enjoy development. > they are much more complimentary If you hate writing code but do it for your job, then you are going to really hate writing code in two different languages with their own syntax and paradigms. Also, nearly all programming language projects want to be the “everything language” so essentially any language is a fine choice and what it really comes down to is the people who enjoy the work develop “tastes” and “preferences” that they treat as dogma when defending their language of choice.
- lagniappe 3y ago
  > It’s frustration at having to learn more than one programming language. Imagine bob ross with only one color could still make something magnificent, but what could he do with two colors? You can't have Burnt Umber without some Phthalo Green..
  - zer00eyz 3y ago
    > Imagine bob ross with only one color could still make something magnificent, but what could he do with two colors? https://www.youtube.com/watch?v=I-ousb8-SD0 https://www.youtube.com/watch?v=I-ousb8-SD0
  - okhugres 3y ago
    Due the concept of Turing completeness I’d argue it’s more of deciding which paint brand to use, or if you must, I suppose you could liken it to the distinction between choosing oils or acrylics.
    - Jtsummers 3y ago
      You don't actually understand Turing completeness if that's your takeaway. Turing completeness is about computational equivalence. That, fundamentally, any Turing complete language can perform the same classes of computations as any other. It says nothing about substitutability of one language for another within any other context.
lumost 3y ago
Having worked in many languages including Go and Rust, I commonly see the following. 1. Team uses some interpreted language. This language is fine for most of their work, but causes performance problems and/or the team needs to do something performance sensitive. 2. Someone on the team proposes Go, often because it solves the performance problem - and is very simple to use. This proposal invites suggestions from the organizations programming language experts leading to "let's use lang X" suggestions. Often these suggestions have recommendations based on advanced programming language features such as high-order types, functional paradigms etc. As Rust has been somewhat popular for backend services, you will find many suggestions of "let's use Rust." These discussions can often be less than civil. As I've aged - I've moved closer to the advanced language features camp - but I'd doubt that this is actually beneficial for productivity. It took me 3 attempts to learn the language and 5 years for Rust to feel productive - now it's my preferred language for side projects. Go took less than a day to pick up.
- mikepurvis 3y ago
  I don't know if it's really still a fair trope at this point, but the argument made is that Go was specifically designed to be the best of Google's three main languages at the time— C++, Java, and Python. It was made to be quick to learn, hard to mess up, and easy to read/review. It specifically includes things like the build tool and formatter because those are long-running pain points in large scale development. Rust, on the other hand, is a borderline research language that was built to support Servo, a web browser backend— literally among the hairiest of sofware engineering problems in existence. It gives you a lot of "safety" but at the cost of having to consider issues that most developers never think about. This is not to say that Go is for dumb programmers and Rust is for smart ones or anything of that sort— just that despite years of evolution, both carry the DNA of their inception, and it shows.
  - lumost 3y ago
    This is exactly so. At the edge, the go community will debate whether the language should be used for a project at all. Whereas the rust community will ship something that only kinda sorta works - or takes performance above all as the primary motivator. As a very experienced engineer, I like the idea of Rust being a go to for all problems. 10 years ago - I would have hated its complexity and cursed the TL who forced it on my project.
deleted 3y ago
[deleted]
hot_gril 3y ago
Golang recently folded on the whole "no generics" decision, which throws a lot of dust into the air. Personally I'm waiting for them to add exceptions and async/await.
- eurleif 3y ago
  What would be the point of async/await when goroutines are already n:m green threads?
  - hot_gril 3y ago
    More familiar and convenient syntax
    - eurleif 3y ago
      `await f()` is more convenient than simply `f()`? I don't get it.
      - hot_gril 3y ago
        I don't want to have to make a channel every time for something so simple. Also, was Googling how you execute two things at once then wait on both in Golang, and https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_in_golang/ https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_... came up. This is honestly how I judge ease of use, how simple are answers to simple questions. The agreed-upon response was to use a library.
        eurleif 3y ago
        Channels and `async/await` are orthogonal. Channels are a way of communicating and coordinating between concurrent tasks; `async/await` are an alternative to blocking function calls (or an alternative form of blocking function calls, perhaps). There are implementations of channels for environments with `async/await`, where you would use syntax like `value = await channel.receive()`. What you may be getting at is that in an environment like Node.js, where everything runs in a single OS thread and there is no parallelism, there's a reduced need for coordination features like channels (or mutexes), because it's safe to mutate shared memory. But that too is orthogonal to `async/await`: the Python library gevent, for example, uses ordinary blocking function calls while running concurrent code in a single OS thread, making it safe to mutate shared memory; and conversely, C# allows `async/await` to be executed across multiple OS threads, making it unsafe to mutate shared memory.
georgespencer 3y ago
> Why do so many go devs feel the need to make statements like this This is a common conceit when writing for the sort of audience who might, for example, nitpick something as utterly uncontroversial as an author's disclaimer acknowledging common criticisms of a language they enjoy working with. tl;dr: Literally because of people like you :)
mikepurvis 3y ago
They've found their lanes now, but I think there's still a lot a historical baggage in the discourse from back when they were much closer together— Go thought it was competing with C++ rather than Python, and Rust originally had a much bigger runtime before no_std.
justincredible 3y ago
[dead]

chrsig 3y ago

You're just experiencing time passing on the internet. Some discussions spring eternal, because there's a constant stream of people having it for the first time.

georgespencer 3y ago
Obligatory link to Eternal September: https://en.wikipedia.org/wiki/Eternal_September https://en.wikipedia.org/wiki/Eternal_September

lagniappe 3y ago

I think it is to pre-emptively dismiss inevitable common trope criticisms made about Go. I don't think they truly believe this, it's just the common pattern of speaking in intellectually adversarial discussions in 2020+. - Acknowledge the common criticism - Defeat it with appropriate common retort, or make a small concession - Proceed with the meat of the argument with your most common opponent "disarmed"

zer00eyz 3y ago
>> it's just the common pattern of speaking in intellectually adversarial discussions in 2020+. Is it? Because I dont see JS or python apologists? Did I miss a corresponding lament about rust compile times in the article?
- mikepurvis 3y ago
  Ehh, those communities have their equivalent issues. At least for Python it's some combination of: I know Py3 was a nightmare and packaging in general is a dumpster fire, testing is a constellation of incompatible tools and practices, MyPy and progressive typing is an embarrassing half-baked mess, and deployment is only really possible when you bundle an entire system image into a container— but hey, developer productivity right?
- lalskii 3y ago
  [flagged]
- hot_gril 3y ago
  Mention how NodeJS has simple package management while Python doesn't, you'll find the Python apologists explaining why somehow it was an impossible task for Python to do packages right for legacy reasons, even though they got to force a whole breaking 2->3 version change. Also bring up the GIL, and you'll be told how Python is implementation-agnostic.
  - majoe 3y ago
    Packaging is indeed a weakness of Python, but to be fair, that Python packages are frequently wrapping C, C++ or Fortran code makes packaging a lot harder compared to nodejs.
    - hot_gril 3y ago
      There are NodeJS packages wrapping C code too. Probably less common than in Python, but that's not really a reason Python packages are so annoying.
neonsunset 3y ago
The sad thing is Go doesn’t need help - it won. It reached critical point where no matter how shitty it is in practice, it will be worked around and made work because engineers have no other choice - that’s what companies impose on them. Like with Python and ML. The optimal amount of bullying towards Go and its proponents is always “more”.

deleted 3y ago

[deleted]

okhugres 3y ago

It’s frustration at having to learn more than one programming language. At this time, due to the social integration of technology the number of people who interact with development has far out paced the number of people who enjoy development. > they are much more complimentary If you hate writing code but do it for your job, then you are going to really hate writing code in two different languages with their own syntax and paradigms. Also, nearly all programming language projects want to be the “everything language” so essentially any language is a fine choice and what it really comes down to is the people who enjoy the work develop “tastes” and “preferences” that they treat as dogma when defending their language of choice.

lagniappe 3y ago
> It’s frustration at having to learn more than one programming language. Imagine bob ross with only one color could still make something magnificent, but what could he do with two colors? You can't have Burnt Umber without some Phthalo Green..
- zer00eyz 3y ago
  > Imagine bob ross with only one color could still make something magnificent, but what could he do with two colors? https://www.youtube.com/watch?v=I-ousb8-SD0 https://www.youtube.com/watch?v=I-ousb8-SD0
- okhugres 3y ago
  Due the concept of Turing completeness I’d argue it’s more of deciding which paint brand to use, or if you must, I suppose you could liken it to the distinction between choosing oils or acrylics.
  - Jtsummers 3y ago
    You don't actually understand Turing completeness if that's your takeaway. Turing completeness is about computational equivalence. That, fundamentally, any Turing complete language can perform the same classes of computations as any other. It says nothing about substitutability of one language for another within any other context.

lumost 3y ago

Having worked in many languages including Go and Rust, I commonly see the following. 1. Team uses some interpreted language. This language is fine for most of their work, but causes performance problems and/or the team needs to do something performance sensitive. 2. Someone on the team proposes Go, often because it solves the performance problem - and is very simple to use. This proposal invites suggestions from the organizations programming language experts leading to "let's use lang X" suggestions. Often these suggestions have recommendations based on advanced programming language features such as high-order types, functional paradigms etc. As Rust has been somewhat popular for backend services, you will find many suggestions of "let's use Rust." These discussions can often be less than civil. As I've aged - I've moved closer to the advanced language features camp - but I'd doubt that this is actually beneficial for productivity. It took me 3 attempts to learn the language and 5 years for Rust to feel productive - now it's my preferred language for side projects. Go took less than a day to pick up.

mikepurvis 3y ago
I don't know if it's really still a fair trope at this point, but the argument made is that Go was specifically designed to be the best of Google's three main languages at the time— C++, Java, and Python. It was made to be quick to learn, hard to mess up, and easy to read/review. It specifically includes things like the build tool and formatter because those are long-running pain points in large scale development. Rust, on the other hand, is a borderline research language that was built to support Servo, a web browser backend— literally among the hairiest of sofware engineering problems in existence. It gives you a lot of "safety" but at the cost of having to consider issues that most developers never think about. This is not to say that Go is for dumb programmers and Rust is for smart ones or anything of that sort— just that despite years of evolution, both carry the DNA of their inception, and it shows.
- lumost 3y ago
  This is exactly so. At the edge, the go community will debate whether the language should be used for a project at all. Whereas the rust community will ship something that only kinda sorta works - or takes performance above all as the primary motivator. As a very experienced engineer, I like the idea of Rust being a go to for all problems. 10 years ago - I would have hated its complexity and cursed the TL who forced it on my project.

deleted 3y ago

[deleted]

hot_gril 3y ago

Golang recently folded on the whole "no generics" decision, which throws a lot of dust into the air. Personally I'm waiting for them to add exceptions and async/await.

eurleif 3y ago
What would be the point of async/await when goroutines are already n:m green threads?
- hot_gril 3y ago
  More familiar and convenient syntax
  - eurleif 3y ago
    `await f()` is more convenient than simply `f()`? I don't get it.
    - hot_gril 3y ago
      I don't want to have to make a channel every time for something so simple. Also, was Googling how you execute two things at once then wait on both in Golang, and https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_in_golang/ https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_... came up. This is honestly how I judge ease of use, how simple are answers to simple questions. The agreed-upon response was to use a library.
      - eurleif 3y ago
        Channels and `async/await` are orthogonal. Channels are a way of communicating and coordinating between concurrent tasks; `async/await` are an alternative to blocking function calls (or an alternative form of blocking function calls, perhaps). There are implementations of channels for environments with `async/await`, where you would use syntax like `value = await channel.receive()`. What you may be getting at is that in an environment like Node.js, where everything runs in a single OS thread and there is no parallelism, there's a reduced need for coordination features like channels (or mutexes), because it's safe to mutate shared memory. But that too is orthogonal to `async/await`: the Python library gevent, for example, uses ordinary blocking function calls while running concurrent code in a single OS thread, making it safe to mutate shared memory; and conversely, C# allows `async/await` to be executed across multiple OS threads, making it unsafe to mutate shared memory.

georgespencer 3y ago

> Why do so many go devs feel the need to make statements like this This is a common conceit when writing for the sort of audience who might, for example, nitpick something as utterly uncontroversial as an author's disclaimer acknowledging common criticisms of a language they enjoy working with. tl;dr: Literally because of people like you :)

mikepurvis 3y ago

They've found their lanes now, but I think there's still a lot a historical baggage in the discourse from back when they were much closer together— Go thought it was competing with C++ rather than Python, and Rust originally had a much bigger runtime before no_std.

justincredible 3y ago

[dead]