5 ms·

Personally their handling of versioning, generics and ESPECIALLY monotonic time (in all 3 cases, seemingly treating everyone raising concerns about the lack of

Personally their handling of versioning, generics and ESPECIALLY monotonic time (in all 3 cases, seemingly treating everyone raising concerns about the lack of a good solution as if they were cranks and/or saying fix it yourself) definitely soured me on Go and I would never choose it for a project or choose to work for a company that uses it as language #1 or language #2. It just left a bad taste in my mouth to see the needs and expertise of actual customers ignored by the Go team that way since the people in charge happened to be deploying in environments (i.e. Google) where those problems weren't 'real' problems Undeniable that people have built and shipped incredible software with it, though.

hnarn 3y ago
> the needs and expertise of actual customers What is an ”actual customer” in the context of the Go programming language?
- kevingadd 3y ago
  Anyone who's run an open source project is used to getting feature requests or complaints from groups like: * people who are merely interested but have no plans to use your project * people with strong opinions not backed by actual experience * people with a specific interest (like a new API or feature) who want to integrate it into as many projects as possible From a naive perspective, it makes sense to treat a request like 'we need monotonic time' as something that doesn't necessarily have any merit. The Go team are very experienced and opinionated, and it seems like it was a request that ran against their own instincts. The design complication probably was distasteful as well. The problem is, the only reason they never needed monotonic time in the past was that many of them spent all their time working in special environments that didn't need it (Google doesn't do leap seconds). In practice other people shipping software in the wider world do need it, and that's why they were asking for it. Their expertise was loudly disregarded even though the requests came with justification and problem scenarios.
  - FridgeSeal 3y ago
    For anyone not familiar with the monotonic time issue, the implementation was found to be incorrect, and the go devs basically closed it and went “just use google smear time like we do lol, not an issue, bye”. It did eventually get fixed I believe, but it was a shitty way of handling it.
    - masklinn 3y ago
      Even the "fix" is... ugh: instead of exposing monotonic time, time.Time contains both a wallclock time and an optional monotonic time, and operations update and use "the right one(s)". Also it's not that the implementation was incorrect, it's that Go simply didn't provide access to monotonic time in any way. It had that feature internally, just gave no way to access it (hence https://github.com/golang/go/issues/16658 https://github.com/golang/go/issues/16658).
    - tubthumper8 3y ago
      For reference, the GitHub thread is: https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914
- deleted 3y ago
  [deleted]
Groxx 3y ago
Package management is a very blatant entry for this list too.
- okanat 3y ago
  Backend people use Go in my company. They do great things with it. It works well enough when the interface between a Go program and another one is a socket kind of thing. But we also have a couple system utilities for embedded computers written in Go. I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and set a bunch of environment variables for private repos. Then there is CGO stuff like reading comments as code interfaces. Those things are incredible waste of time of the embedded developers and it makes harder for no reason to onboard people. Go generally spits out cryptic errors when building private repos like those. I always wanted and still want to create a wrapper that lauches a container, makes whatever "broken" configuration that makes Go compiler happy, figures out file permissions and runs the compiler. The wrapper should be the only go executable in my host system and each repo should come with a config file for it.
  - starttoaster 3y ago
    > I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and Just curious.. But why would you disable ssh-based git authentication? It's significantly more convenient when interacting with private repositories than supplying a username and password to https git endpoints. > set a bunch of environment variables for private repos. Set up a private Go module proxy. Use something like Athens. The module proxy can handle authentication to your private module repositories itself, then you just add a line in your personal bashrc that specifies your proxy. In general I don't have complaints with the things you take issue with so I'll digress on those.
    - shakow 3y ago
      > But why would you disable ssh-based git authentication? Ask the Go developers. AFAIK the only package manager where I have to change my global git configuration to make it work. Even the venerable CPAN and tlmgr behave better. https://stackoverflow.com/questions/27500861/whats-the-proper-way-to-go-get-a-private-repository https://stackoverflow.com/questions/27500861/whats-the-prope...
pa7ch 3y ago
I mostly loved what they did with with modules/package mgmt. I think SIV was a mistake but modules was miles better then the previous projects even with SIV. Some people seemed to take it very personally that the Go team didn't adopt their prior solution but idk why they expected the go team to use their package manager. I think the SAT style package manager proposed would have created a lot more usability problems for developers and would have been much harder to maintain.
- Groxx 3y ago
  They took it personally because Go led the community and those project leaders on for years that it would be looking, learning, and communicating... And then dropped the module spec and implementation and mandated it all in about two days. With no warning or feedback rounds or really any listening at all, just "here it is, we're done", out of nowhere. They have every right to be personally insulted by that.
  - kitd 3y ago
    2 days? ISTR discussions going on for at least 6 months comparing dep with what the 'official' one would do.
starttoaster 3y ago
> It just left a bad taste in my mouth to see the needs and expertise of actual customers ignored by the Go team that way since the people in charge happened to be deploying in environments (i.e. Google) where those problems weren't 'real' problems I feel for this, but only to an extent. It's hard to work in any service industry and retain any notion of, "the customer intelligently knows what they want," as a part of your personal beliefs. At the end of the day, you had an idea for a product, and you have to trust your gut on that product's direction, which is going to make some group of people feel a little unheard.

hnarn 3y ago

> the needs and expertise of actual customers What is an ”actual customer” in the context of the Go programming language?

kevingadd 3y ago
Anyone who's run an open source project is used to getting feature requests or complaints from groups like: * people who are merely interested but have no plans to use your project * people with strong opinions not backed by actual experience * people with a specific interest (like a new API or feature) who want to integrate it into as many projects as possible From a naive perspective, it makes sense to treat a request like 'we need monotonic time' as something that doesn't necessarily have any merit. The Go team are very experienced and opinionated, and it seems like it was a request that ran against their own instincts. The design complication probably was distasteful as well. The problem is, the only reason they never needed monotonic time in the past was that many of them spent all their time working in special environments that didn't need it (Google doesn't do leap seconds). In practice other people shipping software in the wider world do need it, and that's why they were asking for it. Their expertise was loudly disregarded even though the requests came with justification and problem scenarios.
- FridgeSeal 3y ago
  For anyone not familiar with the monotonic time issue, the implementation was found to be incorrect, and the go devs basically closed it and went “just use google smear time like we do lol, not an issue, bye”. It did eventually get fixed I believe, but it was a shitty way of handling it.
  - masklinn 3y ago
    Even the "fix" is... ugh: instead of exposing monotonic time, time.Time contains both a wallclock time and an optional monotonic time, and operations update and use "the right one(s)". Also it's not that the implementation was incorrect, it's that Go simply didn't provide access to monotonic time in any way. It had that feature internally, just gave no way to access it (hence https://github.com/golang/go/issues/16658 https://github.com/golang/go/issues/16658).
  - tubthumper8 3y ago
    For reference, the GitHub thread is: https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914
deleted 3y ago
[deleted]

Groxx 3y ago

Package management is a very blatant entry for this list too.

okanat 3y ago
Backend people use Go in my company. They do great things with it. It works well enough when the interface between a Go program and another one is a socket kind of thing. But we also have a couple system utilities for embedded computers written in Go. I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and set a bunch of environment variables for private repos. Then there is CGO stuff like reading comments as code interfaces. Those things are incredible waste of time of the embedded developers and it makes harder for no reason to onboard people. Go generally spits out cryptic errors when building private repos like those. I always wanted and still want to create a wrapper that lauches a container, makes whatever "broken" configuration that makes Go compiler happy, figures out file permissions and runs the compiler. The wrapper should be the only go executable in my host system and each repo should come with a config file for it.
- starttoaster 3y ago
  > I still get frustrated that I have to go and break my git configuration to enable ssh-based git clones and Just curious.. But why would you disable ssh-based git authentication? It's significantly more convenient when interacting with private repositories than supplying a username and password to https git endpoints. > set a bunch of environment variables for private repos. Set up a private Go module proxy. Use something like Athens. The module proxy can handle authentication to your private module repositories itself, then you just add a line in your personal bashrc that specifies your proxy. In general I don't have complaints with the things you take issue with so I'll digress on those.
  - shakow 3y ago
    > But why would you disable ssh-based git authentication? Ask the Go developers. AFAIK the only package manager where I have to change my global git configuration to make it work. Even the venerable CPAN and tlmgr behave better. https://stackoverflow.com/questions/27500861/whats-the-proper-way-to-go-get-a-private-repository https://stackoverflow.com/questions/27500861/whats-the-prope...

pa7ch 3y ago

I mostly loved what they did with with modules/package mgmt. I think SIV was a mistake but modules was miles better then the previous projects even with SIV. Some people seemed to take it very personally that the Go team didn't adopt their prior solution but idk why they expected the go team to use their package manager. I think the SAT style package manager proposed would have created a lot more usability problems for developers and would have been much harder to maintain.

Groxx 3y ago
They took it personally because Go led the community and those project leaders on for years that it would be looking, learning, and communicating... And then dropped the module spec and implementation and mandated it all in about two days. With no warning or feedback rounds or really any listening at all, just "here it is, we're done", out of nowhere. They have every right to be personally insulted by that.
- kitd 3y ago
  2 days? ISTR discussions going on for at least 6 months comparing dep with what the 'official' one would do.

starttoaster 3y ago

> It just left a bad taste in my mouth to see the needs and expertise of actual customers ignored by the Go team that way since the people in charge happened to be deploying in environments (i.e. Google) where those problems weren't 'real' problems I feel for this, but only to an extent. It's hard to work in any service industry and retain any notion of, "the customer intelligently knows what they want," as a part of your personal beliefs. At the end of the day, you had an idea for a product, and you have to trust your gut on that product's direction, which is going to make some group of people feel a little unheard.