Live data from Hacker News

Toward Go 2

blog.golang.org

111–120 of 670 posts

Re: Toward Go 2

#111
post #68

Earlier quoted context omitted.

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

There's no obvious way to separate personal work, from work work, from exploratory work, from any other way you want to categorise your source directories. You just have to chuck them all in the same root and hope you can remember what each project is for.

That is the reason why GOPATH is an environment variable: so you can change it easily, you own way.

Re: Toward Go 2

#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.

Re: Toward Go 2

#113
post #95
post #6

Earlier quoted context omitted.

Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

In my specific case it was the fact that i could not have one insert function or one update function.

I would need one for each and every struct(table).

These days there is a tool that can generate all those struct methods: https://github.com/vattle/sqlboiler

So from the ORM perspective we (as the community) have worked around it.

Re: Toward Go 2

#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?

Re: Toward Go 2

#115

Earlier quoted context omitted.

I think the Go team would still like to understand your production uses that caused you to write off Go. What is your problem domain? How would you accomplish that in Go? How did you actually solve your problem with a different language? For me, user provided data structures are the only thing that comes to mind (sync.Map for example) in my production use of Go. But even then, my pain (time spent, errors made) due to…

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) => // got a Bar with as string inside
        Baz(n, _) => // got a Baz, took the first number
        Qux => // Got a Qux, it stores no data
    }
(and in most languages the compiler will yell at you if you forget one of the variants).

So for your use case you'd have e.g.

    enum Value {
        Boolean(bool),
        Integer(u32),
        String(String),
        // etc…
    }
> I played around with interface and reflect.TypeOf but lost too much performance compared to just storing everything in a string.

Maybe try a struct with an explicit tag rather than reflection? e.g.

    type ValueType int
    const (
        TYPE1 ValueType = iota
        TYPE2
        TYPE3
        // … one for each concrete type you want to wrap

    )
    struct Value {
        type ValueType
        value interface {}
    }
and then you can

    switch value.type {
    case TYPE1:
        value.value.(Type1)
    case TYPE2:
        value.value.(Type2)
    // etc...
I'd expect reflect.TypeOf to be very expensive, this is a check + a cast.

Re: Toward Go 2

#116

How about fixing all the GOPATH crap?

yeah, I don't fully understand this. I've had the least problems with GOPATH than I have with any other language. You literally set GOPATH=${HOME} and it just works.

Re: Toward Go 2

#117

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. 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…

C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.

It is new to C#, which is slowly catching up to Scala and F# in that regards. Mads Torgesen is good friends with Martin Odersky, in fact, when I first met Mads back in 2006 or so, they were talking about adding pattern matching to C#. C# is a much more conservative language, and it makes sense it would take a while to add.

There are good reasons to use C#, so when it gets a new feature that other languages have had for years, well, it is newsworthy.

Now when will javascript get pattern matching?

Re: Toward Go 2

#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 heavy moralizing tone that you should feel bad for even asking about the issue. It's infuriating that the same people making those comments are now taking credit for the solution, when they had to be dragged into even admitting the issue was legitimate.

Re: Toward Go 2

#119
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…

Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.

Does that mean it now throws an error if you use the common punt like `foo, _ := …` and never check `_`?

Re: Toward Go 2

#120

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.

What do you use?
Post reply on HN