Toward Go 2

Post by slaymaker1907 » Fri, Jul 14, 2017, 2:31 AM UTC

jdmichal wrote: post #91

snuxoll wrote: post #76

Earlier quoted context omitted.

Java has "had" anonymous functions for ages with anonymous inner classes, they just sucked as an implementation.

Absolutely correct. Lambdas are just shorthand for anonymous inner classes which implement an interface with only one method -- aka single abstract method (SAM) types. For instance, you have two functions. One takes `Function ` and the other takes `UnaryOperator `. Giving the "same" lambda to both functions will result in two anonymous inner types, one implementing both interfaces.

Post by artursapek » Fri, Jul 14, 2017, 2:37 AM UTC

vacri wrote: post #425

artursapek wrote: post #93

Earlier quoted context omitted.

What? Manage it the way you'd manage any other environment variables, like AWS_SECRET_ACCESS_KEY. That's exactly what a bash environment is for.

You want to manage GOPATH as if it were a secret key!? Not ever storing it in repos, having weird dotfiles storing them locally, having to set up a keystore cluster like consul in production? Yuck.

Post by bascule » Fri, Jul 14, 2017, 2:42 AM UTC

dgacmu wrote: post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

Post by lewisl9029 » Fri, Jul 14, 2017, 3:02 AM UTC

spyspy wrote: post #426

vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

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.

Post by rmrfrmrf » Fri, Jul 14, 2017, 3:17 AM UTC

weberc2 wrote: post #240

callesgg wrote: post #113

Earlier quoted context omitted.

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.

I guess I don't see how generics would help you reduce the number of insert/update functions. The basic problem of an ORM is to map struct fields to columns; I don't see how generics would help you here. Can you write the generic pseudocode you want to write?

    class Collection {
        void insert(T entity) {
            String vals = entity.props.map(escapeSql).join(",");
            String qs = entity.props.map(x => "?").join(",");
            PreparedStatement p = db.prepare("insert into %s (%s) values (%s);", this.tableName, qs, vals);
            db.submit(p);
        }
    }