12 ms·

I really, really appreciate key people taking the time for retrospectives. It makes a huge difference to people now who want to make a real difference. But I'

by w10-1 3y ago

I really, really appreciate key people taking the time for retrospectives. It makes a huge difference to people now who want to make a real difference. But I'm not sure Rob Pike states clearly enough what they got right (IMO): they managed the forces on the project as well as the language, by: - Restricting the language to its target use: systems programming, not applications or data science or AI... - Defining the language and its principles clearly. This avoids eons of waste in implementing ambiguity and designing at cross-purposes. - Putting quality first: it's always cheaper for all concerned to fix problems before deploying, even if it's harder for the community or OS contributors or people waiting for new features. - Sharing the community. They maintained strict control over the language and release and core messaging, but they also allowed others to lead in many downstream aspects. Stated but under-appreciated is the degree to which Google itself didn't interfere. I suspect it's because Go actually served its objectives and is critical to Google. I wonder if that could be true today for a new project. It's interesting to compare Dart, which has zero uptake outside Flutter even though there are orders of magnitude more application code than systems code. Go was probably the key technology that migrated server-side software off Java bloatware to native containers. It dominates back-end infrastructure and underlies most of the web application infrastructure of the last 10 years. The benefit to Google and the community from that alternative has been huge. Somehow amidst all that growth, the team remained small and kept all its key players. Will that change?

zozbot234 3y ago
> Go was probably the key technology that migrated server-side software off Java bloatware to native containers Interesting point of view - Golang might be pithily described as "Java done right". That has little to do with "systems programming" per se but can be quite valuable in its own terms.
- grumpyprole 3y ago
  Java has a culture of over-engineering, to the point where even a logging library contains a string interpolator capable of executing remote code. Go successfully jettisoned this culture, even if the language itself repeated many of the same old mistakes that Java originally did.
  - dekhn 3y ago
    I asked Rob why he didn't like Java (Gosling was standing nearby) and he said "public static void main"
    - grumpyprole 3y ago
      Nice. My reply would have been something like: it combines the performance of Lisp with the productivity of C++. These days Java the language is much better though, thanks to Brian Goetz.
      - shakow 3y ago
        > it combines the performance of Lisp with the productivity of C++ Is that supposed to be a jab? Because IME SBCL Lisp is in the same ballpark as Go (albeit offering a fully interactive development environment), and C++ is far from being the worst choice when it comes down to productivity.
        grumpyprole 3y ago
        Hopefully you agree Lisp is more productive than C++? Lisp is however not quite fast or efficient enough to displace C++ completely, mainly because, like Java and Go, it has a garbage collector. C++ was very much the language in Java's crosshairs. Java made programming a bit safer, nulls and threads not withstanding, but was certainly not as productive as Lisp. Meanwhile Lisp evolved into Haskell and OCaml, two very productive languages which thankfully are inspiring everyone else to improve. Phil Wadler (from the original Haskell committee) has even been helping the Go team.
        pjmlp 3y ago
        Common Lisp, is also among the GC based languages that offer mechanisms to do GC free allocations and has value types. The only reason is the AI winter, and companies moving away from Lisp.
        shakow 3y ago
- sigzero 3y ago
  No, not even "pithily" is it "Java done right".
- unscaled 3y ago
  From looking at what the Go team had to say about Go in its earliest days, Go had very little to do with Java, and they weren't very concerned with fixing Java's issues. The "Bloated Abstractions" issue in Java is more of a cultural thing than an issue of the language. You could even say it's partially because early Java (especially before Java 1.5) was too much like Go! Java used to have the same philosophy around abstractions, and Sun/Oracle were pretty conservative about adding new language features. To compensate for lack of good language-level abstractions, Java developers used complicated techinques and design patterns, for example: 1. XML configuration, because there were no attributes. 2. Attributes because there were no generics and closures. 3. Observers/Visitors/Strategies/etc. because there weren't any closures. 4. Heavy Inheritance, because there was no delegation. 5. Complicated POJOs and beans, since Java didn't have properties or immutable records.
  - yencabulator 3y ago
    Many other software development cultures lived through similar limitations without evolving to the levels of abstraction astronaut achievement award of Java. No other language comes close to this: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
    - unscaled 3y ago
      Very true, and Go (or bash for that matter) are proofs that language limitations do not mandate complexity. Complexity is mandated by perceived need and culture. You can easily see how complexity would play out in Go by looking at Kubernetes. Most projects did not fall into the complexity trap, but there are many differences in form, functions and context: - Early Java projects before Java EE (like Applets and early GUI apps) did not have this level of complex abstraction. The code wasn't great (old Java APIs like StringBuffer and Date were often quite horrible), but it was simple. - Java started getting complex with J2EE. J2EE was strongly motivated by enterprise requirements for interoperability and dynamically configurable and interchangeable components. - Another source of complexity was the popularity of XML and the widespread belief (back in the early 2000s) that moving part or all of your business logic to XML was a good thing. - And then there was the design patterns obsessions, where design patterns transformed from being a common pattern observed in code into something that should be emulated. - Most of the early J2EE complexity is dead (EJBs, XML configuration, CORBA, SOAP), but many users don't want to give up component interoperability and powerful dynamic configuration. That's why Java frameworks like Spring, Java EE and even modern frameworks like Quarkus or Micronaut have all their annotations and implicitness. - Go was luckier(?) to be born in a different time and popularized in a different context. - There was no top-down enterprise-oriented backing for Go (even within Google, it was a bottom up project). - The Go compiler, runtime and libraries were fully open-source from day one, under a permissive license. Third party libraries were also almost universally open source. The existence of open source culture made concerns about vendor lock-in moot, and interchangeability was not a thing. - The XML hype died and there was a consensus that component wiring should be done in code. - Many of us got sober on design patterns. Peter Norvig's critique[1] gained traction outside of the LISP community and the anti-design pattern view became dominant within the dynamic language community as well, even in strongly OO languages like Ruby. This is the community that was feeding Go. - Most servers written in Go were just smaller in scope than the equivalent Java projects. This has many causes (less top-down big-rewrite enterprise projects, microservices gaining popularity, UI logic usually moving to front-end or mobile app). [1] http://norvig.com/design-patterns/ http://norvig.com/design-patterns/
- kaba0 3y ago
  More like java 1.2 sold in a worse package.
0cf8612b2e1e 3y ago
Not sure I would agree with the community leading aspect. It still feels like Google decides. My particular point would be versioning. At first Go refused to acknowledge the problem. Then, when there was finally growing community consensus, Go said forget everything else, now we are doing modules. I also recall the refusal to make montatomicly-increasing-time a public API until cloudflare had a daylight savings time outage.
- kevingadd 3y ago
  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.
scythe 3y ago
>Restricting the language to its target use: systems programming, not applications or data science or AI... The only Go I ever touched in industry was the backend of a web-app at Salesforce. I'm not sure this counts as "systems programming". https://engineering.salesforce.com/einstein-analytics-and-go-24e5aed2981f/ https://engineering.salesforce.com/einstein-analytics-and-go...
- WatchDog 3y ago
  Rob describes go as a language for writing server applications, and I think that is a much more applicable term than systems programming.
  - bb88 3y ago
    Drew DeVault called it an "internet" language back in 2021. And to that I more or less agree. Read footnote 1 for context. https://drewdevault.com/2021/04/02/Go-is-a-great-language.html https://drewdevault.com/2021/04/02/Go-is-a-great-language.ht...
    - cryptos 3y ago
      But then again the internet is everywhere now: desktop, servers, watches, washing machines, industrial systems, sensors ... So "internet language" is a somewhat pointless term.
      - iainmerrick 3y ago
        That term isn’t meant to include mobile apps, desktop apps, web apps (even though those all use the internet, of course). Nobody is using Go for any of those, as far as I know. So I think it is a useful term, and captures the things Go is good at surprisingly well.
        bb88 3y ago
        I actually kinda thought that Google should have made Go the default language for android. It could have been a compelling argument to the rest of the world as a reason to use it as a systems language. It's feels like they didn't want to dog food it outside of their servers, though.
liampulles 3y ago
I was a Java dev and love using Go now, but I have to say I'm not sure if many of my Ex-Java-Colleagues would like Go. Go is kind of odd in that even when it was new, it was kind of boring. I think a lot of people in the Java world (not least myself) enjoy trying to refactor a codebase for new Java features (e.g. streams, which are amazing). In the Go world, the enjoyment comes from trying to find the simplest, plainest abstractions.
- groestl 3y ago
  > it was kind of boring. As a Java dev, I love boring. That's why I picked Java. Boring means less outages. > find the simplest, plainest abstractions. Not sure I'd give that medal to Go.
  - techdragon 3y ago
    When did go get abstractions? (Only half joking) Isn’t the entire language designed explicitly to prevent programmers from building their own sophisticated abstractions that could confuse other programmers who don’t understand that other persons code… as I understand it, if you can read go and understand basic programming you should be competent with go, and if you know your algorithms you should be proficient. I hated old Java but the modern language isn’t as bad now some people have added some better syntax shortcuts the libraries are nearly twenty years more polished, and the IDE can nearly half write my code for me so the boilerplate and mind numbing aspect isn’t so bad… I loathe go because using it feels like programming with my hands tied behind my back trying on a keyboard with sandpaper keycaps, despite that, I didn’t bother “learning” go, I could just read it based on my Python/C/Basic/Java/C# experience instead of needing any extra learning.
    - zozbot234 3y ago
      K8s just so happens to be coded in Golang. A quick look at that overall codebase should be enough to disabuse people of this notion that Golang developers cannot possibly come up with confusing or overly sophisticated abstractions.
closeparen 3y ago
> Restricting the language to its target use: systems programming, not applications or data science or AI... Go is used extensively in server-side business applications. Arguably it shouldn't be, but it is.
- hnarn 3y ago
  Why shouldn’t it be?
  - eweise 3y ago
    Too low level and lacks the power to cleanly model the business domain.
    - closeparen 3y ago
      Go has pretty powerful composition, reuse, higher-order functions etc. for dealing with byte arrays and streams. Not so much for business domain entities.
    - dharmab 3y ago
      "Too low level" "lacks the power" - I don't understand what this means. What are things that are hard to do in Go business applications that other languages do better?
      - rowls66 3y ago
        Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.
        Cthulhu_ 3y ago
        Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.
the_duke 3y ago
> - Restricting the language to its target use: systems programming, not applications or data science or AI... Go has a GC and a very heavy runtime with green threads, leading to cumbersome/slow C interop. It certainly isn't viable as systems programming language , which is by design. That's an odd myth that has persisted ever since the language called itself as such in the beginning. They removed that wording years ago I think. It's primarily a competitor to Java et al, not to C or Rust, and you see that when looking at the domains it is primarily used in, although it tends to sit a bit lower on the stack due to the limited nature of the type system and the great support for concurrency.
- wredcoll 3y ago
  Man, arguments about the definition of "systems programming" are almost as much fun as the old "dynamic" vs "static" language wars.
  - kibwen 3y ago
    > the old "dynamic" vs "static" language wars. We used to argue about dynamic vs static languages. We still do, but we used to, too.
    - ysofunny 3y ago
      then there's this https://en.wikipedia.org/wiki/Dynamic_programming https://en.wikipedia.org/wiki/Dynamic_programming which has nothing to do with types nor variables but with algorithm optimization
      - jfoutz 3y ago
        The trick is to throw memory at it. if memoization helps, that’ll work without the memory hit!
    - klausnrooster 3y ago
      :) ...Mitch
sjwhevvvvvsj 3y ago
They gutted the key FOSS teams during the layoffs, the c-suite hates real FOSS, it doesn’t look good on Ruth’s spreadsheet. Of course, pretend FOSS like Android they strategically tolerate, but beyond that unless it results in an ad click it’s useless.
- LispSporks22 3y ago
  Who is Ruth?
  - vajrabum 3y ago
    Google CFO
    - sjwhevvvvvsj 3y ago
      Most employees think she’s the CEO to be fair.
jacquesm 3y ago
What they really got right in my opinion: show, don't tell and modesty.
munificent 3y ago
> It's interesting to compare Dart, which has zero uptake outside Flutter Caveat: I work on Dart. I don't see that that's a very damning critique of Dart. Every language needs libraries/frameworks to be suited for a domain. Flutter is a framework for writing client apps in Dart. Without Flutter, no matter how much you like Dart the language, you'd be spending a hell of a lot of time just figuring out how to get pixels on screen on Android and iOS. Few people have the desire or time for that. Anyone writing applications builds on a stack of libraries and frameworks. The only difference I see between Go and Dart with Flutter is that Go's domain libraries for networking, serialization, crypto and other stuff you need for servers are in the standard library. Dart has a bunch of basics in the built in libraries like collections and asynchrony, but the domain-specific stuff relies on external packages like Flutter. That's in large part because Dart has had a robust package management story from very early on: many "core" libraries written and maintained by the Dart team are still shipped using the package manager instead of being built-in libraries because it makes them much easier to evolve. I prefer that Flutter isn't baked into Dart's standard libraries, because UI frameworks tend to be shorter-lived than languages. Flutter is wonderful, but I wouldn't be surprised if twenty years from now something better comes along. When that happens, it will be easier for Dart users to adopt it and not use Flutter because Flutter isn't baked in.
- iainmerrick 3y ago
  I don’t disagree with all that but it seems tangential to the point being made, that people just aren’t using Dart except for Flutter apps. So compared to Go it’s very much a niche language (although maybe it’s a really big niche, I don’t know).
  - copx 3y ago
    One might as well say "People just aren't using Go except for server apps."
    - iainmerrick 3y ago
      Go is used for command-line tools too, e.g. esbuild. It's a question of whether the tail is wagging the dog. Flutter is more important than Dart, unless Dart finds a way to expand into another niche. I don't think any one Go framework is bigger than the language itself (even if you were to include the standard library networking utils as a framework).
pjmlp 3y ago
Where I stand, we keep enjoying Java and .NET bloatware, with powerful programming languages, thank you very much. Go is only used in DevOps scenarios where there is no way around it. The only place I advocate for it, is a C replacement, for the same role as Limbo in Inferno, or Oberon in 1992, not Java or .NET ecosystems.
kaba0 3y ago
> Go was probably the key technology that migrated server-side software off Java bloatware to native containers Bloatware? That’s already an uninformed and loaded term, and Google still has and writes more Java than Go, if I’m not mistaken.
- pjmlp 3y ago
  Java is so bad, and .NET as well, that now WASM startups are re-inventing application servers on top of Kubernetes + WASM. On one side the ecosystems get bashed, on the other, the same ones complaining get to re-invent them, badly.

by w10-1 3y ago

zozbot234 3y ago

> Go was probably the key technology that migrated server-side software off Java bloatware to native containers Interesting point of view - Golang might be pithily described as "Java done right". That has little to do with "systems programming" per se but can be quite valuable in its own terms.

grumpyprole 3y ago
Java has a culture of over-engineering, to the point where even a logging library contains a string interpolator capable of executing remote code. Go successfully jettisoned this culture, even if the language itself repeated many of the same old mistakes that Java originally did.
- dekhn 3y ago
  I asked Rob why he didn't like Java (Gosling was standing nearby) and he said "public static void main"
  - grumpyprole 3y ago
    Nice. My reply would have been something like: it combines the performance of Lisp with the productivity of C++. These days Java the language is much better though, thanks to Brian Goetz.
    - shakow 3y ago
      > it combines the performance of Lisp with the productivity of C++ Is that supposed to be a jab? Because IME SBCL Lisp is in the same ballpark as Go (albeit offering a fully interactive development environment), and C++ is far from being the worst choice when it comes down to productivity.
      - grumpyprole 3y ago
        Hopefully you agree Lisp is more productive than C++? Lisp is however not quite fast or efficient enough to displace C++ completely, mainly because, like Java and Go, it has a garbage collector. C++ was very much the language in Java's crosshairs. Java made programming a bit safer, nulls and threads not withstanding, but was certainly not as productive as Lisp. Meanwhile Lisp evolved into Haskell and OCaml, two very productive languages which thankfully are inspiring everyone else to improve. Phil Wadler (from the original Haskell committee) has even been helping the Go team.
        pjmlp 3y ago
        Common Lisp, is also among the GC based languages that offer mechanisms to do GC free allocations and has value types. The only reason is the AI winter, and companies moving away from Lisp.
        shakow 3y ago
sigzero 3y ago
No, not even "pithily" is it "Java done right".
unscaled 3y ago
From looking at what the Go team had to say about Go in its earliest days, Go had very little to do with Java, and they weren't very concerned with fixing Java's issues. The "Bloated Abstractions" issue in Java is more of a cultural thing than an issue of the language. You could even say it's partially because early Java (especially before Java 1.5) was too much like Go! Java used to have the same philosophy around abstractions, and Sun/Oracle were pretty conservative about adding new language features. To compensate for lack of good language-level abstractions, Java developers used complicated techinques and design patterns, for example: 1. XML configuration, because there were no attributes. 2. Attributes because there were no generics and closures. 3. Observers/Visitors/Strategies/etc. because there weren't any closures. 4. Heavy Inheritance, because there was no delegation. 5. Complicated POJOs and beans, since Java didn't have properties or immutable records.
- yencabulator 3y ago
  Many other software development cultures lived through similar limitations without evolving to the levels of abstraction astronaut achievement award of Java. No other language comes close to this: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
  - unscaled 3y ago
    Very true, and Go (or bash for that matter) are proofs that language limitations do not mandate complexity. Complexity is mandated by perceived need and culture. You can easily see how complexity would play out in Go by looking at Kubernetes. Most projects did not fall into the complexity trap, but there are many differences in form, functions and context: - Early Java projects before Java EE (like Applets and early GUI apps) did not have this level of complex abstraction. The code wasn't great (old Java APIs like StringBuffer and Date were often quite horrible), but it was simple. - Java started getting complex with J2EE. J2EE was strongly motivated by enterprise requirements for interoperability and dynamically configurable and interchangeable components. - Another source of complexity was the popularity of XML and the widespread belief (back in the early 2000s) that moving part or all of your business logic to XML was a good thing. - And then there was the design patterns obsessions, where design patterns transformed from being a common pattern observed in code into something that should be emulated. - Most of the early J2EE complexity is dead (EJBs, XML configuration, CORBA, SOAP), but many users don't want to give up component interoperability and powerful dynamic configuration. That's why Java frameworks like Spring, Java EE and even modern frameworks like Quarkus or Micronaut have all their annotations and implicitness. - Go was luckier(?) to be born in a different time and popularized in a different context. - There was no top-down enterprise-oriented backing for Go (even within Google, it was a bottom up project). - The Go compiler, runtime and libraries were fully open-source from day one, under a permissive license. Third party libraries were also almost universally open source. The existence of open source culture made concerns about vendor lock-in moot, and interchangeability was not a thing. - The XML hype died and there was a consensus that component wiring should be done in code. - Many of us got sober on design patterns. Peter Norvig's critique[1] gained traction outside of the LISP community and the anti-design pattern view became dominant within the dynamic language community as well, even in strongly OO languages like Ruby. This is the community that was feeding Go. - Most servers written in Go were just smaller in scope than the equivalent Java projects. This has many causes (less top-down big-rewrite enterprise projects, microservices gaining popularity, UI logic usually moving to front-end or mobile app). [1] http://norvig.com/design-patterns/ http://norvig.com/design-patterns/
kaba0 3y ago
More like java 1.2 sold in a worse package.

0cf8612b2e1e 3y ago

Not sure I would agree with the community leading aspect. It still feels like Google decides. My particular point would be versioning. At first Go refused to acknowledge the problem. Then, when there was finally growing community consensus, Go said forget everything else, now we are doing modules. I also recall the refusal to make montatomicly-increasing-time a public API until cloudflare had a daylight savings time outage.

kevingadd 3y ago
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.

scythe 3y ago

>Restricting the language to its target use: systems programming, not applications or data science or AI... The only Go I ever touched in industry was the backend of a web-app at Salesforce. I'm not sure this counts as "systems programming". https://engineering.salesforce.com/einstein-analytics-and-go-24e5aed2981f/ https://engineering.salesforce.com/einstein-analytics-and-go...

WatchDog 3y ago
Rob describes go as a language for writing server applications, and I think that is a much more applicable term than systems programming.
- bb88 3y ago
  Drew DeVault called it an "internet" language back in 2021. And to that I more or less agree. Read footnote 1 for context. https://drewdevault.com/2021/04/02/Go-is-a-great-language.html https://drewdevault.com/2021/04/02/Go-is-a-great-language.ht...
  - cryptos 3y ago
    But then again the internet is everywhere now: desktop, servers, watches, washing machines, industrial systems, sensors ... So "internet language" is a somewhat pointless term.
    - iainmerrick 3y ago
      That term isn’t meant to include mobile apps, desktop apps, web apps (even though those all use the internet, of course). Nobody is using Go for any of those, as far as I know. So I think it is a useful term, and captures the things Go is good at surprisingly well.
      - bb88 3y ago
        I actually kinda thought that Google should have made Go the default language for android. It could have been a compelling argument to the rest of the world as a reason to use it as a systems language. It's feels like they didn't want to dog food it outside of their servers, though.

liampulles 3y ago

I was a Java dev and love using Go now, but I have to say I'm not sure if many of my Ex-Java-Colleagues would like Go. Go is kind of odd in that even when it was new, it was kind of boring. I think a lot of people in the Java world (not least myself) enjoy trying to refactor a codebase for new Java features (e.g. streams, which are amazing). In the Go world, the enjoyment comes from trying to find the simplest, plainest abstractions.

groestl 3y ago
> it was kind of boring. As a Java dev, I love boring. That's why I picked Java. Boring means less outages. > find the simplest, plainest abstractions. Not sure I'd give that medal to Go.
- techdragon 3y ago
  When did go get abstractions? (Only half joking) Isn’t the entire language designed explicitly to prevent programmers from building their own sophisticated abstractions that could confuse other programmers who don’t understand that other persons code… as I understand it, if you can read go and understand basic programming you should be competent with go, and if you know your algorithms you should be proficient. I hated old Java but the modern language isn’t as bad now some people have added some better syntax shortcuts the libraries are nearly twenty years more polished, and the IDE can nearly half write my code for me so the boilerplate and mind numbing aspect isn’t so bad… I loathe go because using it feels like programming with my hands tied behind my back trying on a keyboard with sandpaper keycaps, despite that, I didn’t bother “learning” go, I could just read it based on my Python/C/Basic/Java/C# experience instead of needing any extra learning.
  - zozbot234 3y ago
    K8s just so happens to be coded in Golang. A quick look at that overall codebase should be enough to disabuse people of this notion that Golang developers cannot possibly come up with confusing or overly sophisticated abstractions.

closeparen 3y ago

> Restricting the language to its target use: systems programming, not applications or data science or AI... Go is used extensively in server-side business applications. Arguably it shouldn't be, but it is.

hnarn 3y ago
Why shouldn’t it be?
- eweise 3y ago
  Too low level and lacks the power to cleanly model the business domain.
  - closeparen 3y ago
    Go has pretty powerful composition, reuse, higher-order functions etc. for dealing with byte arrays and streams. Not so much for business domain entities.
  - dharmab 3y ago
    "Too low level" "lacks the power" - I don't understand what this means. What are things that are hard to do in Go business applications that other languages do better?
    - rowls66 3y ago
      Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.
      - Cthulhu_ 3y ago
        Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.

the_duke 3y ago

> - Restricting the language to its target use: systems programming, not applications or data science or AI... Go has a GC and a very heavy runtime with green threads, leading to cumbersome/slow C interop. It certainly isn't viable as systems programming language , which is by design. That's an odd myth that has persisted ever since the language called itself as such in the beginning. They removed that wording years ago I think. It's primarily a competitor to Java et al, not to C or Rust, and you see that when looking at the domains it is primarily used in, although it tends to sit a bit lower on the stack due to the limited nature of the type system and the great support for concurrency.

wredcoll 3y ago
Man, arguments about the definition of "systems programming" are almost as much fun as the old "dynamic" vs "static" language wars.
- kibwen 3y ago
  > the old "dynamic" vs "static" language wars. We used to argue about dynamic vs static languages. We still do, but we used to, too.
  - ysofunny 3y ago
    then there's this https://en.wikipedia.org/wiki/Dynamic_programming https://en.wikipedia.org/wiki/Dynamic_programming which has nothing to do with types nor variables but with algorithm optimization
    - jfoutz 3y ago
      The trick is to throw memory at it. if memoization helps, that’ll work without the memory hit!
  - klausnrooster 3y ago
    :) ...Mitch

sjwhevvvvvsj 3y ago

They gutted the key FOSS teams during the layoffs, the c-suite hates real FOSS, it doesn’t look good on Ruth’s spreadsheet. Of course, pretend FOSS like Android they strategically tolerate, but beyond that unless it results in an ad click it’s useless.

LispSporks22 3y ago
Who is Ruth?
- vajrabum 3y ago
  Google CFO
  - sjwhevvvvvsj 3y ago
    Most employees think she’s the CEO to be fair.

jacquesm 3y ago

What they really got right in my opinion: show, don't tell and modesty.

munificent 3y ago

> It's interesting to compare Dart, which has zero uptake outside Flutter Caveat: I work on Dart. I don't see that that's a very damning critique of Dart. Every language needs libraries/frameworks to be suited for a domain. Flutter is a framework for writing client apps in Dart. Without Flutter, no matter how much you like Dart the language, you'd be spending a hell of a lot of time just figuring out how to get pixels on screen on Android and iOS. Few people have the desire or time for that. Anyone writing applications builds on a stack of libraries and frameworks. The only difference I see between Go and Dart with Flutter is that Go's domain libraries for networking, serialization, crypto and other stuff you need for servers are in the standard library. Dart has a bunch of basics in the built in libraries like collections and asynchrony, but the domain-specific stuff relies on external packages like Flutter. That's in large part because Dart has had a robust package management story from very early on: many "core" libraries written and maintained by the Dart team are still shipped using the package manager instead of being built-in libraries because it makes them much easier to evolve. I prefer that Flutter isn't baked into Dart's standard libraries, because UI frameworks tend to be shorter-lived than languages. Flutter is wonderful, but I wouldn't be surprised if twenty years from now something better comes along. When that happens, it will be easier for Dart users to adopt it and not use Flutter because Flutter isn't baked in.

iainmerrick 3y ago
I don’t disagree with all that but it seems tangential to the point being made, that people just aren’t using Dart except for Flutter apps. So compared to Go it’s very much a niche language (although maybe it’s a really big niche, I don’t know).
- copx 3y ago
  One might as well say "People just aren't using Go except for server apps."
  - iainmerrick 3y ago
    Go is used for command-line tools too, e.g. esbuild. It's a question of whether the tail is wagging the dog. Flutter is more important than Dart, unless Dart finds a way to expand into another niche. I don't think any one Go framework is bigger than the language itself (even if you were to include the standard library networking utils as a framework).

pjmlp 3y ago

Where I stand, we keep enjoying Java and .NET bloatware, with powerful programming languages, thank you very much. Go is only used in DevOps scenarios where there is no way around it. The only place I advocate for it, is a C replacement, for the same role as Limbo in Inferno, or Oberon in 1992, not Java or .NET ecosystems.

kaba0 3y ago

> Go was probably the key technology that migrated server-side software off Java bloatware to native containers Bloatware? That’s already an uninformed and loaded term, and Google still has and writes more Java than Go, if I’m not mistaken.

pjmlp 3y ago
Java is so bad, and .NET as well, that now WASM startups are re-inventing application servers on top of Kubernetes + WASM. On one side the ecosystems get bashed, on the other, the same ones complaining get to re-invent them, badly.