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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

521–530 of 670 posts

Re: Toward Go 2

#521

Post by morecoffee »

the_duke wrote: post #148
saghm wrote: post #35

Earlier quoted context omitted.

I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handlin…

I have no idea why you are being downvoted. In Rust, this was handled the right way. The Result type forces you to at least actively dispose of the error. In Go, it's just way too easy to leave an error unhandled.

In order to maintain compatibility with other interfaces, they have to return error in several places. Take bytes.Buffer, which return errors even when they are impossible. Same with http.Cookie(). It promises it will only ever be http.ErrNoCookie, but that isn't going to make static analysis tools happy.

Re: Toward Go 2

#522

Post by dtech »

xargon7 wrote: post #493
dtech wrote: post #391

Earlier quoted context omitted.

One of the problems is who decides what is too simple. E.g. why are for loops, function calls and lamdbas considered simple enough to be in go, but generics aren't? When I TA'ed CS introductory courses, student usually had a lot less trouble with understanding generics than lambdas. Not including feature X in programming language Y will also ensure that no-one who primarily uses Y will ever come to understand or appr…

The complexity from generics isn't from the conceptual standpoint, it's from the resulting code standpoint... for the same reason that the ternary ?: operator is "too complex": it's really easy to say that `foo := cond ? 1 : 0` is better than the if/else alternative, but `foo := (a > (b.Active() ? Compare(b, a) : useDefault() ? DEFAULT : panic()) ? "worked" : "failed"` is a mess waiting to happen. Same with generics.…

Maybe, but the solution to this is not to say: Only the compiler implementers are smart enough people to not create messy code with generics, only a few built-in data types are allowed to be generic and the rest will have to copy-paste implementations or use lose type information through `interface {}`

Re: Toward Go 2

#523

Post by Sharlin »

concede_pluto wrote: post #471
pcwalton wrote: post #462

Earlier quoted context omitted.

If that's the case, then the Go community is wrong. For loops do not get the job done easily enough. I've lost count of the number of times I've had to do contortions in order to count backwards inclusive down to zero with an unsigned int. With a proper iterator API, it's trivial. Furthermore, for loops are a pain to optimize. They encourage use of indices everywhere, which results in heroic efforts needed to elimina…

It's also strange that a language that wants to encourage parallelism requires for loops, and specifies that they always run sequentially. Java 8 can put map/reduce with a thread pool in the standard library precisely because it doesn't use a for loop; imagine how tedious and repetitive the Go version would be: https://docs.oracle.com/javase/tutorial/collections/streams/...

To be fair, I don't think Go prioritizes parallelism as much as it does concurrency.

Re: Toward Go 2

#524

Post by Someone »

mathw wrote: post #512
adrianratnapala wrote: post #489

Earlier quoted context omitted.

Even if you don't care about binary bloat (and I do care), it can introduce some of the same problems as dynamic typing. If I am debugging some C++, and I find myself looking at templated function, then I can't easily see what types the template parameters are. Also it becomes hard to navigate to method calls etc. C++ is a particularly bad example, because template metaprogramming is essentially typeless. But any for…

Since C++ monomorphises every single template instantiation in a program, your debugger certainly should be able to tell you what the type parameters for that instance were!

A sufficiently smart linker will make that harder by removing functions that, byte for byte, are identical to one they already included in the executable ("identical code folding"; both gcc's gold linker and visual studio support that).

Re: Toward Go 2

#525

Post by chongli »

erikpukinskis wrote: post #323
kernelbandwidth wrote: post #184

Earlier quoted context omitted.

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the r…

This suggests that both generics and inheritance are unnecessary.

Thanks to Turing equivalence, all programming languages are unnecessary. We should all go back to writing machine code.

Re: Toward Go 2

#526

Post by chongli »

seanwilson wrote: post #74
wheaties wrote: post #16

Earlier quoted context omitted.

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

> If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Yeah, I find it strange how languages are trending at a glacially slow pace to having the same features that strongly typed functional programming languages have had for literally decades. It's like we're going to be using actua…

strange how languages are trending at a glacially slow pace

Human behaviour is strange when you expect rationality. Sour grapes is such a pervasive cognitive bias that one has to wonder why it exists since it's obviously irrational. I think it's likely that it presents a major advantage in the psychology of group cohesion.

Re: Toward Go 2

#527

Post by jpttsn »

runeks wrote: post #520
spyspy wrote: post #426

Earlier quoted context omitted.

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

> If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line. It's not incomprehensible, it's just phrased a different way from what you're used to. A lot of programming boils down to mutating local or global state, by executing lines of code -- each of which mutatin…

> It's not incomprehensible, it's just phrased a different way from what you're used to.

What would be incomprehensible?

Re: Toward Go 2

#528

Post by pjmlp »

43224gg252 wrote: post #378
jcadam wrote: post #81

Earlier quoted context omitted.

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library). I've mostly moved on to Clojure for p…

I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used. I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually sho…

> C doesn't have generics but we never have this discussion when we talk about C.

Sure it does, a light weight version was introduced in C11.

http://en.cppreference.com/w/c/language/generic

Besides, C gets an excuse because the language was designed before generics were even invented, and with pre-processor macros is it possible to implement a poor man's generic system.

Re: Toward Go 2

#529

Post by issaria »

Regarding the lacking of generics problem, is there a way to get around it, there are always plenty of tools doing that, if the IDE can patch the syntax and support certain kind of prigma to generate the template code, then the problem is almost solved, not sure if it'll cover all cases like Java does though.

Re: Toward Go 2

#530

Post by pjmlp »

rbehrends wrote: post #344
munificent wrote: post #168

Earlier quoted context omitted.

> so was C# 2.0. True, but C# also has nominal types, overloading, and explicit interface implementation. Adding generics without breaking existing code without those features looks very difficult to me.

They don't have to be Java-ish generics. Think SML/OCaml/Ada/Modula-3 (modules parameterized by modules) or Haskell (typeclasses).

Actually that would be the easier way. It is also how CLU had them.
Post reply on HN