5 ms·

Not trying to belittle you or anything, but I have a hard time understand why someone would use Go without Goroutine and Channel.

by dikei 5y ago

grey-area 5y ago
If you want to compare languages on features, lack of complexity is also a feature.
- kaba0 5y ago
  But lack of proper abstractibility, expressivity is not a “feature”.
  - jhoechtl 5y ago
    After all, abstraction is a layer of indirection, hiding meaning. What is a "proper abstraction"?
    - kaba0 5y ago
      Feel free to add together the set of a set of an empty set and a set of a set of a set of an empty set, but I prefer calling it 2+3. Or feel free to manipulate the voltage in some wire, and make sure that it is reliably understood at the other side as the same bit pattern you sent, but I prefer issuing an HTTP packet. These are all abstractions, hell, there is no field building as much on abstractions as IT does. We have to be on like 8-9 levels of abstraction to even do anything non-trivial.
  - grey-area 5y ago
    Lack of other people's abstractions is a feature too :)
    - kaba0 5y ago
      If it is a bad abstraction, sure. But a good abstraction is much much easier to understand then God knows how many lines of code with God knows what program flow.
  - deleted 5y ago
    [deleted]
  - nikki93 5y ago
    I don't think goroutines / channels is a clear win or even that relevant for data-oriented gameplay code. I go into this more in-depth in this comment: https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_simple_goc_compiler_to_use_for_gameplay/hm93ycc https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_si... (it addresses a bunch of points) This is what the game code looks like: https://gist.github.com/nikki93/0425d9ead9eb7810075434d006f3b790?ts=2 https://gist.github.com/nikki93/0425d9ead9eb7810075434d006f3... -- I don't think CSP helps much to improve on that while keeping serializability of state.
nikki93 5y ago
I'll read your statement as a question and answer that. I was using C++ for data-oriented gameplay coding, and I was interested in exploring making a language frontend that compiles to it to clean it up, as a side project (lots of dark corners to run into with C++, and I collected some experience on what those were since I'm managing a C++ game engine codebase at work). I needed a core that was basically a cleaned up C, which is what the C-ish core of Go is (the part other than goroutines, channels and GC), and Go has a good parser and typechecker library you can use. Goroutine and channel are cool for distributed server code or whatever, but not actually that useful for game programming. The main thing is having structs, procedures, some nice ergonomics over those (slices, type inference, non-escaping lambdas, occasional generics) and then metaprogramming so you can reflect over the data structures and have serialization and inspector UI. These are the elements actually relevant to game programming.
- jhgb 5y ago
  > I needed a core that was basically a cleaned up C Why didn't you consider D in 'Better C' mode? (https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html) Not only does it already exist but with very high likelihood is more polished (by virtue of the man-years already invested into D) than a single person's ad-hoc compiler of a subset of Go to C++ could probably be. Unless of course you absolutely needed to use some pre-existing Go code...
  - nikki93 5y ago
    I actually tried D as part of this exploration. I forget but it was confusing which of dmd or the llvm one to use, and ultimately the language ergonomics were not that much of an improvement over C++. Like "auto" is still super weird. I'm going for an actual improvement here, not another botched but slightly improved thing from the past. I think D's tooling worked the least stable-ly out of the box of everything I tried. It wasn't promising. That said, D was one of the things I explored the semantics of for ideas, and it's good that it tries to do the metaprogramming stuff. UFCS is also ok but needing to decide foo(o) and o.foo() at each callsite is actually mental overhead vs. the choice being decided in Go (I wrote the whole engine and game in Nim before so I have experience with this). Just because something has a bunch of years in it doesn't mean it's a good idea for a specific context. The transpiler I have here is just 1500 lines of code and captures all the semantics it currently supports. It uses Go's parser and typechecker from the stdlib and feels on the whole more polished than D as a result (generics are definition-checked, Go's package / module system just work, all the existing Go editor support and godoc etc. just work, ...). It's much easier and straightforward to metaprogram by just editing this simple piece of logic than squeezing it into language features (I've also done the same engine in Nim, explored in Zig, and written it once over in C++). I can, for example, make it so if you mark a function a certain way, it's also compiled to GLSL and useable as a shader (with structs shared). Or make it so types marked a certain way have all their pointers reference counted. There's way more control in this scenario, and the point is to have control to take matters into one's own hands and actually improve things.
dgellow 5y ago
Go without goroutines is still the same simple, straightforward language that people love to work with. The vast majority of Go code being written doesn't use goroutines.

Not trying to belittle you or anything, but I have a hard time understand why someone would use Go without Goroutine and Channel.

by dikei 5y ago

Not trying to belittle you or anything, but I have a hard time understand why someone would use Go without Goroutine and Channel.

grey-area 5y ago

If you want to compare languages on features, lack of complexity is also a feature.

kaba0 5y ago
But lack of proper abstractibility, expressivity is not a “feature”.
- jhoechtl 5y ago
  After all, abstraction is a layer of indirection, hiding meaning. What is a "proper abstraction"?
  - kaba0 5y ago
    Feel free to add together the set of a set of an empty set and a set of a set of a set of an empty set, but I prefer calling it 2+3. Or feel free to manipulate the voltage in some wire, and make sure that it is reliably understood at the other side as the same bit pattern you sent, but I prefer issuing an HTTP packet. These are all abstractions, hell, there is no field building as much on abstractions as IT does. We have to be on like 8-9 levels of abstraction to even do anything non-trivial.
- grey-area 5y ago
  Lack of other people's abstractions is a feature too :)
  - kaba0 5y ago
    If it is a bad abstraction, sure. But a good abstraction is much much easier to understand then God knows how many lines of code with God knows what program flow.
- deleted 5y ago
  [deleted]
- nikki93 5y ago
  I don't think goroutines / channels is a clear win or even that relevant for data-oriented gameplay code. I go into this more in-depth in this comment: https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_simple_goc_compiler_to_use_for_gameplay/hm93ycc https://www.reddit.com/r/golang/comments/r2795t/i_wrote_a_si... (it addresses a bunch of points) This is what the game code looks like: https://gist.github.com/nikki93/0425d9ead9eb7810075434d006f3b790?ts=2 https://gist.github.com/nikki93/0425d9ead9eb7810075434d006f3... -- I don't think CSP helps much to improve on that while keeping serializability of state.

nikki93 5y ago

I'll read your statement as a question and answer that. I was using C++ for data-oriented gameplay coding, and I was interested in exploring making a language frontend that compiles to it to clean it up, as a side project (lots of dark corners to run into with C++, and I collected some experience on what those were since I'm managing a C++ game engine codebase at work). I needed a core that was basically a cleaned up C, which is what the C-ish core of Go is (the part other than goroutines, channels and GC), and Go has a good parser and typechecker library you can use. Goroutine and channel are cool for distributed server code or whatever, but not actually that useful for game programming. The main thing is having structs, procedures, some nice ergonomics over those (slices, type inference, non-escaping lambdas, occasional generics) and then metaprogramming so you can reflect over the data structures and have serialization and inspector UI. These are the elements actually relevant to game programming.

jhgb 5y ago
> I needed a core that was basically a cleaned up C Why didn't you consider D in 'Better C' mode? (https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html) Not only does it already exist but with very high likelihood is more polished (by virtue of the man-years already invested into D) than a single person's ad-hoc compiler of a subset of Go to C++ could probably be. Unless of course you absolutely needed to use some pre-existing Go code...
- nikki93 5y ago
  I actually tried D as part of this exploration. I forget but it was confusing which of dmd or the llvm one to use, and ultimately the language ergonomics were not that much of an improvement over C++. Like "auto" is still super weird. I'm going for an actual improvement here, not another botched but slightly improved thing from the past. I think D's tooling worked the least stable-ly out of the box of everything I tried. It wasn't promising. That said, D was one of the things I explored the semantics of for ideas, and it's good that it tries to do the metaprogramming stuff. UFCS is also ok but needing to decide foo(o) and o.foo() at each callsite is actually mental overhead vs. the choice being decided in Go (I wrote the whole engine and game in Nim before so I have experience with this). Just because something has a bunch of years in it doesn't mean it's a good idea for a specific context. The transpiler I have here is just 1500 lines of code and captures all the semantics it currently supports. It uses Go's parser and typechecker from the stdlib and feels on the whole more polished than D as a result (generics are definition-checked, Go's package / module system just work, all the existing Go editor support and godoc etc. just work, ...). It's much easier and straightforward to metaprogram by just editing this simple piece of logic than squeezing it into language features (I've also done the same engine in Nim, explored in Zig, and written it once over in C++). I can, for example, make it so if you mark a function a certain way, it's also compiled to GLSL and useable as a shader (with structs shared). Or make it so types marked a certain way have all their pointers reference counted. There's way more control in this scenario, and the point is to have control to take matters into one's own hands and actually improve things.

dgellow 5y ago

Go without goroutines is still the same simple, straightforward language that people love to work with. The vast majority of Go code being written doesn't use goroutines.