As I understand, the type would be implicitly applied to every func/struc in scope (which I assume would be the package)

It work quite well for package like a Map so any data structure/algorithm. I suspect it would be less ideal for filter/map/reduce.

I don't think it's because of the complexity. I'm quite sure it would not have been difficult to do.

One of the reason is that you don't always want to check the error. The most common one is fmt.Println.

I would not like to always write

_, _ = fmt.Println("Hello, playground")

You certainly do not always want to write _,_ = fmt.Println("Hello, playground"), and I think this points out the real lack. What do you want your program to do if fmt.Println starts failing? I think, unless you are explicitly checking for errors, that in all other cases you want it to crash. Rather than silently continue. Which is a bug, and a potentially disastrous one, that is endemic in Go code (and, to be fair, plenty of other languages). Thankfully the practical risk of this particular case is tiny.

This is why you want unchecked errors to implicitly bubble up. Which is what exceptions give you, or perhaps a syntax with implicit error return values rather than Go's by-convention approach.

If fmt.Println fails you've likely got bigger problems and the game is over.

And if it means a lot in this case, wrap the function and use it instead.

The language to access a relational database is always SQL. So much than a lot of people doesn't make any difference between SQL and a DBMS. Aren't we in the same situation as Javascript on the web? I always had wondered why there is no effort like Webasm for relational database. I would love to see a more vibrant scene with different syntax, paradigm and ideas.

What would be the rust equivalent of a relational language, the Go equivalent?

As an example, I had a lot of pleasure to read that blog : http://www.try-alf.org/blog/2014-12-03-what-would-a-function...

For rust it would literally be Iterators

Because you should stop asking for generics like in Java/C#/rust etc.. Such generic to make custom type safe container is like using a canon to kill a fly.

You should ask for generic package/templated package. It solve the problem, it's way simpler and and would only touch a small part of the spec. More importantly, it wouldn't change the way we code in go today.

With generic package you only have to define the parameter in package declaration like this:

package list {Value: interface{}

And use it by importing it like this:

import list "container/list" {Value: int}

And that's why to go team asked for use case. To use the most simple tool to fix a problem so there is less chance for other problems to appear. If every people wanting to make custom type safe container would stop asking for full generics and instead would brought their case with a simpler solution. I'm sure it would have a chance to go in Go 2.0.

I don't see how that would allow you to do both

  import list "container/list" {Value: int}
  import list "container/list" {Value: string}

in a single source file. At the least, you would need the ability to give the type(s) that those import statements import distinctive names.

Even that would, IMO, not be enough, as this seems (from what I infer the semantics to be) to make it impossible for writers of such a generic library to build on another generic library.

That can be fixed by allowing such a programmer to write:

  package foo {MyValue: interface{}}
  ...
  import list "container/list" {Value: MyValue}

but that, IMO, would be way too cumbersome. That package declaration would have to mention all types in all generic packages that get imported.

Go already allows you to rename imports. It's already used in the example provided, actually; the first token is the aliased name of the package.

I.e.

  import intlist "container/list" {Value: int}
  import stringlist "container/list" {Value: string}

Thanks. I didn't realize that the second token was a user-specified name.

So, this basically would boil down to something like C++ templates, with he extra requirement that templates must be instantiated explicitly.

That is pretty much exactly what my gotemplate package does, except using go generate...

https://github.com/ncw/gotemplate

i'm sorry, what in my post made you think i wouldn't be happy with your solution ?

i would even be happy with no generic at all if basic types implemented low level interfaces, and let me code my containers against things like "sortable, equatable, hashable" ( although it may pose other problems).

Well, It was more about strategy :) Sorry for the stupid analogy, but that's how I feel about the discussion:

A: I need a Ferrari to go to work. How is it hard to understand!

B: Well, you've only have 10 minute commute, a small car would do the work quite as well, as cost a lot less.

A: What made you think i wouldn't be happy with a smaller car?