[go-nuts] Yet Another Generics Proposal...
So, there were plenty of generics proposal, and hopefully I'll get some
constructive feedback about this one.
Syntax Example:
```
type MyGeneric interface {
int32
uint32
float32
float64
ANumber
}
type ANumber interface {
Plus(ANumber) ANumber
Minus(ANumber)
Compare(ANumber) int
Neg() ANumber
}
func ConstrainedFunc(gen MyGeneric) interface{uint32, int32} {
return gen - 1; // will work only for uint32 and int32 as gen, because
return generic type will match the generic, the return type will get a type
constraints
}
func GenFunc(gen MyGeneric) MyGeneric {
return gen - 1; // will work only for every type in MyGeneric, because 1
and -1 can be casted to any of the respective types
}
func ConstrainedFunc(gen interface{uint32, int32}) MyGeneric {
return gen - 1;
}
```
If type or an interface implements all the respective methods it will
trigger the implicit codegen for a type cast.
So, unary/binary type operators could be represented with the respective
interface methods, and their naming should be standartized.
Of course, it's a point of a separate discussion.
But for now it's the most viable solution, as for me, which could've
replace existing reflection and switch interface{} boilerplate and
respective codegen...
The other strong point is that it could be cached and built incrementally
too.
Such generics impl will not break any of the existing code, or conventions,
will not introduce any overhead, and will be able fail at compile time when
any of the target types do not impl the respective methods and operators.
Operator names could've been plain + - <=> but I've seen companies switched
from Scala to Golang just because of "wtf is a spaceship operator"
situation... so, meh.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/25529400-4c37-4e54-8304-38aaa7581fef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Yet Another Generics Proposal...
So, my point is that operator naming should be standardized, or we might've
introduce an additional construct like
```
type Neg operator - func() Neg
type Compare operator <=> func(Compare) int
```
On Friday, May 10, 2019 at 9:15:30 PM UTC+3, Yuriy Yarosh wrote:
>
> So, there were plenty of generics proposal, and hopefully I'll get some
> constructive feedback about this one.
>
> Syntax Example:
>
> ```
> type MyGeneric interface {
> int32
> uint32
> float32
> float64
> ANumber
> }
>
> type ANumber interface {
> Plus(ANumber) ANumber
> Minus(ANumber)
> Compare(ANumber) int
> Neg() ANumber
> }
>
> func ConstrainedFunc(gen MyGeneric) interface{uint32, int32} {
> return gen - 1; // will work only for uint32 and int32 as gen, because
> return generic type will match the generic, the return type will get a type
> constraints
> }
>
> func GenFunc(gen MyGeneric) MyGeneric {
> return gen - 1; // will work only for every type in MyGeneric, because 1
> and -1 can be casted to any of the respective types
> }
>
> func ConstrainedFunc(gen interface{uint32, int32}) MyGeneric {
> return gen - 1;
> }
>
> ```
>
> If type or an interface implements all the respective methods it will
> trigger the implicit codegen for a type cast.
>
> So, unary/binary type operators could be represented with the respective
> interface methods, and their naming should be standartized.
> Of course, it's a point of a separate discussion.
>
> But for now it's the most viable solution, as for me, which could've
> replace existing reflection and switch interface{} boilerplate and
> respective codegen...
> The other strong point is that it could be cached and built incrementally
> too.
> Such generics impl will not break any of the existing code, or
> conventions, will not introduce any overhead, and will be able fail at
> compile time when any of the target types do not impl the respective
> methods and operators.
>
> Operator names could've been plain + - <=> but I've seen companies
> switched from Scala to Golang just because of "wtf is a spaceship operator"
> situation... so, meh.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/28ee5338-7251-46c7-86ae-f2b4e6b5bfee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Proposal for compile-time package overrides support
Basically I've got some different tcp/ip stack implementations based on DPDK and want to be able to replace existing types and methods of the stock net package, which would allow to add DPDK support for existing apps without any amends as a complete plug'n'play. Same goes for JSON serialization and similar non-optimized implementations. Stdlib shouldn't be perfect, but developers should be able to use optimized implementations as a drop-in replacement when necessary. What do you think guys ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f3dfc2bf-f650-436f-82c7-fef67003fd5an%40googlegroups.com.
Re: [go-nuts] Proposal for compile-time package overrides support
Basically I'm replacing net package partially rn with custom DPDK-enabled impl right now i.e. everything syscall.Socket related. It's not about the protocols, it's about replacing whole BSD sock API and epoll/kqueue with a custom impl enterily. I've managed to impl a PoC for this, might create a golang PR soon(-ish) after getting some opinions. Dubbed at slack #dartarts. On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote: > On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh wrote: > > > > Basically I've got some different tcp/ip stack implementations based on > DPDK and want to be able to replace existing types and methods of the stock > net package, which would allow to add DPDK support for existing apps > without any amends as a complete plug'n'play. > > Same goes for JSON serialization and similar non-optimized > implementations. > > > > Stdlib shouldn't be perfect, but developers should be able to use > optimized implementations as a drop-in replacement when necessary. > > > > What do you think guys ? > > I'm not sure quite what you are suggesting. But the net package does > intend to support alternate protocols via calls like syscall.Socket > followed by os.NewFile and net.FileConn. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%40googlegroups.com.
Re: [go-nuts] Proposal for compile-time package overrides support
> don't think it's going to be feasible to make it possible to replace the standard library net package. Well, I'm not proposing to replace entirely, just to add some annotations for the compiler, like use this instead of net package over here... > That's a lot of work and a massive increase in required testing configurations Well, not really... it's application specific and could provide real highload capabilities for golang i.e. 300K-1M RPS per node because of Kernel bypass. Reducing clusters from 32 machines to 4 is not a minimal gain, ofc it should be completely optional. On Monday, July 20, 2020 at 10:30:20 PM UTC+3 Ian Lance Taylor wrote: > On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh wrote: > > > > Basically I'm replacing net package partially rn with custom > DPDK-enabled impl right now i.e. everything syscall.Socket related. > > It's not about the protocols, it's about replacing whole BSD sock API > and epoll/kqueue with a custom impl enterily. > > I've managed to impl a PoC for this, might create a golang PR soon(-ish) > after getting some opinions. > > Dubbed at slack #dartarts. > > I see. I don't think it's going to be feasible to make it possible to > replace the standard library net package. That's a lot of work and a > massive increase in required testing configurations for relatively > minimal gain. > > Since you mentioned JSON I'll note that the encoding/json package does > not depend on the net package. > > Ian > > > > On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote: > >> > >> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh > wrote: > >> > > >> > Basically I've got some different tcp/ip stack implementations based > on DPDK and want to be able to replace existing types and methods of the > stock net package, which would allow to add DPDK support for existing apps > without any amends as a complete plug'n'play. > >> > Same goes for JSON serialization and similar non-optimized > implementations. > >> > > >> > Stdlib shouldn't be perfect, but developers should be able to use > optimized implementations as a drop-in replacement when necessary. > >> > > >> > What do you think guys ? > >> > >> I'm not sure quite what you are suggesting. But the net package does > >> intend to support alternate protocols via calls like syscall.Socket > >> followed by os.NewFile and net.FileConn. > >> > >> Ian > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d3e42b12-3177-4dc7-8522-d3058ab1f9c4n%40googlegroups.com.
Re: [go-nuts] Proposal for compile-time package overrides support
> https://golang.org/issue/35283 Yup, thanks for pointing this out. On Tuesday, July 21, 2020 at 12:09:07 AM UTC+3 Ian Lance Taylor wrote: > On Mon, Jul 20, 2020 at 12:48 PM Yuriy Yarosh wrote: > > > > > don't think it's going to be feasible to make it possible to > > replace the standard library net package. > > > > Well, I'm not proposing to replace entirely, just to add some > annotations for the compiler, like use this instead of net package over > here... > > Yes, that is also what I meant. Replace in the sense of "replace at > compile time." > > > > > That's a lot of work and a > > massive increase in required testing configurations > > > > Well, not really... it's application specific and could provide real > highload capabilities for golang i.e. 300K-1M RPS per node because of > Kernel bypass. > > Reducing clusters from 32 machines to 4 is not a minimal gain, ofc it > should be completely optional. > > I'm sorry, I don't understand how your comment addresses my objection. > > See https://golang.org/issue/35283. > > Ian > > > > > On Monday, July 20, 2020 at 10:30:20 PM UTC+3 Ian Lance Taylor wrote: > >> > >> On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh > wrote: > >> > > >> > Basically I'm replacing net package partially rn with custom > DPDK-enabled impl right now i.e. everything syscall.Socket related. > >> > It's not about the protocols, it's about replacing whole BSD sock API > and epoll/kqueue with a custom impl enterily. > >> > I've managed to impl a PoC for this, might create a golang PR > soon(-ish) after getting some opinions. > >> > Dubbed at slack #dartarts. > >> > >> I see. I don't think it's going to be feasible to make it possible to > >> replace the standard library net package. That's a lot of work and a > >> massive increase in required testing configurations for relatively > >> minimal gain. > >> > >> Since you mentioned JSON I'll note that the encoding/json package does > >> not depend on the net package. > >> > >> Ian > >> > >> > >> > On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote: > >> >> > >> >> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh > wrote: > >> >> > > >> >> > Basically I've got some different tcp/ip stack implementations > based on DPDK and want to be able to replace existing types and methods of > the stock net package, which would allow to add DPDK support for existing > apps without any amends as a complete plug'n'play. > >> >> > Same goes for JSON serialization and similar non-optimized > implementations. > >> >> > > >> >> > Stdlib shouldn't be perfect, but developers should be able to use > optimized implementations as a drop-in replacement when necessary. > >> >> > > >> >> > What do you think guys ? > >> >> > >> >> I'm not sure quite what you are suggesting. But the net package does > >> >> intend to support alternate protocols via calls like syscall.Socket > >> >> followed by os.NewFile and net.FileConn. > >> >> > >> >> Ian > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to golang-nuts...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%40googlegroups.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/d3e42b12-3177-4dc7-8522-d3058ab1f9c4n%40googlegroups.com > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/839abe73-ec72-4141-a9ea-d75eb1e8fa08n%40googlegroups.com.
[go-nuts] What about QNX golang support ?
So, I'm currently interested in using golang for a QNX based project, but afaik there was no QNX port yet. Is it even possible now ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
