Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.18

go.dev

Post reply on HN
Print view View original

601–610 of 614 posts

Re: Go 1.18

#601

Post by oxplot »

azth wrote: post #594
oxplot wrote: post #138

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only…

> in service of large distributed teams and long term maintainability. Except those didn't really manifest. The opposite was actually true, golang is worse for large teams and maintainability compared to languages like Java and C#. > Go authors avoided complicating the language, runtime, and compiler Which ended up complicating end users' code. There is no way around it, complexity has to exist in one space or the ot…

> Except those didn't really manifest.

And your proof is?

> golang is worse for large teams and maintainability compared to languages like Java and C#

How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions.

> Which ended up complicating end users' code.

Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it.

> ended up with a weak language

Looks strong to me!

Re: Go 1.18

#602

Post by azth »

oxplot wrote: post #601
azth wrote: post #594

Earlier quoted context omitted.

> in service of large distributed teams and long term maintainability. Except those didn't really manifest. The opposite was actually true, golang is worse for large teams and maintainability compared to languages like Java and C#. > Go authors avoided complicating the language, runtime, and compiler Which ended up complicating end users' code. There is no way around it, complexity has to exist in one space or the ot…

> Except those didn't really manifest. And your proof is? > golang is worse for large teams and maintainability compared to languages like Java and C# How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions. > Which ended up complicating end users' code. Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it. > end…

> And your proof is?

Years of experience working on several large golang projects, and seeing what sorts of issues and bugs programmer face when working on them. Things that they wouldn't have encountered in Java or C# for instance.

Furthermore, the burden of proof is on the golang authors making the claim. I have not seen any rigorous studies that underly the design decisions they claim will result in more maintainable large code bases.

> How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions.

That's despite of golang, not because of it. C is quite bad for large scale projects, yet Linux has a lot of contributions because it is a large project (a tautology of sort).

> Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it.

A biased survey that mostly pro golang people would take anyway.

> Looks strong to me!

See first point.

Re: Go 1.18

#603

Post by oxplot »

azth wrote: post #602
oxplot wrote: post #601

Earlier quoted context omitted.

> Except those didn't really manifest. And your proof is? > golang is worse for large teams and maintainability compared to languages like Java and C# How do you figure that? I see large projects like Kubernetes and Docker thriving with contributions. > Which ended up complicating end users' code. Some users, sure. Majority of projects, as evident in Go annual surveys clearly shows they are doing OK without it. > end…

> And your proof is? Years of experience working on several large golang projects, and seeing what sorts of issues and bugs programmer face when working on them. Things that they wouldn't have encountered in Java or C# for instance. Furthermore, the burden of proof is on the golang authors making the claim. I have not seen any rigorous studies that underly the design decisions they claim will result in more maintaina…

> A biased survey that mostly pro golang people would take anyway

ok - I was gonna run some BigQuery and get you stats - but that comment makes it clear as day that you're not interested in "proof".

Thanks for saving me time and good luck to you and your Java/C#.

Re: Go 1.18

#604

Post by ParetoOptimal »

zemo wrote: post #227
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

people hate Go because Go is unapologetically designed from the framing of programmers being members of a labor class having differing levels of expertise. It's not the design itself; it's the design goals themselves that people are opposed to. This Rob Pike quote gets bandied around in these discussions: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, f…

> I have never met a Go programmer that is bothered by the existence of Haskell. I have met many, many Haskell programmers that are bothered by the existence of Go. Ask yourself why that is.

This is easy.

Go programmers are more likely to claim language choice doesn't impact software much.

Haskell programmers are more likely to claim language choice does matter a large amount.

That means there's not as much reason for Go programmers to criticize other languages because they don't see it as mattering much.

I think "language doesn't matter" is a hypocritical position that people make in bad faith though.

That said, Go programmers definitely criticize other languages including Haskell for not being inferior to Go's brand of "simplicity".

Re: Go 1.18

#605

Post by ParetoOptimal »

zemo wrote: post #227
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

people hate Go because Go is unapologetically designed from the framing of programmers being members of a labor class having differing levels of expertise. It's not the design itself; it's the design goals themselves that people are opposed to. This Rob Pike quote gets bandied around in these discussions: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, f…

> This leaves us with the final problem: why can't people acknowledge that different people have different goals, and that those people's goals are just as legitimate as their own? Why are other people's goals threatening?

Because swaths of code written in a language where it's easier to make mistakes affects all parties and entrenches said language.

Imagine a book on programming an unreadable language like Befunge was given out to low income schools across the world, those people ended up organizing, and by sheer number and force cranked out software the industry depended upon.

Is it unethical to see the downside, point it out, but appreciate what was accomplished?

I think about the dilemma of socioeconomics preventing language choice from being a consideration and language mattering for writing better software a lot though.

Re: Go 1.18

#606

Post by keybored »

philosopher1234 wrote: post #278
keybored wrote: post #107

Earlier quoted context omitted.

This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fix…

You may think these reasons are negative or depraved, but they are none the less legitimate reasons that motivate real people. Why should we pretend they can't possibly be a factor?

I was condemning your bad faith argumentation, not the reasons given. Maybe you misunderstood.

Re: Go 1.18

#607

Post by Zababa »

int_19h wrote: post #376
Zababa wrote: post #266

Earlier quoted context omitted.

> Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.) It's not only your personal observation (though I would remove the "purely" from "purely functional languages). A good indication of that: on the Go 2020 survey, the 6 most popular responses to "Which critical language features do you need that are no available in Go?" are features t…

Of the top 6 features in this chart, I see only two that are associated with functional languages: the vague "functional language features" catch-all, and ADTs. The rest is commonly found in mainstream imperative languages today.

My point is that functional languages have all these features, even if some are found in non-functional languages these days. Even functional langauges themselves are often not only functional. You can do OO in Scala, imperative and OO in OCaml. OCaml is actually a good example to talk about, as the recent developments are all about adding multicore, better concurrency and better tooling, something that Go was very good at from the start.

In a way, you can see that the people using these languages that may appear very different are converging to the same "ideal". And that's not a surprise, both languages have a very Unix-y origin, and origin in Pascal/Modula. Go added to that CSP, OCaml added ML. These days OCaml is adding things to better handle the CSP part, and some people are asking for Go to better handle the ML part.

Re: Go 1.18

#608

Post by yencabulator »

randomswede wrote: post #588
thegeekpirate wrote: post #475

Earlier quoted context omitted.

You've also opened yourself up to bugs by allowing the map values to be "false". Using a "set's" value in an if statement doesn't make sense either, compared to if _, exists := something[item]; exists { ... } which is explicit regarding what's actually going on. As Rob said, "Clear is better than clever." https://www.youtube.com/watch?v=PAAkCSZUG1c&t=875s I also don't want to be hunting down whoever creates a map[T]b…

I would say that "exists in the set" is determined only and exactly by "mySet[thing]" returning true, not that there happens to be a key in the map. But, that's one of those "requires extensive documentation" (and ideally, wrapping in a custom type and provide methods for checking and manipulating the set(s)).

Now every range over your set is likely to be a bug. `map[T]bool` is simply a bad design to use.

Re: Go 1.18

#609

Post by yencabulator »

stouset wrote: post #241
CraigJPerry wrote: post #228

Earlier quoted context omitted.

>> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not i…

As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less c…

Have you thought about the amount of allocations and copying your chained generic map-reduce thing would cause? Go for loops are good because they are simple, even if you have to use more than one line.

Re: Go 1.18

#610

Post by Mawr »

svnpenn wrote: post #405
frenchie4111 wrote: post #139

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional

Why can't you just do something like this: func hello() (string, bool)

You can, and in fact, that's how idiomatic Go's handled this up until now. But it only works in that specific case, and even then there's a small issue with readability - if you're not already familiar with this pattern, it's not immediately obvious that the string is strongly coupled with the bool. An Optional is very explicit about that.

The problem becomes clearer once you venture out of this exact case. How would you embed this pattern in a struct?

Like so?

  type A struct {
      value string
      valueOK bool
  }
Or maybe with a pointer?

  type B struct {
      value *string
  }
This option is the most common one in Go code today.

You can perhaps see the issues already - these are awkward, neither properly communicates that what we want is optionality.

But the real issue is that now that these are in a struct, nothing prevents us from accessing the value without checking if it's valid first:

  a := A{value: "", valueOk: false}
  // oops
  fmt.Println(a.value)

  a := B{value: nil}
  // oops
  fmt.Println(a.value)
This wasn't an issue in your example - if we attempt to only access the value, and omit assigning the bool, the code will not compile:

  func hello() (string, bool) {
      return "hi", false
  }

  func main() {
      value := hello()
      // ^^^ compiler error: assignment mismatch: 1 variable but hello returns 2 values ([1])
      fmt.Println(value)
  }
An Optional type fixes this by not allowing you to access the value directly, but to instead have to go through a function like the one above.

[1]: https://play.golang.com/p/cJcTD0WWSPO

Post reply on HN