Go 1.11 got me to stop ignoring Go

Post by Kalium » Tue, Oct 09, 2018, 8:39 PM UTC

raziel2p wrote: post #53

brandur wrote: post #33

A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their…

There's going to be a large group of people (myself included) who graps the system but refuses to use it because it's pointless and stupid. > It's always obvious where your dependencies are located and which versions are going to be used to build your project. More obvious than specifying the version in some dependencies file? > Even better, it lets use very easily drop into those dependencies and add minor changes o…

Post by brandur » Tue, Oct 09, 2018, 8:47 PM UTC

raziel2p wrote: post #53

brandur wrote: post #33

A few years into using Go, I have mixed feelings about `GOPATH`. On one hand, I can see the author's frustration in that it was always incredibly presumptuous of the language's authors to dictate how its users should organize their hard drives, and more so it feels like exactly the type of arrogance that people tend to attribute to the Go's core and community. Also, having helped a number of people now through their…

There's going to be a large group of people (myself included) who graps the system but refuses to use it because it's pointless and stupid. > It's always obvious where your dependencies are located and which versions are going to be used to build your project. More obvious than specifying the version in some dependencies file? > Even better, it lets use very easily drop into those dependencies and add minor changes o…

Post by sebcat » Tue, Oct 09, 2018, 9:06 PM UTC

apta wrote: post #64

sebcat wrote: post #52

Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned. GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a ser…

> something Java, C and other languages failed at before Go was introduced. Java's concurrency solutions are just as good, if not better than golang's. Pair that with libraries such as RxJava and you're definitely ahead. I don't see what golang has to offer in that area that the JVM doesn't

Post by paxy » Tue, Oct 09, 2018, 9:17 PM UTC

sebcat wrote: post #52

Having introduced Golang in a business environment in 2014 and having seen the language solve real problems at that time, at scale, I feel that if your own reason to not use Go is GOPATH... Either Go does not solve any real problems for your use case, or your reasons to use Go is misaligned. GOPATH is really not a problem, but efficient concurrency is. Go made the company I worked for go from 20 deployments for a ser…

Post by dagenix » Tue, Oct 09, 2018, 9:35 PM UTC

sebcat wrote: post #65

apta wrote: post #64

Earlier quoted context omitted.

> something Java, C and other languages failed at before Go was introduced. Java's concurrency solutions are just as good, if not better than golang's. Pair that with libraries such as RxJava and you're definitely ahead. I don't see what golang has to offer in that area that the JVM doesn't

Sounds believable, but at the time we were stuck at 1.6 and had a significant drop in traffic due to JSSE and non-existing support of "modern" TLS Cipher Suites and TLS extensions (we even had problems with SNI, years after introduction)... We were using C because epoll made it possible for us to compete, but the Java reactivex stuff were lagging behind.