Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

261–270 of 297 posts

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

#261

Post by mi100hael »

vips7L wrote: post #184
mi100hael wrote: post #69

Earlier quoted context omitted.

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?

And then I get a jar. Or maybe a war. Or maybe a zip? And maybe it's a fat jar with all dependencies bundled. Or maybe not and I need to fetch a bunch of deps and configure a classpath. And then I need the right JRE wherever I'm going to run it. And then I can run it like 'java -jar'. Or maybe I need a server like Tomcat. Or maybe something else.

And every time you jump into an existing codebase, you need to scrutinize the docs that are hopefully there to figure out particulars of the build/deploy process.

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

#262

Post by masklinn »

scroot wrote: post #249
masklinn wrote: post #212

Earlier quoted context omitted.

TBF that's pretty directly inherited from the Smalltalk ancestry: just like Smalltalk, Ruby simply doesn't have public (data) fields. Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does. Funnily enough, Self opted for the opposite tack of not having private data fields (although it does have readonly and read/write slots), but you can trivially swap "data…

> Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does. Most Smalltalk browsers do actually offer this capability

The tooling does provide that yes, as it does in e.g. Java. But Ruby does it without tooling, the feature is a runtime message to the class object.

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

#264

Post by apta »

fileeditview wrote: post #204
apta wrote: post #142

Earlier quoted context omitted.

These complaints are usually by people who have not been using modern Java, or who have just been reading or hearing unsubstantiated claims about it. Or who haven't worked in large golang projects to see all the mess it brings with it because of how underpowered it is. Look up libraries like Spark[1] or Javalin[2] and you get something quite light weight. Or DropWizard[3] if you need something more holistic. That bei…

You are right that big (especially enterprise) projects in Go are also a mess. But one of the main reasons is that people have a Java (or C++) background and try to replicate all sorts of complexity.. not because Go is "underpowered". Also if you compare those codebases to Java (again enterprise) projects of a similar size they seem quite readable instantly..

> You are right that big (especially enterprise) projects in Go are also a mess. But one of the main reasons is that people have a Java (or C++) background and try to replicate all sorts of complexity.. not because Go is "underpowered".

That hasn't been my experience at an employer. Their devs mainly had Python and NodeJs experience and similar languages (which is what the first version of the code base was written in), and disliked "enterprisey" code. Somehow, the decision to move to golang was made.

Yet, they somehow managed to come up with their own mess, and yes it is mainly because how underpowered golang is. I keep thinking about how much simpler the code base would be if it were written in Java, let alone something like Kotlin.

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

#266

Post by DuskStar »

_bxg1 wrote: post #258
DuskStar wrote: post #110

Earlier quoted context omitted.

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.

> one of the best parts of the go ecosystem Is it more powerful in some way than the auto-formatters that exist for nearly every other language?

It has one amazing property not shared by any other auto-formatter I'm aware of - it is included with the compiler by default and so is the only formatter in common use. Yes, there are formatters for C++ or Java - but the plural there is not a good thing.

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

#267

Post by baby »

amedvednikov wrote: post #244
baby wrote: post #163

Earlier quoted context omitted.

Options :) But generics :( I'm really hopping that Golang finds a way to either not add generics, or add them in contrained ways. Your example code for generics are very hard to read for example. Rust somehow tackles that with associated types, but since generics are still allowed it's not great imo.

Always interested in feedback, thanks. Why do you find them unreadable, because of the angle brackets? I've considered using struct Repo ⟨T⟩ { db DB } Instead of struct Repo { db DB } The conversion would be done automatically by vfmt.

Because they are too general.

The ultimate test is to read someone else's code and try to figure out what is the actual struct being used in place. You will see that you often have to jump through many many files in order to get a sense of what is actually used in place. This problem becomes even harder when people start nesting generics.

Take a look at associated types in Rust. I think it is a better way to do generics because it forces you to specify the type early. It also prevents nested types that are hard to read like >> (and this is nothing)

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

#268

Post by DuskStar »

networkimprov wrote: post #190
DuskStar wrote: post #110

Earlier quoted context omitted.

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!

I think we're going to have to disagree there, then - yes that oneliner might reduce your LOC count and help you win at code golf, but it doesn't actually make things more readable and certainly isn't worth breaking from the rest of the community.

The ecosystem-wide consistency of go fmt is its biggest strength. Adding switches to disable features would eliminate that.

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

#269

Post by trpc »

hu3 wrote: post #232
trpc wrote: post #128

it's a mediocre language, in fact it's the most mediocre language I have ever seen, that is being pushed by managers who want to lower hosting costs and faster time to market with good runtime performance.

- lower hosting costs - faster time to market - good runtime performance Looks good to me.

good if you're the manager not if you're the dev

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

#270

Post by pjmlp »

jstimpfle wrote: post #257
pjmlp wrote: post #187

Earlier quoted context omitted.

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

UB is not what makes C fast. A good (and fast) program does not contain undefined behaviour, at least ideally. The only speed advantage of Fortran, to my knowledge, comes from pointer aliasing information that C compilers have a harder time to infer. But that's more a consequence of the programming domain. Fortran is not a systems programming language. Fortran has specialized data structures for scientific computing…

Fran Allen begs to differ.

Plus the experience from all from us that had access to early C compilers on CP/M and home micros.

IBM already had a LLVM like toolchain for their RISC research with PL.8 and respective OS.

Only later did they switch to UNIX due to the market they were after.

Surviving mainframes are still writen on their system languages.

As for Fran Allen point of view:

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

Post reply on HN