mopsy

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")

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

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?

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.