Live data from Hacker News

Ask HN: Go programming language is over ten years old. What do you think of it?

news.ycombinator.com

241–250 of 310 posts

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#241
post #215

Earlier quoted context omitted.

Java might in theory be faster but I have never seen a real Java team put out code that was capable of doing 10k requests per CPU per second. Always hitting per thread limits or logging lock contention or GC issues etc. except one thing written by a genius with NIO. Ordinary people can hit those performance numbers with Go and without special smarts.

Don't mistake the tooling capabilities with those that use them.

Of course one shouldn't mistake those. But one has to understand, a tool is only as valuable as it actually produces result, not as what it could produce given a theoretical perfect programmer. C is an extremely capable programming language judging on "what you could do with it", but in reality, most programmers fail to create robust C code. And most Java code suffers from programmers using it in a less than optimal manner.

Also, Go does not suffer from some fundamental Java problems, though they slowly get corrected. Go has value types, unboxed arrays. Generally, no struct in Go is boxed automatically. You have first class functions in Go and of course, it is statically compiled. It is true, that Hotspot often produces very good code, but for a lot of szenarios, a statically compiled Go executable beats it, as run-time compilation is not required.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#242

Earlier quoted context omitted.

Lack of real enums is one of my biggest annoyances with Go. So so many times I've put the wrong enum value in because it's just an int and it matches another set of enums. I've taken to putting each set of enums into a separate file and separate folder just to help the compiler catch this. The project I'm working on now has about 25 separate enum files+folders. Gagh!

I made this playground: https://play.golang.org/p/S1Yh0Oq24q- There are a ways to do unique enums with implicit repetition. Like this: I 0 1 2 II 101 102 103 III 201 202 203 IV 10 20 40 80

Yes and no. Most of the time my enums are well defined: ContactStatus, AwardLevel, JugeStatus, for example. I have not control over the names or values and all have a "Revoked" value. When they come in from an external system it's pretty easy to parse them and convert them to the wrong type if someone isn't paying close attention. Then they don't get caught for a week or so because the code compiles, runs, and appears to work correctly except for these occasional odd results.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#243
post #241
post #215

Earlier quoted context omitted.

Don't mistake the tooling capabilities with those that use them.

Of course one shouldn't mistake those. But one has to understand, a tool is only as valuable as it actually produces result, not as what it could produce given a theoretical perfect programmer. C is an extremely capable programming language judging on "what you could do with it", but in reality, most programmers fail to create robust C code. And most Java code suffers from programmers using it in a less than optimal…

Java also has AOT compilation to native code, if one is willing to pay for such tools (since around 2000, but now there is free beer AOT anyway).

Value types are around the corner and I bet they will be done first than generics in Go.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#244
post #243
post #241

Earlier quoted context omitted.

Of course one shouldn't mistake those. But one has to understand, a tool is only as valuable as it actually produces result, not as what it could produce given a theoretical perfect programmer. C is an extremely capable programming language judging on "what you could do with it", but in reality, most programmers fail to create robust C code. And most Java code suffers from programmers using it in a less than optimal…

Java also has AOT compilation to native code, if one is willing to pay for such tools (since around 2000, but now there is free beer AOT anyway). Value types are around the corner and I bet they will be done first than generics in Go.

As I wrote, Java is in the process of adding features that mitigate its problems. My post was pointing out a few things where Go is clearly ahead of Java.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#245
post #194

Earlier quoted context omitted.

For me personally, with also nearly 2 decades of C# and C++, exceptions is the best possible way to handle errors there is, especially for large projects. I have worked on projects which were built on exceptions, and on projects which were built on return codes. Exceptions is hands down the cleanest. Instead of becoming a mess of call/error handle blocks, you code can clearly separate business logic and error handlin…

And for me having worked in both, errors as return values have been hands down better. The complexity added by an entirely different flow control has resulted in far more bugs for me to track down than anything else. Similarly, it's for good reason that there's a whole other class of languages using things like the Result monad over throwing up all over everything. That's not to say that there isn't better code writt…

I'm pretty sure exceptions are better, for a couple of reasons.

The first is that the idea all Go programmers reliably propagate or wrap error codes, without losing important context, is not true. One of my first encounters with a serious Go codebase was at a consulting client, where I had a task to use their API. I sent it some input and got back a 500 Internal Server Error, no other info. OK, not ideal, but it was in development so I asked them to check the logs and find out what was going wrong. Guess what, the logs were useless. It logged at one or two places that an error had occurred, mostly close to the top level HTTP loop, but the actual location where the error was originated had been lost. Several layers in this app would convert error codes from one level of abstraction to another, also losing information. They shrugged, mystified. Just try things until you figure out what the issue is.

With exceptions this could not have happened. An exception has a stack trace. The developer needs do no work to get this valuable debugging aid, it's always there unless some bad code strips it somehow. Additionally, exceptions can wrap each other as causes, so code can work at high levels of abstraction whilst developers who are debugging can get precise error data from deep down the stack.

Another problem is the idea that Go developers never forget to propagate errors. Error handling in Go is tedious and there's no visible indication if you forget to do it or don't do it properly so sometimes it goes AWOL. The exceptional control flows still exist, just as they would if using exceptions, but now you have to write them manually instead of having the compiler write them for you.

A final problem is performance. Go has notoriously quite low performance, the people who say it's fast are usually comparing it to something like Python. Scattering hand written error handling code all over the place makes it harder for a compiler to move it out of the hot paths, because it's just a bunch of if statements. Exceptions by their nature tell the compiler that those error-handling edges won't execute very often, so they can be put out of the way in places that won't pollute the icache.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#246
post #244
post #243

Earlier quoted context omitted.

Java also has AOT compilation to native code, if one is willing to pay for such tools (since around 2000, but now there is free beer AOT anyway). Value types are around the corner and I bet they will be done first than generics in Go.

As I wrote, Java is in the process of adding features that mitigate its problems. My post was pointing out a few things where Go is clearly ahead of Java.

Only on support for value types, everything else Java did it first.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#247
I learned it in 2014 and have been using it ever since.

I think the backward compatibility has been the number one feature for me followed by the tooling and batteries included standard library.

It is nice to be able to do most things without depending on a 3rd party library.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#248
post #57

Speaking strictly about the language, and not the platform, I'm skeptical about the lack of more modern core library and language features like immutability, pattern matching, and records. They spent almost 10 years saying "we don't need generics", but now are implementing it Also, the dependency management.

> They spent almost 10 years saying "we don't need generics", but now are implementing it You're making things up. Not a single member of the Go team ever said "we don't need generics". In fact, the FAQ stated from day one that they "continue to think about it", and that "Generics may well be added at some point".

Ah, I stand corrected.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#249

Earlier quoted context omitted.

I often find it useful that implementing an interface is implicit. For example maybe I'm using a library that provides a struct A. I can make another struct B that mocks that functionality for testing, and then everywhere in my code use an interface C that encapsulates A and B. That wouldn't be possible if A had to explicitly declare that it implements C. If you want to explicitly declare that you implement an interf…

- that's an optional convention, and it is not always followed - not easy to search for this pattern. You are right that go interfaces give you some flexibility with mocking, but i still think it's a questionable choice.

If the problem is finding implementations of an interface, that's provided by the standard tooling. If you're using VSCode just right-click on an interface and select Find All Implementations.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#250
post #214

Earlier quoted context omitted.

Not the OP, but i would have guessed that the (subjective) axes of "being better" are uncontroversial - by which I mean prepend "there are many who value that" in front of each: - a GC that can has relatively smart defaults without having to tweak a ton of parameters - don't have to ship a vm - concurrency baked in from the start - simpler language - doesn't try to square everything into the OO paradigm

> a GC that can has relatively smart defaults without having to tweak a ton of parameters Depends on the JVM being used > don't have to ship a vm You get to ship a runtime instead. Which Java also allows since around 2000, given how long commercial AOT compilers do exist for Java. > simpler language Java 1.0 was also Go simple, and just like Go does nowadays, full of code generation tools to work around that simplici…

> Depends on the JVM being used

Is picking a jvm not tweaking a parameter?

Post reply on HN