Toward Go 2 • Hacker News Board

Re: Toward Go 2

#131

Post by treehau5 » Thu, Jul 13, 2017, 7:16 PM UTC

camus2 wrote: post #127

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead…

> Pike said "Go design" is done. Except that a language which design "is done" is a dead one.

Guess C is done for.

Re: Toward Go 2

#132

Post by fixermark » Thu, Jul 13, 2017, 7:17 PM UTC

johansch wrote: post #114

My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

I'd be even more excited if the compiler were willing to execute complete heresy on my behalf and (with user consent) edit my source code automatically to remove unused imports. ;)

Re: Toward Go 2

#133

Post by [deleted] » Thu, Jul 13, 2017, 7:18 PM UTC

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

[deleted]

Re: Toward Go 2

#134

Post by owaislone » Thu, Jul 13, 2017, 7:19 PM UTC

tschellenbach wrote: post #112

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.

> Improvements to package management is probably the highest item on my wishlist for Go 2.

The work is in progress and will most likely be available for general purpose use way before Go2.

Check it out: https://github.com/golang/dep

Re: Toward Go 2

#135

Post by I_am_tiberius » Thu, Jul 13, 2017, 7:19 PM UTC

masklinn wrote: post #115

I_am_tiberius wrote: post #102

Earlier quoted context omitted.

I'm new to Go and actually and don't do professional IT work but I immediately felt the need for having a type that allowed me to store any type. My use case was/(still is) writing a spreadsheet where a user can enter different stuff in a cell and I want to store the value in an underlying data type. I now ended up storing everything as string because I couldn't figure out an efficient way to implement it. My goal wo…

> My goal would have been to have one generic type that can store the cell types text and number which I can store in an array. FWIW generics wouldn't help you with that, "sum types" would. A sum type is a souped-up enum which can store associated data alongside the "enum tag", so you can have e.g. enum Foo { Bar(String), Baz(u8, u32), Qux, } and at runtime you ask which "value" is in your enum: match foo { Bar(s) =>…

Thanks for that information. I had thought enums can only be used as named types. Good to know they can hold data as well. I had though of that struct as well (ok, not in that professional way with types as constants and iota:-)) but found it a bit annoying that I have to store a type myself although the type itself should already have the type information somewhere itself - consequently that information is stored reduntantly. But I'll definitely try that. Thanks.

Re: Toward Go 2

#136

Post by kzisme » Thu, Jul 13, 2017, 7:20 PM UTC

frik wrote: post #110

kzisme wrote: post #73

Earlier quoted context omitted.

I'm also curious as to what issues you have come across with GOPATHS

Multiple unrelated Go projects in different repos located in different directories. No problem at all with very other language, except with Go - not possible! I want to open cmd.exe (Win) or bash (Linux) and cd to the directory and build. And not configure a GOPATH in the environment variables of the current user or pretend it to the batch script, set it in IntelliJ Go plugin, etc. It so unflexible, so arkward, and t…

This is the sort of thing that makes it hard to get started with Go in my opinion.

Re: Toward Go 2

#137

Post by tomovo » Thu, Jul 13, 2017, 7:20 PM UTC

int_19h wrote: post #59

tomovo wrote: post #11

Earlier quoted context omitted.

More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.

C++ doesn't have generics, it has templates, which are effectively a syntax-constrained form of macros. That's why it lends itself to abuse (or creative use, depending on your take on macros).

So C++ generates separate code for each template type and C# and Java do a typecheck at compile time and reuse the same codepath for all types at runtime?

Re: Toward Go 2

#138

Post by kevinconaway » Thu, Jul 13, 2017, 7:20 PM UTC

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> asking for monotonic time

His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted.

> We did what we always do when there's a problem without a clear solution: we waited

The original problem described the issue and the potential consequences very well and the problem didn't change between the initial report and when cloudflare hit it. It was only until a Serious Industrial User (to borrow a term from Xavier @ OCaml) got bit in a very public way that they actually began thinking about what a clear solution would look like.

Re: Toward Go 2

#139

Post by thibran » Thu, Jul 13, 2017, 7:21 PM UTC

I would love to see uniform-function-call-syntax.

Turning: func (f Foo) name() string

Into: func name(f Foo) string

Callable like this: f.name() or name(f)

Extending foreign structs from another package should be possible too, just without access to private fields.

Other than that, if-as-expression would be nice to have, too.

Re: Toward Go 2

#140

Post by treehau5 » Thu, Jul 13, 2017, 7:22 PM UTC

solomatov wrote: post #18

fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Conversely, I would stop using Go in my projects if it introduces generics.

If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations that nobody else in the world understands, and your project fails but hey -- at least you have a dope, terse, generic implementation -- totally rad.