Live data from Hacker News

Why I Don't Like Golang (2016)

teamten.com

151–160 of 297 posts

Re: Why I Don't Like Golang (2016)

#152

I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…

The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this. But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, C…

> But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, Class, CONSTANT convention.

What "pre-existing conventions" do you see in the Go code that you've had to refactor? The fact that conventions from Java or C++ aren't the same simply reinforces the fact that Go is a different language, and that's A Good Thing.

Re: Why I Don't Like Golang (2016)

#153
post #150
post #79

I have been using Go in production since 2012 and I find it a fantastic tool. Except for point 8 ("The sort.Interface approach is clumsy") the rest are features for me. I am so grateful for the Go creators for having made it as it is. What worries me is the recent changes: modules (never had a problem with GOPATH) and Go 2 proposals. I hope they are able to keep their vision as it started.

Same here, people can complain but the reality is that more and more people find Golang a great language to use day-to-day. Honestly I think it's here to replace Java and to stay. Same as Rust replaced C and C++. That anyone would want to write C/C++ or Java today is absurd, except if they're old.

These are still very niche languages. Go has a better shot, albeit still long, with the weight of Google behind it, but there is an unbelievable amount of inertia. Rust certainly hasn't replaced C/C++ to any real degree yet.

Maybe time will tell, but I'd lay money that there will be a lot of people still working on C, C++ and Java codebases in fifty years, just like there is a boatload of COBOL and even MUMPS software still out there in the wild today.

Re: Why I Don't Like Golang (2016)

#154
post #16

Earlier quoted context omitted.

My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(

Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.

Go's star feature is straightforwardness. Some people call this simplicity. The upshot is that it is very easy to use Go within teams of inconsistent expertise. Since there is a fairly low ceiling to cleverness, Go rewards just getting started rather than spending time making the code smaller, or more general.

Of course, this is not as good for having fun programming, unless the programmer feels having written something is more fun than writing it.

Re: Why I Don't Like Golang (2016)

#155

You’re not forced to use the "imperative verbosity" in the article. The following is shorter and more idiomatic. serializeType := model.SerializeNonArchivedOnly if showArchived { serializeType = model.SerializeAll }

How is this not imperative verbosity?

Not to mention you are mutating an already assigned variable. You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one.

Re: Why I Don't Like Golang (2016)

#157

Earlier quoted context omitted.

You can, but you can't deploy them. If you really want to keep your services separate, you need a separate JVM installation and jars for each service. Go gives you this automatically with a simple binary. Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable.

>> Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable Can you please provide some examples? This would be a useful comparison, as Java had way more time to work on the libraries.

Don't you think it'd be the other way around - the older a language gets, the standard libraries degrade since you can't introduce newer patterns without breaking compatibility.

Re: Why I Don't Like Golang (2016)

#158

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

C is great for some things, but not at others. For instance, the same simplicity you laud makes it very difficult to work with strings or serialization—both are highly manual operations. So—I agree generally with your sentiment, but it's very far from a perfect language. If you're working with word-sized integers it's pretty damn good.

Also, ironically, I feel like C presents an excellent case for an evolved language, not a designed language. Its very name is derived from BCPL, as are many of the semantics and notation.

Post reply on HN