4 ms·

> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for ye

by shakow 4y ago

> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for years, and these features still make no sense to me. > lack of enums Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basically C #define. And I think that the consensus has been, for decades, that having badly typed magical constants was not a good thing. > implicit interfaces Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. > by popular urban myth Tell me exactly who finds that nil pointers are a great thing in a high-level language?

cube2222 4y ago
> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". In general, implicit interfaces let structures and functions require much less by defining their needed functionality subset, instead of requiring the whole "domain interface" from somewhere else. If you have a struct that only needs to list an S3 bucket, it's nice to accept an interface that only requires listing, and not the other 30 methods the AWS library "full" interface has. This makes understanding what a piece of code is doing much easier, while simplifying mocking as well. I do agree that enums, or even better, sum types, would be desirable. It's not a big issue in my day to day, though.
- pjmlp 4y ago
  > Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". And me thinking the Go culture is against languages that tend to come with IDEs...
  - foldr 4y ago
    You don't need an IDE to do that. More or les anything that can hook up with the Go language server will do the job.
    - pjmlp 4y ago
      So somehow needing a language server to work around language design flaws is alright for Go then.
      - foldr 4y ago
        Sarcasm aside, I do think it’s fair to assume that someone writing code in a modern programming language in 2022 has access to basic language-aware editor tooling. That’s the beauty of the language server. You can look up the implementations of an interface from vim, or some other minimalist development environment, if that’s your bag.
        masklinn 4y ago
        "Go is so simple you don't need an IDE to write it, unlike java" "Well obviously you need a proper IDE to protect you from Go's fuckups" Cool.
        foldr 4y ago
        You don’t need an IDE, as I explained in my two preceding posts in this thread. Please at least try to respond to someone who is actually making the arguments that you take yourself to be refuting.
  - 4y ago
deleted 4y ago
[deleted]
saturn_vk 4y ago
> Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Language servers are a thing nowadays, and the standard go one will find all implementations before you finish blinking. Why is this considered harder than whatever you are using to find implementations in your language of choice? > And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. So like every other language with interfaces then? But why are you even compiling in prod at 3AM in the first place?

by shakow 4y ago

cube2222 4y ago

> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". In general, implicit interfaces let structures and functions require much less by defining their needed functionality subset, instead of requiring the whole "domain interface" from somewhere else. If you have a struct that only needs to list an S3 bucket, it's nice to accept an interface that only requires listing, and not the other 30 methods the AWS library "full" interface has. This makes understanding what a piece of code is doing much easier, while simplifying mocking as well. I do agree that enums, or even better, sum types, would be desirable. It's not a big issue in my day to day, though.

pjmlp 4y ago
> Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". And me thinking the Go culture is against languages that tend to come with IDEs...
- foldr 4y ago
  You don't need an IDE to do that. More or les anything that can hook up with the Go language server will do the job.
  - pjmlp 4y ago
    So somehow needing a language server to work around language design flaws is alright for Go then.
    - foldr 4y ago
      Sarcasm aside, I do think it’s fair to assume that someone writing code in a modern programming language in 2022 has access to basic language-aware editor tooling. That’s the beauty of the language server. You can look up the implementations of an interface from vim, or some other minimalist development environment, if that’s your bag.
      - masklinn 4y ago
        "Go is so simple you don't need an IDE to write it, unlike java" "Well obviously you need a proper IDE to protect you from Go's fuckups" Cool.
        foldr 4y ago
        You don’t need an IDE, as I explained in my two preceding posts in this thread. Please at least try to respond to someone who is actually making the arguments that you take yourself to be refuting.
- 4y ago

deleted 4y ago

[deleted]

saturn_vk 4y ago

> Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Language servers are a thing nowadays, and the standard go one will find all implementations before you finish blinking. Why is this considered harder than whatever you are using to find implementations in your language of choice? > And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. So like every other language with interfaces then? But why are you even compiling in prod at 3AM in the first place?