6 ms·

> Coming from languages that have them, it's just hard to take Golang seriously Some people judge the language on their ability to get work done with it. I ge

by LanceH 5y ago

> Coming from languages that have them, it's just hard to take Golang seriously Some people judge the language on their ability to get work done with it. I get generics, but they really don't come up in daily use with the tasks where I use Go. Yes, it would be nice for writing some libraries but you're going through a laundry list of Rust features which don't hamper my ability to get work done at all. I even like Rust, but if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. It's like was Perl was for Unix, but for the cloud instead.

choeger 5y ago
> Some people judge the language on their ability to get work done with it. Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? For me it's crucial that a programming language contains tools that allow me to definitely rule out as many errors as possible. A powerful (and sound) typesystem does just that.
- cloudfifty 5y ago
  It's already self-evident that Go manages that just fine. That's just weird dogma.
- ori_b 5y ago
  How are you finding Idris? or are you more in the Agda camp? If you want to definitely rule out as many errors as possible, dependently typed languages are the state of the art, allowing you to write a sort function that will fail to compile if it returns a list that isn't sorted (eg,https://dafoster.net/articles/2015/02/27/proof-terms-in-idris/ https://dafoster.net/articles/2015/02/27/proof-terms-in-idri..., or https://www.twanvl.nl/blog/agda/sorting https://www.twanvl.nl/blog/agda/sorting). After all, if you can't even prove basic properties about your code from your language, like array accesses being within bounds, are you really using all possible tools to rule out errors at your disposal?
  - choeger 5y ago
    To be fair, I never had a chance to use Idris nor Agda. I don't know how capable I would be to encode the proofs in libraries nor client code. If it's usable, I am all for it. Otoh, I do know that languages like OCaml, Haskell, or Rust take the burden of trivial errors from my shoulders for neglible cost.
    - eyelidlessness 5y ago
      Yeah, that was an insincere gotcha question, and it's a shame that it could potentially undermine other readers' potential value of a higher degree of confidence versus a hypothetically perfect confidence.
- grey-area 5y ago
  Does Rust also have a feature that instills a burning desire to proselytise?
  - choeger 5y ago
    I like Rust mostly for its user-friendly tools. I dislike the compilation model. The type system I already liked even before Rust existed. So, not every String opinion on PL is down to Rust.
  - 5e92cb50239222b 5y ago
    No, I just find discussions like these absolutely hilarious. A Go developer with ten years of experience convinces himself that Go is the gospel and generics are a useless toy and distraction from "real work™", then tries generics and they move from a feature you don't really need to a feature you couldn't possibly live without. Same with every other thing that goes into this language. A thing that's been available elsewhere for literally 3-4 decades. We have some examples in this very thread.
    - grey-area 5y ago
      Your description doesn’t match what I see in this thread at all. Odd that you’re so upset by other people’s choices.
  - lenkite 5y ago
    Yes, all Rust devs get infected with the PROSELTIZE virus. Other languages are desperately trying to develop vaccines.
- fnord123 5y ago
  Maybe they don't want a target directory using 3gb from a clean build.
- AnimalMuppet 5y ago
  > > Some people judge the language on their ability to get work done with it. > Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? A charitable reading of the GP would be that "safety and correctness" would be included in "getting work done", in amounts that are appropriate to the work in question. Your interpretation is... less than charitable.
  - LanceH 5y ago
    Exactly. Go is safe enough. Correctness for most programs is more about making sure it solves the problem correctly, not merely that it guarantees no errors if it runs. That feels like a modern version of "It compiles, I'm done."
cube2222 5y ago
Agreed. I wrote a bunch of Rust, Scala, Haskell, but I still greatly prefer Go, even without generics. I am very happy with the generic container libraries I'll get with generics, but I hope people won't try to be too clever (as they usually do). So far, Go is a language that just rules out a lot of bikeshedding, which I very much appreciate. We'll see how that evolves. I do think premature or wrong abstractions are a much bigger and widespread problem than a lack of abstraction. Also, I really like Go's error handling, it results in error messages in Go projects usually being top-notch (because of explicit handling and wrapping which includes relevant context and human-readable messages).
- garethrowlands 5y ago
  Premature or wrong anything is clearly bad. But is parameterisation a premature or wrong abstraction? I'd say that parameterisation - even in the type language - is the original proven abstraction.
  - cube2222 5y ago
    Yes, in my opinion oftentimes it is. There is a reason why even in mathematics people like to operate on concrete examples to get an intuition. For many, concrete is much easier to understand than abstract. That's the less important point. The more important point is that making your code generic often involves more trickery which makes the code more complex, even if you only use the code once or twice - so that's just effort wasted. The fact that parameterization is a proven abstraction doesn't mean it's good everywhere. Same as I don't agree with the "Clean Code" way of creating a myriad of 4 line functions. Yes, good programmers won't make these mistakes, you can totally handle them. But when arriving at legacy code or open-source projects I greatly prefer to find under-abstraction rather than over-abstraction. To be clear, I'm not against generics, I just agree with the parent of my original message. I'm worried people will overuse them and I don't want a whole laundry list of Rust features in Go. I'm very happy about libraries with type-safe generic B-Trees.
    - Zababa 5y ago
pjmlp 5y ago
That comparison is a disowner for Perl, given its language capabilities.
- mseepgood 5y ago
  It's a disowner for Go given that Perl's philosophy is "more is more" and Go's philosophy is the Wirthian "less is more".
fiedzia 5y ago
> I get generics, but they really don't come up in daily use with the tasks where I use Go. I sort of understand this argument, but I can't really imagine defining queue as something else then <T> wait_for_item() -> T. I've been writing Python for to long to know that wait_for_item() -> any will backfire in production eventually and I don't want that. At some scale (both in code size and amount and scope of dependencies) those problems just become too serious and too common to not have language that deals with that. And Go is way too popular for people to limit its use only for the cases where it currently works.
- LanceH 5y ago
  Define queue using generics, sure. It will be huge for people waiting packages. A specific queue is typically well defined and has a struct in/out. There are times when I've wanted arbitrarily nested JSON that doesn't map into structs very well, but it is uncommon enough.
- LanceH 5y ago
  I guess a better response to this is that I don't use generics a lot when writing Go, but I probably use a lot of packages where they would have been incredibly useful.
eweise 5y ago
I use Go every day and yeah you can your work done with it but not quickly due to typing all the boilerplate.
xedrac 5y ago
> if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. Since the inception of async/await in Rust, it is incredibly quick to whip something like that up. The slowest part might even be the time it takes to compile. Maybe that's what you were referring to?
- theshrike79 5y ago
  The way Go does it is easier to reason with, channels and goroutines are really easy to explain to anyone.
  - xedrac 5y ago
    That does sound a lot easier than Rust's channels and tasks...
heresie-dabord 5y ago
> It's like [what] Perl was for Unix, but for the cloud instead. Perl and Go both have the kind of long-term language stability that I value above all. But Go offers excellent concurrency, networking baked-in, and now even fuzzing. https://go.dev/blog/fuzz-beta https://go.dev/blog/fuzz-beta
thayne 5y ago
I haven't even written that much go, but even with the little I have written, I have felt hindered in my "ability to get work done" by the lack of generics.
pas 5y ago
> Some people judge the language on their ability to get work done with it. I value maintenability (type safety helps prevent unintended consequences) and readability (Haskell and Clojure are out).

by LanceH 5y ago

choeger 5y ago

> Some people judge the language on their ability to get work done with it. Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? For me it's crucial that a programming language contains tools that allow me to definitely rule out as many errors as possible. A powerful (and sound) typesystem does just that.

cloudfifty 5y ago
It's already self-evident that Go manages that just fine. That's just weird dogma.
ori_b 5y ago
How are you finding Idris? or are you more in the Agda camp? If you want to definitely rule out as many errors as possible, dependently typed languages are the state of the art, allowing you to write a sort function that will fail to compile if it returns a list that isn't sorted (eg,https://dafoster.net/articles/2015/02/27/proof-terms-in-idris/ https://dafoster.net/articles/2015/02/27/proof-terms-in-idri..., or https://www.twanvl.nl/blog/agda/sorting https://www.twanvl.nl/blog/agda/sorting). After all, if you can't even prove basic properties about your code from your language, like array accesses being within bounds, are you really using all possible tools to rule out errors at your disposal?
- choeger 5y ago
  To be fair, I never had a chance to use Idris nor Agda. I don't know how capable I would be to encode the proofs in libraries nor client code. If it's usable, I am all for it. Otoh, I do know that languages like OCaml, Haskell, or Rust take the burden of trivial errors from my shoulders for neglible cost.
  - eyelidlessness 5y ago
    Yeah, that was an insincere gotcha question, and it's a shame that it could potentially undermine other readers' potential value of a higher degree of confidence versus a hypothetically perfect confidence.
grey-area 5y ago
Does Rust also have a feature that instills a burning desire to proselytise?
- choeger 5y ago
  I like Rust mostly for its user-friendly tools. I dislike the compilation model. The type system I already liked even before Rust existed. So, not every String opinion on PL is down to Rust.
- 5e92cb50239222b 5y ago
  No, I just find discussions like these absolutely hilarious. A Go developer with ten years of experience convinces himself that Go is the gospel and generics are a useless toy and distraction from "real work™", then tries generics and they move from a feature you don't really need to a feature you couldn't possibly live without. Same with every other thing that goes into this language. A thing that's been available elsewhere for literally 3-4 decades. We have some examples in this very thread.
  - grey-area 5y ago
    Your description doesn’t match what I see in this thread at all. Odd that you’re so upset by other people’s choices.
- lenkite 5y ago
  Yes, all Rust devs get infected with the PROSELTIZE virus. Other languages are desperately trying to develop vaccines.
fnord123 5y ago
Maybe they don't want a target directory using 3gb from a clean build.
AnimalMuppet 5y ago
> > Some people judge the language on their ability to get work done with it. > Really? Safety and correctness aren't relevant for you? Then why even bother with go instead of Python or a Lisp? A charitable reading of the GP would be that "safety and correctness" would be included in "getting work done", in amounts that are appropriate to the work in question. Your interpretation is... less than charitable.
- LanceH 5y ago
  Exactly. Go is safe enough. Correctness for most programs is more about making sure it solves the problem correctly, not merely that it guarantees no errors if it runs. That feels like a modern version of "It compiles, I'm done."

cube2222 5y ago

Agreed. I wrote a bunch of Rust, Scala, Haskell, but I still greatly prefer Go, even without generics. I am very happy with the generic container libraries I'll get with generics, but I hope people won't try to be too clever (as they usually do). So far, Go is a language that just rules out a lot of bikeshedding, which I very much appreciate. We'll see how that evolves. I do think premature or wrong abstractions are a much bigger and widespread problem than a lack of abstraction. Also, I really like Go's error handling, it results in error messages in Go projects usually being top-notch (because of explicit handling and wrapping which includes relevant context and human-readable messages).

garethrowlands 5y ago
Premature or wrong anything is clearly bad. But is parameterisation a premature or wrong abstraction? I'd say that parameterisation - even in the type language - is the original proven abstraction.
- cube2222 5y ago
  Yes, in my opinion oftentimes it is. There is a reason why even in mathematics people like to operate on concrete examples to get an intuition. For many, concrete is much easier to understand than abstract. That's the less important point. The more important point is that making your code generic often involves more trickery which makes the code more complex, even if you only use the code once or twice - so that's just effort wasted. The fact that parameterization is a proven abstraction doesn't mean it's good everywhere. Same as I don't agree with the "Clean Code" way of creating a myriad of 4 line functions. Yes, good programmers won't make these mistakes, you can totally handle them. But when arriving at legacy code or open-source projects I greatly prefer to find under-abstraction rather than over-abstraction. To be clear, I'm not against generics, I just agree with the parent of my original message. I'm worried people will overuse them and I don't want a whole laundry list of Rust features in Go. I'm very happy about libraries with type-safe generic B-Trees.
  - Zababa 5y ago

pjmlp 5y ago

That comparison is a disowner for Perl, given its language capabilities.

mseepgood 5y ago
It's a disowner for Go given that Perl's philosophy is "more is more" and Go's philosophy is the Wirthian "less is more".

fiedzia 5y ago

> I get generics, but they really don't come up in daily use with the tasks where I use Go. I sort of understand this argument, but I can't really imagine defining queue as something else then <T> wait_for_item() -> T. I've been writing Python for to long to know that wait_for_item() -> any will backfire in production eventually and I don't want that. At some scale (both in code size and amount and scope of dependencies) those problems just become too serious and too common to not have language that deals with that. And Go is way too popular for people to limit its use only for the cases where it currently works.

LanceH 5y ago
Define queue using generics, sure. It will be huge for people waiting packages. A specific queue is typically well defined and has a struct in/out. There are times when I've wanted arbitrarily nested JSON that doesn't map into structs very well, but it is uncommon enough.
LanceH 5y ago
I guess a better response to this is that I don't use generics a lot when writing Go, but I probably use a lot of packages where they would have been incredibly useful.

eweise 5y ago

I use Go every day and yeah you can your work done with it but not quickly due to typing all the boilerplate.

xedrac 5y ago

> if I'm going to write a worker that will read from a queue, do a transformation and write to a few more queues/services upon completion, Go just works and the turn around time is far better than Rust. Since the inception of async/await in Rust, it is incredibly quick to whip something like that up. The slowest part might even be the time it takes to compile. Maybe that's what you were referring to?

theshrike79 5y ago
The way Go does it is easier to reason with, channels and goroutines are really easy to explain to anyone.
- xedrac 5y ago
  That does sound a lot easier than Rust's channels and tasks...

heresie-dabord 5y ago

> It's like [what] Perl was for Unix, but for the cloud instead. Perl and Go both have the kind of long-term language stability that I value above all. But Go offers excellent concurrency, networking baked-in, and now even fuzzing. https://go.dev/blog/fuzz-beta https://go.dev/blog/fuzz-beta

thayne 5y ago

I haven't even written that much go, but even with the little I have written, I have felt hindered in my "ability to get work done" by the lack of generics.

pas 5y ago

> Some people judge the language on their ability to get work done with it. I value maintenability (type safety helps prevent unintended consequences) and readability (Haskell and Clojure are out).