Why I Don't Like Golang (2016) • Hacker News Board

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

#181

Post by paulddraper » Thu, Jun 13, 2019, 4:39 AM UTC

Boxxed wrote: post #95

simias wrote: post #82

Earlier quoted context omitted.

>To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics. Except that clearly history showed that it wasn't enough, and we ended up with about 50 millions (and counting) different meaning for "static" for instance. I like C but its simplicity is almost by accident more than by design. It's pretty far from "perfect" in my book. There are so many weird features…

> Why do we need both . and -> ? The compiler is always able to know which one makes sense from the type of the variable anyway. I've often wondered this myself. The best I can come up with is that the underlying code generation includes an additional dereferencing step with ->, so having both . and -> makes the compiler a little more transparent. Of course, in C++ you really need both because overloading -> is nice…

My guess is they liked the explicitness of it.

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

#182

Post by paulddraper » Thu, Jun 13, 2019, 4:44 AM UTC

mi100hael wrote: post #69

jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

It's not always clear how to do that. Sure, in theory it's possible to manually download JARs, configure your classpath, and run javac. In practice, the wisdom seems to be to replace the old ecosystem with a new ecosystem like Maven -> Gradle or Spring -> Spring Boot. In comparison, the entire standard build process for a Go program is: $ export GOPATH="/path/to/repo" && go get && go build && ./main No config files w…

The tooling is a very valid critique.

Like C/C++, javac is just a compiler.

It's not a a dependency resolver, a runtime, a formatter, etc.

go is all of those things.

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

#183

Post by sriharis » Thu, Jun 13, 2019, 4:44 AM UTC

O hey, there's a subreddit dedicated to this: https://www.reddit.com/r/gobashing/

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

#184

Post by vips7L » Thu, Jun 13, 2019, 4:50 AM UTC

mi100hael wrote: post #69

jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

It's not always clear how to do that. Sure, in theory it's possible to manually download JARs, configure your classpath, and run javac. In practice, the wisdom seems to be to replace the old ecosystem with a new ecosystem like Maven -> Gradle or Spring -> Spring Boot. In comparison, the entire standard build process for a Go program is: $ export GOPATH="/path/to/repo" && go get && go build && ./main No config files w…

The entire build process for java is mvn package. The only xml you encounter in modern java will be your pom.xml. How is that any different from a package.json, go.mod, cargo.toml, or Pipfile?

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

#185

Post by pjmlp » Thu, Jun 13, 2019, 4:59 AM UTC

gerbilly wrote: post #31

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…

Yes and I wasn't that impressed, given that I already had a experience with several other languages, including for doing low level stuff.

What impresses me is reading Burroughs manuals, or the manuals, books and research papers from Xerox PARC and IBM in the 70's.

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

#186

Post by vips7L » Thu, Jun 13, 2019, 5:01 AM UTC

sdegutis wrote: post #67

jayd16 wrote: post #64

Earlier quoted context omitted.

I see this complaint against Java a lot. If you're going to slum it in a language with no ecosystem so you don't feel overwhelmed, why not just use less of the Java ecosystem?

Not OP, but in my experience, it's harder to know how to get from System.out.println("hello world") to GET / in a browser showing " hello world ", without adopting some intensely documented framework and infrastructure, along with obscure XML configuration files. I liked that aspect of Clojure, but I wouldn't have a clue how to achieve the same thing in pure Java.

This is patently false. Getting to hello world is as simple as knowing how to add a dependency, just like any other language and requires 0 xml. See javalin [0], or spark [1].

[0] https://javalin.io/ [1] http://sparkjava.com/

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

#187

Post by pjmlp » Thu, Jun 13, 2019, 5:05 AM UTC

tx-0 wrote: post #106

lmm wrote: post #52

Earlier quoted context omitted.

Can't say I got that feeling at all. Smalltalk is a tight design. So is Lisp. So is Forth. So is APL. C's design just feels like a pile of... stuff. Arrays are almost but not quite the same as pointers. You can pass functions but not return them. There's a random grab-bag of control flow keywords, too many operators with their own precedence rules, and too many keywords given over to a smorgasbord of different intege…

but you can't pass functions in C, you can only pass pointers-to-functions... and you can return them too. the piles of stuff that C contains are the stuff of 20th century von Neumann architectures, the stuff that defines the undefined behaviors, and that's what has made C indispensible. I'm not saying C's perfect, but you can't swap it out without replacing what it did and does.

UB is what makes C fast versus what PL/I variants and Fortran optimisers were already able to do without such tricks.

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

#188

Post by pjmlp » Thu, Jun 13, 2019, 5:09 AM UTC

jayd16 wrote: post #65

sdegutis wrote: post #56

Earlier quoted context omitted.

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…

WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.

A design introduced by Eiffel, copied by Delphi, before Anders went to Microsoft designed J++ and then C#, with the said feature.

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

#189

Post by lacker » Thu, Jun 13, 2019, 5:12 AM UTC

DaveInTucson wrote: post #123

I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.

If you work for a while at a larger company that enforces a style guide, it starts to make total sense. If your company's style guide already insists that identifiers should be named with some convention that matches their visibility, then by making that part of the language, you are simplifying the system.

I would not be surprised if specifically the Google C++ style guide influenced this decision.

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

#190

Post by networkimprov » Thu, Jun 13, 2019, 5:14 AM UTC

DuskStar wrote: post #110

networkimprov wrote: post #12

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 :-(

Banning go fmt gets rid of one of the best parts of the go ecosystem, and I am horrified that you would do so. go fmt may not be anyone's favorite code style, but having go fmt is so much better than dealing with everyone else's favorite (incompatible!) styles.

There is no spec for go fmt. Its behavior has changed across releases.

It has no switches to disable features.

It destroys many nice single-line constructs, e.g.

    if err != nil { return err }

Much of my code would be painful to read without that one.

On the bright side, it artificially inflates your line count, so you appear more productive!