14 ms·

Are you saying that python is better than GO on syntax alone? Like easier to review code ...?

by skyde 6y ago

kevincox 6y ago
In many ways yes. The high level code it is far easier to review the semantics of the change. With Go I feel like I am too bogged down in all of the unimportant implementation details. (I don't really care how you implemented `map` I don't need to see the 4 lines of that loop) Of course with minimal static typing it is easy to miss more "typo" style bugs but those tend to be caught fairly easy in tests and are obvious when they fail.
- wahern 6y ago
  > With Go I feel like I am too bogged down in all of the unimportant implementation details. But then when people praise Python and Rust, getting bogged down with "unimportant implementation details" like specialized async typing and colored functions becomes an absolutely essential and useful aspect of the language. There's just no accounting for taste...
  - kevincox 6y ago
    I agree that async creating coloured functions is a compromise. However in practice I don't find it too distracting. At the very least it is less distracting then Go's error handling. (Although IIRC that is going away thankfully) However if you put N:M threading against 1:1 threading then you can argue about that all day. I think the implementations in Rust and Go are very effectively implementations of each model. The threading model difference is *not* something that I hold against Go. It is possible for a language to handle some things well but have other downsides that makes me prefer to avoid it.
- mpfundstein 6y ago
  in all seriousness, but how many golang and python code bases of roughly equally the size have you reviewed and examined? Python is HELL if you are new to a codebase. Everyone has their own conventions, lack of typing means you need to do a lot of guesswork, dynamic calls break up control flow etc. Yes, go is more explicit (lack of generics...), but at least its straightforward. Just compare k8s codebase with nomad with your homegrown stuff. It will likely look a bit like the same sauce...

Are you saying that python is better than GO on syntax alone? Like easier to review code ...?

by skyde 6y ago

Are you saying that python is better than GO on syntax alone? Like easier to review code ...?

In many ways yes. The high level code it is far easier to review the semantics of the change. With Go I feel like I am too bogged down in all of the unimportant implementation details. (I don't really care how you implemented `map` I don't need to see the 4 lines of that loop) Of course with minimal static typing it is easy to miss more "typo" style bugs but those tend to be caught fairly easy in tests and are obvious when they fail.

wahern 6y ago
> With Go I feel like I am too bogged down in all of the unimportant implementation details. But then when people praise Python and Rust, getting bogged down with "unimportant implementation details" like specialized async typing and colored functions becomes an absolutely essential and useful aspect of the language. There's just no accounting for taste...
- kevincox 6y ago
  I agree that async creating coloured functions is a compromise. However in practice I don't find it too distracting. At the very least it is less distracting then Go's error handling. (Although IIRC that is going away thankfully) However if you put N:M threading against 1:1 threading then you can argue about that all day. I think the implementations in Rust and Go are very effectively implementations of each model. The threading model difference is *not* something that I hold against Go. It is possible for a language to handle some things well but have other downsides that makes me prefer to avoid it.
mpfundstein 6y ago
in all seriousness, but how many golang and python code bases of roughly equally the size have you reviewed and examined? Python is HELL if you are new to a codebase. Everyone has their own conventions, lack of typing means you need to do a lot of guesswork, dynamic calls break up control flow etc. Yes, go is more explicit (lack of generics...), but at least its straightforward. Just compare k8s codebase with nomad with your homegrown stuff. It will likely look a bit like the same sauce...