3 ms·

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

Zach_the_Lizard 10y ago
They seem to take a lazy approach to feature development. Generics are complicated and bad, but having makeIntMap or makeStringSlice is...not great for developer productivity. So let's special case `make()`, slices, channels, etc. so that some productivity is possible. Then as they add library features they violate their own tenants as they find utility in these verboten constructs. Exceptions are bad...But we have panics which are in no way the same thing renamed. Never expose them outside a package...But closing an already closed channel panics. Random number generator functions panic on mundane and expected things, just like Java checked exceptions. Example: https://golang.org/pkg/math/rand/ https://golang.org/pkg/math/rand/ ``` func (Rand) Int31n func (r Rand) Int31n(n int32) int32 Int31n returns, as an int32, a non-negative pseudo-random number in [0,n). It panics if n <= 0. ``` Standard behavior would be returning an error, not panicking, See this: https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover ``` The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. ``` It's just an inconsistent and, quite frankly, disappointing language outside of goroutines and its interfaces. Those two make it possible to be productive, but with generics for instance a whole slew of new possibilities will emerge. The simplicity is nice, but it's too simple and too inconsistent. All the verbosity of Java combined with the impenetrable inconsistency and abbreviations of C.
stefantalpalaru 10y ago
You can have your generics and many other nice things combined with the gccgo goroutines, channels and garbage collector by switching to Nim: https://github.com/stefantalpalaru/golib-nim https://github.com/stefantalpalaru/golib-nim
randomdata 10y ago
I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.
- algesten 10y ago
  How can a google backed project not have the resources?
  - randomdata 10y ago
    I don't know, but Google does frequently complain about not being able to find talent. Some of this is through fault of their own, but it is easy to imagine that they have not found suitable developers to fill the spot, for whatever reason it may be. They have lots of other business goals for what developers they do have. Putting their people on generics at the cost of some other business function may not be a good choice, even if it is theoretically possible.
Buttons840 10y ago
I've been thinking about a two way compiler with a primary focus on producing readable code. If such a compiler targeted Go or Java, you could white your "Go+" code (for lack of a better name) in a higher level language with more features, and have it compiled to readable Go code. I don't know to what extent this is possible, but if it was good enough you could be a Go developer while rarely writing actual Go code.
- zzzcpan 10y ago
  It is very much possible, there are already DSLs that generate Go code. I'm even doing that myself.
  - solidsnack9000 10y ago
    Can you link some examples?
pjmlp 10y ago
It would be wasted work, because no one in the community would take it. So better spend that time contributing to other parts of the Go ecosystem, or another programming language project.

Zach_the_Lizard 10y ago

They seem to take a lazy approach to feature development. Generics are complicated and bad, but having makeIntMap or makeStringSlice is...not great for developer productivity. So let's special case `make()`, slices, channels, etc. so that some productivity is possible. Then as they add library features they violate their own tenants as they find utility in these verboten constructs. Exceptions are bad...But we have panics which are in no way the same thing renamed. Never expose them outside a package...But closing an already closed channel panics. Random number generator functions panic on mundane and expected things, just like Java checked exceptions. Example: https://golang.org/pkg/math/rand/ https://golang.org/pkg/math/rand/ ``` func (Rand) Int31n func (r Rand) Int31n(n int32) int32 Int31n returns, as an int32, a non-negative pseudo-random number in [0,n). It panics if n <= 0. ``` Standard behavior would be returning an error, not panicking, See this: https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover ``` The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. ``` It's just an inconsistent and, quite frankly, disappointing language outside of goroutines and its interfaces. Those two make it possible to be productive, but with generics for instance a whole slew of new possibilities will emerge. The simplicity is nice, but it's too simple and too inconsistent. All the verbosity of Java combined with the impenetrable inconsistency and abbreviations of C.

stefantalpalaru 10y ago

You can have your generics and many other nice things combined with the gccgo goroutines, channels and garbage collector by switching to Nim: https://github.com/stefantalpalaru/golib-nim https://github.com/stefantalpalaru/golib-nim

randomdata 10y ago

I wonder this too. For how important generics are claimed to be, it does seem strange that nobody has stepped up and helped out the core team in this capacity. They have been quite open about wanting generics, but do not have the resources to dedicate to implementing them in an acceptable fashion. But being an open source project, anyone can step up to fill that void.

algesten 10y ago
How can a google backed project not have the resources?
- randomdata 10y ago
  I don't know, but Google does frequently complain about not being able to find talent. Some of this is through fault of their own, but it is easy to imagine that they have not found suitable developers to fill the spot, for whatever reason it may be. They have lots of other business goals for what developers they do have. Putting their people on generics at the cost of some other business function may not be a good choice, even if it is theoretically possible.

Buttons840 10y ago

I've been thinking about a two way compiler with a primary focus on producing readable code. If such a compiler targeted Go or Java, you could white your "Go+" code (for lack of a better name) in a higher level language with more features, and have it compiled to readable Go code. I don't know to what extent this is possible, but if it was good enough you could be a Go developer while rarely writing actual Go code.

zzzcpan 10y ago
It is very much possible, there are already DSLs that generate Go code. I'm even doing that myself.
- solidsnack9000 10y ago
  Can you link some examples?

pjmlp 10y ago

It would be wasted work, because no one in the community would take it. So better spend that time contributing to other parts of the Go ecosystem, or another programming language project.