Live data from Hacker News

Eleven Years of Go

blog.golang.org

111–120 of 170 posts

Re: Eleven Years of Go

#111
post #43

Earlier quoted context omitted.

I didn’t have a positive experience with my own contribution. While working with SSH keys in Go, I realized there was no existing method to calculate a key fingerprint. Seeing as this is a reasonably common operation, I opened a PR and added it. I was told—with a straight face—that it was unnecessary because it’s simple enough to read the RFC and do it yourself. It was eventually added, but that experience taught me…

I had a similar experience contributing to Dart. The Dart standard library didn't implement an RFC correctly, so I submitted a fix with a PR and was given the run around about how nothing was actually wrong, despite citing the RFC and giving test cases to reproduce errors. It wasn't until another Google employee showed up much later and echoed that there was a problem with Dart's implementation that the maintainers w…

Did this all play out in a publicly available issue or a PR?

Re: Eleven Years of Go

#112
post #43
post #3

I had different opinion than guy who joined the Go team in 2019 (Ian Lance Taylor). I was banned from their github repo, my AdSense sites were removed from Google's index, my AdSense CPC dropped by 2/3. My github account was "flagged" aka disabled from being seen in public. I was on github for 7 years. I received nonsensical "not in accordance to policies" messages from AdSense all of a sudden when that happened aka…

I didn’t have a positive experience with my own contribution. While working with SSH keys in Go, I realized there was no existing method to calculate a key fingerprint. Seeing as this is a reasonably common operation, I opened a PR and added it. I was told—with a straight face—that it was unnecessary because it’s simple enough to read the RFC and do it yourself. It was eventually added, but that experience taught me…

> I was told—with a straight face—that it was unnecessary because it’s simple enough to read the RFC and do it yourself.

This peaked my interest, because it didn't match my experience at all.

https://github.com/golang/go/issues/12292

It was an initial reply to another user, which was immediately reconsidered and accepted when the request was clarified to include colons. There was concern about the breadth of a single package, and if this should be included in a sibling package. This was all in one morning.

The original user closed the ticket, and was reopened after your comment.

> On the other hand, if I have to read a five-page document, sign up for a third-party code review tool, install strange and mysterious new git commands, and send a diff to a mailing list, only to invariably need to argue endlessly to get a ~15-line function added to a x/ package, hopefully you'll understand why I don't.

Indeed, this was recognized a large obstacle for contributors, and the process changed. The community now accepts contributions via GitHub. Unfortunately, this change happened after your contribution, but is now available should you decide to contribute in the future.

https://golang.org/doc/contribute.html#sending_a_change_gith...

Re: Eleven Years of Go

#113
post #87

I use Go quite a bit, and I have the exact opposite experience from a lot of these testimonials. Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I re…

The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand.

Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms and data structures, not the language you are using.

Re: Eleven Years of Go

#114
post #99

I'd like to hear some Java devs opinions on Go. On one hand I'd like to try and learn something new, on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

I am mainly Java developer but used Go for some tools. I can't use Go for official applications because Go's XML library is little funky and my work is quite a bit XML dependent. It also lacks pure Go drivers for major commercial databases. If these 2 things were there I would have written lot more Go.

Re: Eleven Years of Go

#115

I am super happy that I invested in Go. I ended up working on TURN, WebRTC and DTLS and feel I made the right choice. The impact vs time spent was worth it. I don't think there is any other language I would have had a better experience. Either it is too niche, or it is so popular that the community is anemic. * https://github.com/pion/dtls * https://github.com/pion/webrtc * https://github.com/pion/turn Go is really g…

WASM is their weaker part. On the flip-side the WASM takeup is also rather modest so the net loss is not that big. Eventually they might come up with a solution to get their huge WASM files down to bearable size. Sure its because they have to ship the bigger part of their VM with it.

There's no VM in Go—you're probably thinking of the runtime.

A "Hello World!" using 1.15.4 on linux/amd64 takes up 1.2MiB of space (731KiB after UPX).

Using https://github.com/tinygo-org/tinygo, it drops to 21KiB (unable to be compressed further using UPX), making WASM size a non-issue.

Re: Eleven Years of Go

#116
post #95

Earlier quoted context omitted.

> The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side? As someone who's been writing Go full-time for over…

I very much agree with this. Rust is to C++ what Go is to Java. I think the fact that Go compiles to native binaries and can be linked statically are the primary reasons it is often compared to system languages like Rust or C++. But really, it's not the same type of language.

Rust fundamentally improves C++ with memory safety and allegedly provably correct concurrency. It is a vastly different set of assumptions, design, and opinions than C++.

What does Go do to fundamentally deviate from Java? IMO it is basically the same space with a few different opinions. It has GC, is C-style, a more modern stdlib than C/C++.

Re: Eleven Years of Go

#117
post #113
post #87

I use Go quite a bit, and I have the exact opposite experience from a lot of these testimonials. Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I re…

The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand. Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms an…

I suggest you try and implement some complex but well-defined algorithm, e.g. sha256, in some very, very simple language, say, brainfuck (which is very close to the original Turing machine language). Or, more realistically, in PDP11 assembly, which is beautifully transparent and uniform.

You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.

Re: Eleven Years of Go

#119
post #99

I'd like to hear some Java devs opinions on Go. On one hand I'd like to try and learn something new, on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

The vast majority of my work has been on the JVM - and most of that in Java. I tried Go for a while, and came away pretty unhappy. First, similarities: Go seems like a really good language for building software for teams. It's straightforward and simple, and generally what you see is what you get. That's great. Where it wins: - having a standard formatter is amazing - having a compiler that is fast, and an executable…

How was experience using Go routines? And how would you compare it with Java? I am sure Java would have something similar

Re: Eleven Years of Go

#120
post #99

I'd like to hear some Java devs opinions on Go. On one hand I'd like to try and learn something new, on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

Having used it some, and watched others use it more, I'm struck by the commonality that the most steadfast adherents of the language confuse typing with productivity; "The code flies from my fingers!"

Well, sure, but the code I don't need to write in the first place because of well used and vetted libraries, or higher level abstractions, is pretty cool too. It just isn't as keyboard clackyclacky.

Post reply on HN