Live data from Hacker News

Go 1.11 got me to stop ignoring Go

drewdevault.com

71–79 of 79 posts

Re: Go 1.11 got me to stop ignoring Go

#71
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…

> Even better, it lets you very easily drop into those dependencies and add minor changes or debugging lines if you need to. This can be incredibly useful if you're trying to understand how one of them works or think that that you might have found a bug and trying to verify or patch it.

You should totally check out Roger Peppe's gohack[1] It enables you to do the same in a Go modules world

https://github.com/rogpeppe/gohack

Re: Go 1.11 got me to stop ignoring Go

#72
post #65
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.

Why couldn't you have just put a reverse proxy in front of your java?

Re: Go 1.11 got me to stop ignoring Go

#73

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because…

Having written a lot of C++, constructors are a bad idea. Two main reasons:

1. Error handling is difficult - they don't return anything, so you are forced to use exceptions, and throwing exceptions in constructors is awkward. Go doesn't even have exceptions so it can't do that.

2. They don't have names. Often this is fine - you only have one way to construct an object. But if you have more than one, then you have two unnamed functions that do different things. And if they have the same parameters you end up with crazy workarounds like adding dummy parameters.

The way Rust does it is far superior. Basically you have a static function that creates the object. It's a normal function, so it can return errors (or the object), and you can name it, so you can have `Circle::new_with_radius(float r)` and `Circle::new_with_diameter(float d)` with no confusion.

Much better.

Re: Go 1.11 got me to stop ignoring Go

#74

My biggest problem with Go is the lack of a constructor. I don't feel that a struct type is good enough to enforce data integrity and as you have a more complex program, you need to know that the object you are being passed has data integrity. With a constructor, I can force data to conform to what I need it to. I can ensure that certain fields are not nil, that they conform to a specific list of values, etc. Because…

How about just using the builder pattern?

Not familiar with go or that pattern but is this a good example? https://gist.github.com/vaskoz/10073335

Re: Go 1.11 got me to stop ignoring Go

#75
post #64
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

But then you have to write java

Re: Go 1.11 got me to stop ignoring Go

#76

Earlier quoted context omitted.

How about just using the builder pattern?

Not familiar with go or that pattern but is this a good example? https://gist.github.com/vaskoz/10073335

have an initSomething() that returns an initialized struct.

Re: Go 1.11 got me to stop ignoring Go

#77
post #15

> I have major gripes with PEP-8, and if you ever see me using it I want you to shoot me in the face. That sounds extreme. I've never heard this before. Why?

IIRC, pep8 would have you write: def my_very_very_very_very_very_long_function_name(self, param1, param2):

if your function name is that long, you have a problem

Re: Go 1.11 got me to stop ignoring Go

#79
post #49
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…

As someone who hasn't used Go, it sounds like GOPATH is very similar to an Eclipse IDE Workspace.

Now you mention it, it sorta is; I haven't used eclipse, but I've never stopped putting all of my projects into a single folder called "workspace" in my home directory.

The main difference would be that all dependencies are also in this folder, instead of e.g. a maven or ivy folder located somewhere else. And a (suggested?) folder structure, not dissimilar to java's package structure, where you'd put your e.g. github.com/user/repo repository into $GOPATH/src/github.com/user/repo. I'm sure there's clever tooling or commandline wizardry that works really well with a structure like that.

Post reply on HN