6 ms·

It's totally on point. I've been writing a fair bit of Go lately and consequently am firmly in the Generics! Now! camp. The pace of writing in this language is

by bdamm 8y ago

It's totally on point. I've been writing a fair bit of Go lately and consequently am firmly in the Generics! Now! camp. The pace of writing in this language is almost snail like, and a lot of that is due to re-implementing common idioms like popping and pushing from/to a stack and then debugging the little typos that creep in around the edges. It's freaking annoying, and it's a shame because the language is otherwise nice to work with. If it weren't for the testing workflow I'd have given up on Go entirely, just because of how annoying it is to re-implement the basics, over, and over, and over...

skybrian 8y ago
Do you really need to debug errors from implementing a stack? If you mean compile-time errors, I would look into getting your editor to report them while you type.
- z0r 8y ago
  People constantly screw up the simplest and easiest things, especially when there are hundreds of simple and easy things in a program. And Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.
  - kjksf 8y ago
    I just finished porting 50k loc from Java to Go: https://github.com/ravendb/ravendb-go-client https://github.com/ravendb/ravendb-go-client You won't find hundreds of purported simple/easy things that are exclusive to Go code. There's probably less than 10 cases where I implemented some simple thing (like a set of strings) that Java gave for free because of library function that used generics. Among 50k loc that's background noise.
    - maximente 8y ago
      don't forget the defer keyword: from README: // ... use session session.Close() can be changed to this right after you get a session: defer session.Close()
  - linuxftw 8y ago
    > Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems. This is precisely how I feel, could never capture it in words myself.
- newen 8y ago
  Point is you shouldn't have to implement a stack. I have never had to do that in any language I used except C. Sounds like a nightmare.
  - courtf 8y ago
    Luckily you can implement a stack in 10 very simple lines. And if you don't want to do that, there are many existing implementations.
    - tsimionescu 8y ago
      Well, not ones as efficient as the one showed here, since those can't be expressed in the language as it currently stands.
    - tonyedgecombe 8y ago
      >there are many existing implementations Sounds like JavaScript/Node all over again, which shouldn't surprise anybody as many of the prominent Node developers hopped over to Go.
  - kjksf 8y ago
    push: a = append(a, el) pop: n := len(a) el := a[n-1] a = a[:n-1] It took me, literally, 10 seconds to write.
    - newen 8y ago
      Is that an O(n) implementation of pop? I hope you realize my point.. I looked it up and it's not but the point is that you shouldn't have to worry about these things, including implementation details of trees and hundreds of other data structures.
      - oconnor663 8y ago
        It isn't. It re-slices the backing array and retains its capacity. (Maybe that's what you looked up at the end?)
johan_larson 8y ago
I don't know. I've worked in three different languages for years on end, and they all have different pain points. C++ is too complicated, and generics are part of that complexity. Java has an ok basic language, but the ecosystem is weird and fad-prone, jumping from beans to patterns to annotations to injection, searching for the One True Way. Go is a little too simple, which sometimes leads to rewriting fairly straightforward stuff that a few clever general mechanisms would let us write once. This experience makes me suspect that there will always be some pain point with the language. We'll never be happy; that's impossible. The only thing we can do is choose what type of unhappiness we are willing to live with. The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. And I suspect that whatever complexities we add would compromise this clarity in the name of brevity. I'd spend less time being bored, and more time being puzzled or incredulous. And fundamentally, I'd rather be bored.
- paulddraper 8y ago
  > the ecosystem is weird and fad-prone Won't dispute that but did that materially affect your chosen paradigms and patterns?
  - johan_larson 8y ago
    When I had the opportunity to choose, I felt I could find useful ways of doing things. The problem was that I often had to accommodate myself to someone else's choices that had been made years before, and I had to understand what the heck they had done before I could make useful upgrades. And with many ways of doing things, some of which are hugely reliant on really non-obvious behavior controlled by cryptic settings in control files or annotations, that can be hard.
- snarfy 8y ago
  Have you tried C#?
  - johan_larson 8y ago
courtf 8y ago
I don't agree with this, and I find the pace of writing in Go to be quite quick. I've recently been working on a server that performs arbitrary work pre-defined in DAGs, with an API, full tests and several fancy features. The initial bulk of the work took me about 3 weeks and the only dependency is a test mocking library.
chessturk 8y ago
My work has handled this with autogeneration of things like DB models. I don't know if that would be applicable to what you're doing.
- int_19h 8y ago
  So, basically, textual, non-syntax-aware macros? It's not uncommon to use such in C to define generic data structures and operations, but it's very painful to write and maintain... and besides, it has been widely considered a pain point in C for decades. It shouldn't be necessary in a modern well-designed PL.
JyB 8y ago
I've been working with Go full time for 2+ years. After forcing myself to understand its philosophy and idioms, I surprised myself with not missing generics at all. The language seem to have found a nice spot, hence its success. Strangely, I feel the day Go has generics is the day its attractiveness will start to fade away.

by bdamm 8y ago

skybrian 8y ago

Do you really need to debug errors from implementing a stack? If you mean compile-time errors, I would look into getting your editor to report them while you type.

z0r 8y ago
People constantly screw up the simplest and easiest things, especially when there are hundreds of simple and easy things in a program. And Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems.
- kjksf 8y ago
  I just finished porting 50k loc from Java to Go: https://github.com/ravendb/ravendb-go-client https://github.com/ravendb/ravendb-go-client You won't find hundreds of purported simple/easy things that are exclusive to Go code. There's probably less than 10 cases where I implemented some simple thing (like a set of strings) that Java gave for free because of library function that used generics. Among 50k loc that's background noise.
  - maximente 8y ago
    don't forget the defer keyword: from README: // ... use session session.Close() can be changed to this right after you get a session: defer session.Close()
- linuxftw 8y ago
  > Go makes sure that you have to write a hundred simple and easy things every time you work with it to solve problems. This is precisely how I feel, could never capture it in words myself.
newen 8y ago
Point is you shouldn't have to implement a stack. I have never had to do that in any language I used except C. Sounds like a nightmare.
- courtf 8y ago
  Luckily you can implement a stack in 10 very simple lines. And if you don't want to do that, there are many existing implementations.
  - tsimionescu 8y ago
    Well, not ones as efficient as the one showed here, since those can't be expressed in the language as it currently stands.
  - tonyedgecombe 8y ago
    >there are many existing implementations Sounds like JavaScript/Node all over again, which shouldn't surprise anybody as many of the prominent Node developers hopped over to Go.
- kjksf 8y ago
  push: a = append(a, el) pop: n := len(a) el := a[n-1] a = a[:n-1] It took me, literally, 10 seconds to write.
  - newen 8y ago
    Is that an O(n) implementation of pop? I hope you realize my point.. I looked it up and it's not but the point is that you shouldn't have to worry about these things, including implementation details of trees and hundreds of other data structures.
    - oconnor663 8y ago
      It isn't. It re-slices the backing array and retains its capacity. (Maybe that's what you looked up at the end?)

johan_larson 8y ago

I don't know. I've worked in three different languages for years on end, and they all have different pain points. C++ is too complicated, and generics are part of that complexity. Java has an ok basic language, but the ecosystem is weird and fad-prone, jumping from beans to patterns to annotations to injection, searching for the One True Way. Go is a little too simple, which sometimes leads to rewriting fairly straightforward stuff that a few clever general mechanisms would let us write once. This experience makes me suspect that there will always be some pain point with the language. We'll never be happy; that's impossible. The only thing we can do is choose what type of unhappiness we are willing to live with. The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. And I suspect that whatever complexities we add would compromise this clarity in the name of brevity. I'd spend less time being bored, and more time being puzzled or incredulous. And fundamentally, I'd rather be bored.

paulddraper 8y ago
> the ecosystem is weird and fad-prone Won't dispute that but did that materially affect your chosen paradigms and patterns?
- johan_larson 8y ago
  When I had the opportunity to choose, I felt I could find useful ways of doing things. The problem was that I often had to accommodate myself to someone else's choices that had been made years before, and I had to understand what the heck they had done before I could make useful upgrades. And with many ways of doing things, some of which are hugely reliant on really non-obvious behavior controlled by cryptic settings in control files or annotations, that can be hard.
snarfy 8y ago
Have you tried C#?
- johan_larson 8y ago

courtf 8y ago

I don't agree with this, and I find the pace of writing in Go to be quite quick. I've recently been working on a server that performs arbitrary work pre-defined in DAGs, with an API, full tests and several fancy features. The initial bulk of the work took me about 3 weeks and the only dependency is a test mocking library.

chessturk 8y ago

My work has handled this with autogeneration of things like DB models. I don't know if that would be applicable to what you're doing.

int_19h 8y ago
So, basically, textual, non-syntax-aware macros? It's not uncommon to use such in C to define generic data structures and operations, but it's very painful to write and maintain... and besides, it has been widely considered a pain point in C for decades. It shouldn't be necessary in a modern well-designed PL.

JyB 8y ago

I've been working with Go full time for 2+ years. After forcing myself to understand its philosophy and idioms, I surprised myself with not missing generics at all. The language seem to have found a nice spot, hence its success. Strangely, I feel the day Go has generics is the day its attractiveness will start to fade away.