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

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

471–480 of 534 posts

Re: Go 2, here we come

#471

Post by AsyncAwait »

meddlepal wrote: post #418
AsyncAwait wrote: post #298

Earlier quoted context omitted.

> Python with PEP484 is pleasant. Not yet, I use types as an important form of documentation, so the vast majority of the library ecosystem would need to adopt optional types before I'd consider it so. > Java 11 Not may people actually write Java 11 at work, most are stuck with 8, or even 6. Java 11 is basically even less mainstream than Kotlin right now, as not even Android supports it. > is pretty much on par with…

> significantly better for your argument to work. No you misinterpreted my point. It has to be significantly better than what already exists at the time of creation. Java was this to C++ in the 90s and early 2000s. Go is not that language.

Go can serve as a sort of Java to people who don't want the JVM. There's no rule that says only one language is allowed in a particular space. Go has several strong points and several weaknesses, which are to be addressed in Go 2.

Java didn't have lambdas until 8 and now it does. Its generics implementation is not what I'd like to see. Still, it certainly has its place.

Go has been used to implement widely used technologies like Docker & k8, so it seems to have found its justification for existing as well.

Re: Go 2, here we come

#472

Post by kochthesecond »

infogulch wrote: post #23

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

Coming from languages that lack such a «convention», I quite like Context. Try implementing something similar in java or even node is also a giant pain

Re: Go 2, here we come

#473

Post by majewsky »

floatboth wrote: post #214
asien wrote: post #26

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

hah. GOPATH is the only thing I like about Go. I have all (non-Go) repositories cloned as URL-style paths e.g. ~/src/github.com/user/repo. I strongly dislike the non-standard internals (horrendous custom assembler, direct usage of syscalls instead of libc) and the "developers are too stupid to use this" attitude towards modern language features.

Same for me. I moved all my code into the GOPATH pattern after finding that I had 3 separate clones of the Linux kernel in separate places. (And not just for development, just for reading and grepping.) I made myself a helper tool for navigating the GOPATH:

  $ cg gh:torvalds/linux # cg = cd to git repo
  $ pwd
  .../src/github.com/torvalds/linux
The code is at https://github.com/majewsky/gofu#rtree if anyone's interested.

Re: Go 2, here we come

#474

Post by dullgiulio »

closeparen wrote: post #362
erikpukinskis wrote: post #352

Earlier quoted context omitted.

Increasing language surface area will generally increase the complexity of all api surfaces written in the language. This has obvious costs. It’s true genetics will shrink some specific APIs, where they are a good fit. But they will also be used opportunistically by developers excited to push their boundaries. Of course you can say “just don’t do that” which works if you have a tightly controlled codebase. But most c…

It’s C’s lack of complexity which makes it necessary to do dangerous things for everyday purposes. I’d much rather a novice interact with generics, where the compiler is a safety net, than with void * and interface{}.

void * and interface{} are not going away when generics come. Try searching for "Object" or "" in some Java code...

Re: Go 2, here we come

#475

Post by growse »

pxia wrote: post #329
growse wrote: post #325

Earlier quoted context omitted.

Shouldn't idiomatic go return an error instead? Magic number ranges for errors always seemed a bit old-fashioned.

It's just an example... Another example would be you want to iterate your array in reverse. The normal `for (uint i=size-1; i >= 0; i--)` won't work.

That example doesn't work precisely because you're conflating the concept of the loop counter (which type represents an integer that needs to be able to go What would be a more compelling argument is to use int in the same way that python does - a negative accessor means offset from the end of the array, not the start. I'm not sure golang lets you do this though...?

Re: Go 2, here we come

#476

Post by 4ad »

greenleafjacob wrote: post #370
jerf wrote: post #356

Earlier quoted context omitted.

Despite most of my professional programming being in Go nowadays, I am extremely sympathetic to the Haskell/FP way of thinking about things, and trying to make invalid state unrepresentable. However, having made the mistake a few times now of trying to use "unsigned ints" for things that I want to assert are never negative, I've learned the hard way not to do that. The problem is, there's always some bug you have in…

> if this int or uint under or overflows, throw an exception Overflow flags are supported on some architectures, so it would really just be a matter of checking that flag.

Except in Go, types are defined using modular 2s complement. Overflow is not considered a problem, it's a feature that code depends on.

Re: Go 2, here we come

#477

Post by dtech »

usrusr wrote: post #251
dmurray wrote: post #233

Earlier quoted context omitted.

> Why not introduce a primitive type "num" for arbitrary precision rational numbers instead? Rationals aren't supported natively by processors, so there's no real need to handle this as a primitive instead of letting people to use a library for it. Adding them to the base language just because some people would find it convenient would clash with Go's explicit minimalist philosophy.

It's like building in special handling for a string type, exactly one instead of a catalog of library options. I'd say that would fit in quite well with the brand of minimalism that Go is representing, keep the language simple and provide builtins where more convenience is needed. The opposite kind of "minimalism" would be providing tools to allow libraries to define what other languages can only support as special b…

> I wonder wether Scala has inerited special handling for the (not special, but specially handled) string type

Scala uses Java's String exactly, but does define a few extra methods using its extension method functionality (called implicit class in Scala)

Templates like s"This is a string with a $variable", are part of the language, but `s` is a stdlib feature.

   xxx"First $a $b Second"
will be translated by the compiler to

   new StringContext(Array("First ", " ", " Second")).xxx(a, b)
The standard library defines `StringContext.s`, but there's no restriction. Several SQL Libraries for example define `StringContext.sql`, to allow you to safely and type-checked embed SQL queries directly inside the code.

Re: Go 2, here we come

#478

Post by bryanlarsen »

stcredzero wrote: post #46
bryanlarsen wrote: post #29

Earlier quoted context omitted.

For the first round they are testing the GO 2 selection process by applying it to proposed changes for 1.13, which limits it to non-breaking proposals. It won't get interesting until they start selecting breaking proposals.

It won't get interesting until they start selecting breaking proposals. From what I see in the past couple of decades in popular languages, is there really a justification for breaking changes, from the POV of project maintainers?

Rust 2018 has breaking changes, and their mechanism for dealing with it is incredible.

Re: Go 2, here we come

#480

Post by gameswithgo »

glangdale wrote: post #339

I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments. As for all the folks claiming they'll leave Go if it gets generics, it's faintly remini…

>"Oh, I need a vector of maps from a pair of Foo to a set of Bar"

This is a fun example since you can do that in Go now, as it comes with a generic vector (essentially) and map :D

I think that was the design decision, 95% of generics use cases are covered by having growable arrays and maps, so why clutter the language with generics.

I like generics, I think most people who dislike them are coming from C++ templates, which has downsides that don't exist in newer generics systems (such as in C# or F#)

Post reply on HN