3 ms·

Which specific "code gen tools" and "non standard syntax"? What kinds of errors would you expect to be "caught at compile time" with a different type system?

Which specific "code gen tools" and "non standard syntax"? What kinds of errors would you expect to be "caught at compile time" with a different type system? What kinds of "default values lead to subtle bugs"? Have you looked into... a) the Go2 generics draft design https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... b) the Go2 error handling draft design feedback (the initial concept is unworkable :-) https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

ilovecaching 8y ago
> Which specific "code gen tools" and "non standard syntax"? I've done codegen through a DSL and through comments. The DSL is actually typed, which is nice, but it's also its own mini-language that you have to teach people on top of the Go basics. It's also a general rule that it should be used sparingly because it tends to generate very verbose and ugly code. > What kinds of errors would you expect to be "caught at compile time" with a different type system? The empty interface, which must be cast to the contained type to be useful, is an obvious one. Generally type casts, error handling, pointer dereferences, all can lead to run time bugs. At the macro level, a language with a rich type system should make invalid program states fail to compile. With true phantom types, for example, one can make a state machine that will fail to compile if a state transition invariant is not satisfied. > What kinds of "default values lead to subtle bugs"? The issue is that the notion of a "default value" makes little sense. For many applications 0 is not a good choice for the initial value of every integer. Someone who forgets to set the integer to an appropriate value will run into the same error as in C, except instead of a trash value, they will find a consistently bad value, which is slightly better. Better to throw an error if an uninitialized value is used, and demand that all struct fields be set unless the struct author has explicitly set default values. > Have you looked into... Yes, I have seen the proposals. I am an opponent to generics in Go. I think Go excels at exactly that which I described in my first post. If you add more to the language, I believe it will morph into a poor mans Java instead of a better Go. Better to simply move to a language that was built from the ground up with the intention of providing abstractions (I like Rust), and use Go when its upsides outweighs its downsides. Many times, they do, especially in businesses where the talent pool is limited.

ilovecaching 8y ago

> Which specific "code gen tools" and "non standard syntax"? I've done codegen through a DSL and through comments. The DSL is actually typed, which is nice, but it's also its own mini-language that you have to teach people on top of the Go basics. It's also a general rule that it should be used sparingly because it tends to generate very verbose and ugly code. > What kinds of errors would you expect to be "caught at compile time" with a different type system? The empty interface, which must be cast to the contained type to be useful, is an obvious one. Generally type casts, error handling, pointer dereferences, all can lead to run time bugs. At the macro level, a language with a rich type system should make invalid program states fail to compile. With true phantom types, for example, one can make a state machine that will fail to compile if a state transition invariant is not satisfied. > What kinds of "default values lead to subtle bugs"? The issue is that the notion of a "default value" makes little sense. For many applications 0 is not a good choice for the initial value of every integer. Someone who forgets to set the integer to an appropriate value will run into the same error as in C, except instead of a trash value, they will find a consistently bad value, which is slightly better. Better to throw an error if an uninitialized value is used, and demand that all struct fields be set unless the struct author has explicitly set default values. > Have you looked into... Yes, I have seen the proposals. I am an opponent to generics in Go. I think Go excels at exactly that which I described in my first post. If you add more to the language, I believe it will morph into a poor mans Java instead of a better Go. Better to simply move to a language that was built from the ground up with the intention of providing abstractions (I like Rust), and use Go when its upsides outweighs its downsides. Many times, they do, especially in businesses where the talent pool is limited.