Why I’m Frustrated with Go

Post by nooorofe » Sun, Jul 23, 2017, 7:03 PM UTC

fnord123 wrote: post #188

sametmax wrote: post #76

Earlier quoted context omitted.

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. >>> (1,2) > {1: 2} True >And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust: https://…

  In [60]: (1,2) > {1: 2}
  ---------------------------------------------------------------------------
  TypeError                                 Traceback (most recent call last)
   in ()
  ----> 1 (1,2) > {1: 2}

  TypeError: '>' not supported between instances of 'tuple' and 'dict'

Post by nicwolff » Sun, Jul 23, 2017, 7:22 PM UTC

fnord123 wrote: post #188

sametmax wrote: post #76

Earlier quoted context omitted.

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. >>> (1,2) > {1: 2} True >And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust: https://…

Post by brango » Sun, Jul 23, 2017, 7:47 PM UTC

latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

Post by geezerjay » Sun, Jul 23, 2017, 8:03 PM UTC

humanrebar wrote: post #82

searealist wrote: post #43

Earlier quoted context omitted.

> Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. const std::set & s // This is a read-only view. const std::set s // This is immutable. > Another approach is to just declare member variables 'const'. So you have a 'const map ' as a member variable. Except for that to work, you n…

> const std::set s // This is immutable. > Foo() : s(helper()) {} // This is a move, not a copy. First, I'll point out that the data of s is not immutable. The fact that you can const_cast away the const and change the value makes that clear. If people do things like that (or corrupt memory or have race conditions in the code), C++ doesn't necessarily give you clear exceptions or compiler errors. Many of the ways to…

Post by regulation_d » Sun, Jul 23, 2017, 8:40 PM UTC

KallDrexx wrote: post #158

atombender wrote: post #50

Earlier quoted context omitted.

I don't like the "central exception handler" idea -- it is invariably too far away from the error site to do anything intelligent. I do like Erlang's approach with hierarchical error domains ("processes" and "supervisor trees"), and I honestly think Go made a mistake here: The semi-recent introduction of Context acknowledges that a control hierarchy is present and an important part of a concurrent, distributed applic…

I don't think a central exception handler means ONLY handle exception in one very specific point. It means that if you can handle an error handle it, otherwise let the central exception handler handle it. I really like Elixir and the Erlang VM but supervisor trees are not a perfect solution either. For all the talk about how in Erlang you just let things fail and don't have to do defensive coding, any non-trivial app…