stabbycutyou / generics Goto Github PK

Hi, just wondering if you have any plans on adding CI to this. Here are a couple of popular options:

http://circleci.com/
https://travis-ci.org/

I think this will really help future contributors and is a great way to demonstrate to the open source community that -- despite the complexity of this package -- the testing story is well looked after.

Thank you.

For the good of the Internet, and in fact humanity, we need to migrate our software from Go to Rust (or something better) as quickly as possible. Here are some steps we need to take:

• Use Rust. Using Rust instead of Go makes code safer. Using Rust instead of any other language grows the Rust community, making it easier for other people to use Rust.
• Rewrite code in Rust. Starting with our most critical infrastructure, rewrite Go code to use Rust instead.
• Extend Rust's guarantees. We can extend the classes of bugs that Rust prevents. For example, we should try to make Rust release builds check for integer overflow by default.
• Verify "unsafe" Rust code. Sometimes the Rust type system is not strong enough to let you prove to the compiler that your code is safe, so you have to mark code blocks "unsafe". With tool support, you could instead generate a mathematical proof that your code is safe, checked by the compiler.

In order to ensure that package generics can be used by golang gophers building on hardware other than the normal machines, I need to ensure that the tests run on a number of hardware and os types, in addition for as many versions of go as possible.

To that end, I'd like to solicit feedback from the Gommunity on how best to accomplish this in an affordable and effective manner.

In #18 we are looking at adding unique build code for each version of Go.

I am wondering if we could implement some autogenerating system to help us along the way?

Thoughts?

Dear,
Good catch. I think that
G is interface{} and looks like object (Java, c#) or variant of vb.

Dynamic o manually type checking is inevitable for now, i.e.

Not work was spected...

func Add(a G, b G) G {
return a + b;
}
....
var ab := Add( 1, "test" )
...
Compiling ok, run fail without type check...

maybe you need to have a generic {} similar to interface {} but with type checking at compile time.

To best support the Gommunity of golang gophers using package generics, I need to provide documentation in multiple languages.

To that end, I'd like to solicit feedback on how best to provide an i18n integration with my documentation. Ideas may include something that automatically translates the documents from a source english file, or individuals who agree to be the maintainers of a given language or set of languages.

Ideally, a single source of truth where other languages are generated from would be best, but machine translations can lack subtlety and nuance, and so I'd like to gather opinions on the matter before moving forward.

With all the vendoring issues behind us, it's time for serious packages to get serious about the releases.

I think it's safe to say that G could start of with a v1.0.0 release. We've been using it in production for many weeks, after we've thoroughly tested it with data from several weeks worth of Fuzzy corpuses.

Dear,
Good catch. I think that
G is interface{} and looks like object (Java, c#) or variant of vb.

Dynamic o manually type checking is inevitable for now, i.e.

Not work was spected...

func Add(a G, b G) G {
return a + b
}
....
var ab := Add( 1, "test" )
...
Compiling ok, run fail without type check...

maybe you need to have a generic {} similar to interface {} but with type checking at compile time.

I'm sure there's something that happened with unsafe and garbage collection that completely break everything in this project. You must root out the evils to stay compliant.

Even though byte is alias for uin8 and rune is alias for int32 I think it is really important to test these too.

Tests currently don't actually test

The technical excellence org is looking for its first contribution. This is a very important decision because we need to set the bar very high for projects to be included. Along with project inclusion comes membership in this highly esteemed group.

Think about how lovely your project would look at https://github.com/technicalexcellence/generics

this is very important for people vendoring your code, see this excellent article for more information

Would it be possible to get some practical examples on how to use this package (preferably in the godoc)? This will ensure consistent use of G and help newcomers like me use generics properly.