5 ms·

Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in th

Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.

setr 6y ago
the solution is... to not use Golang! more specifically, fairly basic operations on a list of data does not seem like it should call for the complexity of a DSL. IMO unless you need to do this quite a bit on random datatypes, copy & paste would probably be the better alternative. Unless you're referring to a DSL that looks exactly like Golang but with generics & monomorphism.... in which case ok I guess
- pjmlp 6y ago
  When that solution is possible, sometimes project requirements make us use tools that we rather not, but have to.
mhh__ 6y ago
If you do that you have no soul. Why complicate it when you can just have generics that work from the get go
- Cthulhu_ 6y ago
  Because generics is a nontrivial problem to solve in languages and compilers; a really great comment that I bookmarked is here: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417. I read elsewhere (can't find it now) just how much lines of code and language spec is dedicated to generics in Java. Right now, the Go spec + compiler chain are a lot simpler; adding generics would have made things a ton more complicated. Second, by first spending a lot of time perfecting the core language, understanding it, and resolving early issues, they have a much more stable base now to build generics on top of it. As the comment also implies, they take things slow and steady when it comes to Go; it's a language made to run core systems (e.g. at Google) for the next 30-50 years.
  - mhh__ 6y ago
    All I can say to that is: Taking Java and C++ to be generics as god intended is not a particularly good thing to plan around. D's generics are concise, strict, relatively simple, and mostly understandable by mere mortals (in the compiler) - this is a totally solved problem for a language like D, if Go can't do it then it's their own fault.
bee_rider 6y ago
Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.
- pjmlp 6y ago
  This is how C++ compilers used to work before templates came into the picture. For example Borland's BIDS 1.0 in Borland C++ for MS-DOS, it was based on the C pre-processor, as you would define a set of macros and then include the desired type, something like #define LIST_T int #include <bids/list.h> #define LIST_T float #include <bids/list.h> and so on, however when BIDS 2.0 was released, there was already primitive support for the ongoing ISO discussions and it was rewritten to use templates. To be fair, Go generics seem to be finally on their way to be adopted into the language.
- xmprt 6y ago
  We have a lot of codegen in our codebase right now and I can't wait for the day that generics are finally added.
  - pjmlp 6y ago
    As heavy critic, but also fan, I have been following up on it, and the last update on the document is from September, so I am positive they might make it, it just appears the proper implementation still has some engineering challenges. https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
- Joker_vD 6y ago
  Well, and there is also kinda sorta support foir generics on top of it: https://github.com/vasilevp/aboriginal https://github.com/vasilevp/aboriginal There is no engineering challenge that can't be overcome by ingenious thought!
vips7L 6y ago
Instead of just using an actual good language?! Go is the problem!
- hazz99 6y ago
  "Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.
  - ironmagma 6y ago
    Kind of, but C and Python have undergone many iterations to try to become as good as they can be, while Go has lagged behind and almost prides itself on how uncomplex it is which is unfortunate only because people crave for it to be more complex. With languages like C and Python, the complexity and capability is there; it’s on you to decide when to use it. With Golang, you are just SOL.
    - Philip-J-Fry 6y ago
      The thing is, do you want so many iterations to get something close to being good. Or do you want people to work with the community and decide together what a feature should look like and then get it in a good shape at day 1. Like, ask any python dev what dependency management is like. That's what iteration gets you. Take your time and you get in a much better shape.
      - ironmagma 6y ago
        Thing is, I’m not convinced Go is actually “taking their time,” it’s just intentionally crap and there won’t be any significant improvements. Generics have been “coming” since the language became popular ~10 years ago.
  - vips7L 6y ago
    I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it. This is stockholm syndrome.
spullara 6y ago
Ah the original templates from C++.
dmitriid 6y ago
> Sounds to me like a job for a DSL that compiles down to Golang for the final output. So, you mean it's the job for generics. Which is a DSL for, well, generic types that compiles to final output. That way, the repeated code doesn't even exist, especially not in the code that humans actually write.

Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.

setr 6y ago

the solution is... to not use Golang! more specifically, fairly basic operations on a list of data does not seem like it should call for the complexity of a DSL. IMO unless you need to do this quite a bit on random datatypes, copy & paste would probably be the better alternative. Unless you're referring to a DSL that looks exactly like Golang but with generics & monomorphism.... in which case ok I guess

pjmlp 6y ago
When that solution is possible, sometimes project requirements make us use tools that we rather not, but have to.

mhh__ 6y ago

If you do that you have no soul. Why complicate it when you can just have generics that work from the get go

Cthulhu_ 6y ago
Because generics is a nontrivial problem to solve in languages and compilers; a really great comment that I bookmarked is here: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417. I read elsewhere (can't find it now) just how much lines of code and language spec is dedicated to generics in Java. Right now, the Go spec + compiler chain are a lot simpler; adding generics would have made things a ton more complicated. Second, by first spending a lot of time perfecting the core language, understanding it, and resolving early issues, they have a much more stable base now to build generics on top of it. As the comment also implies, they take things slow and steady when it comes to Go; it's a language made to run core systems (e.g. at Google) for the next 30-50 years.
- mhh__ 6y ago
  All I can say to that is: Taking Java and C++ to be generics as god intended is not a particularly good thing to plan around. D's generics are concise, strict, relatively simple, and mostly understandable by mere mortals (in the compiler) - this is a totally solved problem for a language like D, if Go can't do it then it's their own fault.

bee_rider 6y ago

Googling about this (I assumed the actual 'solution' would be a to use C-style awful macro kludges) eventually lead me to: https://blog.golang.org/generate https://blog.golang.org/generate Now I'm wondering if you joke was not actually a joke.

pjmlp 6y ago
This is how C++ compilers used to work before templates came into the picture. For example Borland's BIDS 1.0 in Borland C++ for MS-DOS, it was based on the C pre-processor, as you would define a set of macros and then include the desired type, something like #define LIST_T int #include <bids/list.h> #define LIST_T float #include <bids/list.h> and so on, however when BIDS 2.0 was released, there was already primitive support for the ongoing ISO discussions and it was rewritten to use templates. To be fair, Go generics seem to be finally on their way to be adopted into the language.
xmprt 6y ago
We have a lot of codegen in our codebase right now and I can't wait for the day that generics are finally added.
- pjmlp 6y ago
  As heavy critic, but also fan, I have been following up on it, and the last update on the document is from September, so I am positive they might make it, it just appears the proper implementation still has some engineering challenges. https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
Joker_vD 6y ago
Well, and there is also kinda sorta support foir generics on top of it: https://github.com/vasilevp/aboriginal https://github.com/vasilevp/aboriginal There is no engineering challenge that can't be overcome by ingenious thought!

vips7L 6y ago

Instead of just using an actual good language?! Go is the problem!

hazz99 6y ago
"Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.
- ironmagma 6y ago
  Kind of, but C and Python have undergone many iterations to try to become as good as they can be, while Go has lagged behind and almost prides itself on how uncomplex it is which is unfortunate only because people crave for it to be more complex. With languages like C and Python, the complexity and capability is there; it’s on you to decide when to use it. With Golang, you are just SOL.
  - Philip-J-Fry 6y ago
    The thing is, do you want so many iterations to get something close to being good. Or do you want people to work with the community and decide together what a feature should look like and then get it in a good shape at day 1. Like, ask any python dev what dependency management is like. That's what iteration gets you. Take your time and you get in a much better shape.
    - ironmagma 6y ago
      Thing is, I’m not convinced Go is actually “taking their time,” it’s just intentionally crap and there won’t be any significant improvements. Generics have been “coming” since the language became popular ~10 years ago.
- vips7L 6y ago
  I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it. This is stockholm syndrome.

spullara 6y ago

Ah the original templates from C++.

dmitriid 6y ago

> Sounds to me like a job for a DSL that compiles down to Golang for the final output. So, you mean it's the job for generics. Which is a DSL for, well, generic types that compiles to final output. That way, the repeated code doesn't even exist, especially not in the code that humans actually write.