8 ms·

It is a language for people who like to get things done and get reasonably performant code for free. Relative to folks grinding in some of these dynamic languag

by avl999 5y ago

It is a language for people who like to get things done and get reasonably performant code for free. Relative to folks grinding in some of these dynamic languages doing contortions to deal with basic things like concurrency, twisting themselves into unimaginative ways to get that code coverage bump from 90% to 100% (the hardest part) just because their language cannot provide a semblance of guarantee that code "works" or has no syntax errors unless it is ran, unable to refactor without confidence unless the entire team is willing to commit to 100% test coverage and even with the test coverage the refactorings taking orders of magnitude more time than Go as now you need to parse through your test results to see exactly what your simple refactoring of changing a method name or moving a method from one file to another broke and then fixing it as opposed to the superior tooling of Go (or some other similar statically typed language) just doing all that for you in the press of a few keystrokes. It is also a language for those who like seeing a lower memory foot print, a lower cpu foot print, a simpler distribution story (literally copying over a binary to the target system) The verbosity of Go (and even Java for that matter) is 100% worth it for me for all those reasons. It allows me to iterate fast, make changes with confidence and not have to feel guilty that my test coverage is only 92% because I am not going through the trouble of covering some branches of code that returns an error message (that would otherwise require annoying effort to trigger in your tests) as the compiler guarantees that all those `return errors.New("some error")` will execute if the error condition is ever hit in production which was not the case when I was working in python unless I went through the effort of having my test cover that bit of code.

amirkdv 5y ago
> these dynamic languages doing contortions to deal with basic things like concurrency I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines. But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?
- avl999 5y ago
  Yeah the compiler guarantees that a certain class of errors can never happen and thus you don't need to go through significant effort to cover things like error returns. Additionally with a dynamic language where the codebase has less than a 100% test coverage I would find it very hard to refactor anything without sweating bullets. The compiler is giving you a free test suite.
- tptacek 5y ago
  Because Ruby and Python force you to unit test for typos. I like and use both of them but if you're trying to argue that the testing problem in Python is the same as that of Go or Rust, that argument will fail.
  - amirkdv 5y ago
    > if you're trying to argue that the testing problem in Python is the same as that of Go or Rust Wasn't trying to make that case, but I can see how my comment could be read that way. I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.
  - mixmastamyk 5y ago
    Pyflakes should be the first "test" run, and it finds those kind of issues.
kubb 5y ago
Sounds like you just want a statically typed language, because you've been scarred by Python. I'm sorry that you had to deal with what sounds like poorly maintained medium or large Python code base. After you get some experience with Go, you might want to explore other modern statically typed programming languages (I suggest Kotlin and Rust). When you know the strengths and weaknesses of each, you'll be able to pick the best one for the job. And the concepts learned often translate from one language to the other, which will make it easier to pick up new ones in the future.
- avl999 5y ago
  Rust does not solve the problems that I deal with in the kind of work I do. I have no interest in picking up Kotlin. Java/Go/C# solve all the problems that Kotlin solves without the interop headaches and I pick between them for production code depending on the team and the platform we are targeting. For the projects that I am working on right now I specifically want Go because of its faster startup time than Java/C# and the ability to spin up 10s of thousands of threads without breaking up sweat which is needed for the sort of work I currently do.
  - kubb 5y ago
    The constraints of fast startup + "green threads" + easy deployment are actually a sound argument for using Go. The simplicity of the language isn't. Kotlin and Rust also have the "green threads" [1] that Java lacks, both of them can also produce a native binary giving you fast startup. So the claim that "Java solves all the problems that Kotlin does" is not completely true. Finally both Kotlin and Rust can let you write safer concurrent code, because their type systems actually can enforce constraints on what's shared between threads, and what's immutable and safe to accesss. Go gives you nothing in the type system, but there is a thread sanitizer. [1] Here's a Kotlin program that spins up 100K coroutines: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/test/guide/example-basic-06.kt https://github.com/Kotlin/kotlinx.coroutines/blob/master/kot...
    - vips7L 5y ago
closeparen 5y ago
After four years using Go all day professionally, I agree with all of these pros, and yet, the code volume to impact ratio is just so bad. Everything is very straightforward and understandable, the next step is always clear, I can spend an afternoon grinding out those 500 lines without thinking too much. But then I look back at what was actually accomplished in that time and it feels pathetic. Go is a language for teams. All the cogs in the machine will spin, they will almost never get jammed, but nobody's fingers are fast enough to be particularly more productive than anyone else. Maybe this is the gray reality of mature collaborative software development. But every day I work in Go I get this gnawing feeling that software development could be so much better, that we could have been done weeks ago.
- morelisp 5y ago
  The thing is... that's all the major languages. Even the ones that aren't necessarily like that, the culture / style ends up like that. The Python I'll write and pass review at work is vastly different than the Python I would like to write, because I know the next person isn't going to understand my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it. There's the famous line from GLS about Java: > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. And probably there's some equivalent idea about Go not trying to win over the Clojure programmers, but rather dragging the enterprise Python/Ruby/JS/Java programmers halfway to C.
  - oalae5niMiel7qu 5y ago
    > my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it. That's just Python and its endless edge cases, caused by everything being special-cased into the interpreter. If you were using Lisp, the macro equivalent of your ________dunder________ method would likely have no edge cases, so the next guy who makes a change with only a partial understanding wouldn't end up introducing that performance degradation.

by avl999 5y ago

amirkdv 5y ago

> these dynamic languages doing contortions to deal with basic things like concurrency I get the concurrency gains, esp with older versions of dynamic languages without native support for coroutines. But the test coverage argument seems quite contorted. If you're accepting 92% coverage because the "return an error" lines are not worth testing (fair) then why is that harder to achieve in, say, Ruby or Python? Is the argument that your 92% coverage in Go is _effectively_ 100% because compiler?

avl999 5y ago
Yeah the compiler guarantees that a certain class of errors can never happen and thus you don't need to go through significant effort to cover things like error returns. Additionally with a dynamic language where the codebase has less than a 100% test coverage I would find it very hard to refactor anything without sweating bullets. The compiler is giving you a free test suite.
tptacek 5y ago
Because Ruby and Python force you to unit test for typos. I like and use both of them but if you're trying to argue that the testing problem in Python is the same as that of Go or Rust, that argument will fail.
- amirkdv 5y ago
  > if you're trying to argue that the testing problem in Python is the same as that of Go or Rust Wasn't trying to make that case, but I can see how my comment could be read that way. I was genuinely trying to understand what the parent comment meant. Specifically whether they were saying error control code is _the_ critical but hard to test part of a code base (which I don't think is typically true), or rather error control code is just an example among many of less frequently executed paths in code, which categorically is easier with a static type checker. I think they meant the latter and I don't disagree with that.
- mixmastamyk 5y ago
  Pyflakes should be the first "test" run, and it finds those kind of issues.

kubb 5y ago

Sounds like you just want a statically typed language, because you've been scarred by Python. I'm sorry that you had to deal with what sounds like poorly maintained medium or large Python code base. After you get some experience with Go, you might want to explore other modern statically typed programming languages (I suggest Kotlin and Rust). When you know the strengths and weaknesses of each, you'll be able to pick the best one for the job. And the concepts learned often translate from one language to the other, which will make it easier to pick up new ones in the future.

avl999 5y ago
Rust does not solve the problems that I deal with in the kind of work I do. I have no interest in picking up Kotlin. Java/Go/C# solve all the problems that Kotlin solves without the interop headaches and I pick between them for production code depending on the team and the platform we are targeting. For the projects that I am working on right now I specifically want Go because of its faster startup time than Java/C# and the ability to spin up 10s of thousands of threads without breaking up sweat which is needed for the sort of work I currently do.
- kubb 5y ago
  The constraints of fast startup + "green threads" + easy deployment are actually a sound argument for using Go. The simplicity of the language isn't. Kotlin and Rust also have the "green threads" [1] that Java lacks, both of them can also produce a native binary giving you fast startup. So the claim that "Java solves all the problems that Kotlin does" is not completely true. Finally both Kotlin and Rust can let you write safer concurrent code, because their type systems actually can enforce constraints on what's shared between threads, and what's immutable and safe to accesss. Go gives you nothing in the type system, but there is a thread sanitizer. [1] Here's a Kotlin program that spins up 100K coroutines: https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/test/guide/example-basic-06.kt https://github.com/Kotlin/kotlinx.coroutines/blob/master/kot...
  - vips7L 5y ago

closeparen 5y ago

After four years using Go all day professionally, I agree with all of these pros, and yet, the code volume to impact ratio is just so bad. Everything is very straightforward and understandable, the next step is always clear, I can spend an afternoon grinding out those 500 lines without thinking too much. But then I look back at what was actually accomplished in that time and it feels pathetic. Go is a language for teams. All the cogs in the machine will spin, they will almost never get jammed, but nobody's fingers are fast enough to be particularly more productive than anyone else. Maybe this is the gray reality of mature collaborative software development. But every day I work in Go I get this gnawing feeling that software development could be so much better, that we could have been done weeks ago.

morelisp 5y ago
The thing is... that's all the major languages. Even the ones that aren't necessarily like that, the culture / style ends up like that. The Python I'll write and pass review at work is vastly different than the Python I would like to write, because I know the next person isn't going to understand my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it. There's the famous line from GLS about Java: > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. And probably there's some equivalent idea about Go not trying to win over the Clojure programmers, but rather dragging the enterprise Python/Ruby/JS/Java programmers halfway to C.
- oalae5niMiel7qu 5y ago
  > my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it. That's just Python and its endless edge cases, caused by everything being special-cased into the interpreter. If you were using Lisp, the macro equivalent of your ________dunder________ method would likely have no edge cases, so the next guy who makes a change with only a partial understanding wouldn't end up introducing that performance degradation.