4 ms·

Why shouldn’t it be?

by hnarn 3y ago

eweise 3y ago
Too low level and lacks the power to cleanly model the business domain.
- closeparen 3y ago
  Go has pretty powerful composition, reuse, higher-order functions etc. for dealing with byte arrays and streams. Not so much for business domain entities.
- dharmab 3y ago
  "Too low level" "lacks the power" - I don't understand what this means. What are things that are hard to do in Go business applications that other languages do better?
  - rowls66 3y ago
    Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.
    - Cthulhu_ 3y ago
      Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.
  - za3faran 3y ago
    It lacks modeling capability that you'd find even in languages like Java and C#. Enums, records, pattern matching, switch expressions, and yes even inheritance where it makes sense.
    - deleted 3y ago
      [deleted]
  - shakow 3y ago
    > What are things that are hard to do in Go business applications that other languages do better? Streams, meta-programming, enums, ‶modern″ switches, generators, portable types in CGo, streamlined error handling, safer concurrency primitives, nil, partial struct initialization, ...
  - kaba0 3y ago
    Lacks expressivity is likely what parent meant.
wavemode 3y ago
I believe even the language's own designers would agree with that sentiment. There's just generally a lot of things about Go that are great for low-level microservices but not great for 1M+ line of code business applications maintained by large teams. I can't speak for others, but personally if I'm writing software with complex business logic, I'd want null safety, better error handling, a richer type system, easier testing/mocking... I've also never liked that a panic in one goroutine crashes the whole application (you can recover if it's your own code, sure, but not if it happened in a goroutine launched by some library).
- dx034 3y ago
  I'd disagree with most of that, but the panic in goroutines really hits home. It's so annoying to remember implementing recover in every goroutine started to avoid crashing your application. I don't get why there's no global recover option that can recover from panic's in goroutines as well.
  - closeparen 3y ago
    Goroutines are expected to communicate on channels. If one goroutine simply vanishes, then its counterparties on any channels will deadlock - either waiting for messages that never come, or trying to send messages to it after channel buffers fill up. Crash is significantly easier to detect and understand than deadlock.

Why shouldn’t it be?

by hnarn 3y ago

Why shouldn’t it be?

eweise 3y ago

Too low level and lacks the power to cleanly model the business domain.

closeparen 3y ago
Go has pretty powerful composition, reuse, higher-order functions etc. for dealing with byte arrays and streams. Not so much for business domain entities.
dharmab 3y ago
"Too low level" "lacks the power" - I don't understand what this means. What are things that are hard to do in Go business applications that other languages do better?
- rowls66 3y ago
  Here is an example. Go let’s structs be passed by value or by reference. The programmer needs to decide, and that adds complexity that is largely irrelevant for modeling complex business logic. Java does not provide a choice, which keeps it simple.
  - Cthulhu_ 3y ago
    Simple, but with an inherent performance issue and GC load; note also that Java's Valhalla project adds value types with more stack based semantics, so there too you as a developer get a choice.
- za3faran 3y ago
  It lacks modeling capability that you'd find even in languages like Java and C#. Enums, records, pattern matching, switch expressions, and yes even inheritance where it makes sense.
  - deleted 3y ago
    [deleted]
- shakow 3y ago
  > What are things that are hard to do in Go business applications that other languages do better? Streams, meta-programming, enums, ‶modern″ switches, generators, portable types in CGo, streamlined error handling, safer concurrency primitives, nil, partial struct initialization, ...
- kaba0 3y ago
  Lacks expressivity is likely what parent meant.

wavemode 3y ago

I believe even the language's own designers would agree with that sentiment. There's just generally a lot of things about Go that are great for low-level microservices but not great for 1M+ line of code business applications maintained by large teams. I can't speak for others, but personally if I'm writing software with complex business logic, I'd want null safety, better error handling, a richer type system, easier testing/mocking... I've also never liked that a panic in one goroutine crashes the whole application (you can recover if it's your own code, sure, but not if it happened in a goroutine launched by some library).

dx034 3y ago
I'd disagree with most of that, but the panic in goroutines really hits home. It's so annoying to remember implementing recover in every goroutine started to avoid crashing your application. I don't get why there's no global recover option that can recover from panic's in goroutines as well.
- closeparen 3y ago
  Goroutines are expected to communicate on channels. If one goroutine simply vanishes, then its counterparties on any channels will deadlock - either waiting for messages that never come, or trying to send messages to it after channel buffers fill up. Crash is significantly easier to detect and understand than deadlock.