Live data from Hacker News

Eleven Years of Go

blog.golang.org

61–70 of 170 posts

Re: Eleven Years of Go

#61
I'm primarily a C# dev, but I find Go quite interesting. Any recommendations for how I can get started and reap some benefits, given my background?

Re: Eleven Years of Go

#62
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…

Sorry to hear that. For what it’s worth: I once submitted a tiny pull request for Bazel (IIRC allowing insecure connections to localhost for docker repositories) and it was accepted and merged within a few days. Positive experience overall.

Re: Eleven Years of Go

#63

I have really been enjoying Go, except for the built-in templating library. It's a wart on the standard library IMO. The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc. It has very very poor documentation. Some docstrings are not a replacement for actual…

Love using the template library for writing codegen utils for Go and Java

Looked for codegen utils on Github a while back -- but found nothing useful. Any public utils you'd recommend?

Re: Eleven Years of Go

#64
post #61

I'm primarily a C# dev, but I find Go quite interesting. Any recommendations for how I can get started and reap some benefits, given my background?

I got started with the Go tour: https://tour.golang.org

You'll get a feel for the language constructs. Once you're ready to graduate to tinkering with your own stuff, then go install Go: https://golang.org/doc/install

Some noted differences from C# (my C# knowledge is 5-10 years out of date, mind you):

* Go is a much simpler language; it lacks classes, inheritance, generics, exceptions, etc--you can be productive in a weekend, conservatively * Go has a formatter that everyone uses, so everyone's code has the same style * Go lacks generics, so everyone generally writes in the same imperative way (few personal, creative flourishes)--it's very boring in this regard (which is a feature for many people) * Go has value types (like C#) but they are much more idiomatic--it also has pointers and other reference types * Go's interfaces are implicitly satisfied, which is like statically-typed duck typing if you're familiar with any dynamic languages (no need to write `extends IFoo` or whatever, unlike C#) * Go statically compiles everything by default (the "VM" is compiled into every individual program) so you can just pass around a single compiled artifact * Go has lightweight threads ("goroutines") * For web service things, you don't need a Netty or any other web-server in front of your service; the web server is just a library (part of the standard library, in fact) and it is production-grade

Go and C# occupy the same ballpark in terms of performance.

Re: Eleven Years of Go

#65

Earlier quoted context omitted.

Love using the template library for writing codegen utils for Go and Java

Looked for codegen utils on Github a while back -- but found nothing useful. Any public utils you'd recommend?

I love using text/template directly for codegen. Its really easy in my experience to create sophisticated tools using it + some go functionality. The trick is learning what gen problems are best solved in text templates and whats best solved in go functions. A big advantage of using text/template for codegen is you can just write the code you want to generate and it looks like real go code. Really easy to maintain compared to AST-style codegen.

Re: Eleven Years of Go

#66
I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

Re: Eleven Years of Go

#67

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.

I'm developing an entire desktop app in WASM(with electron). Once you build the right abstraction it's just Go...simple and fun! To me the main issue I have with Go is the incomplete reflect package(i.e StructOf )

Re: Eleven Years of Go

#68

Earlier quoted context omitted.

It's really a joke :) Fundamentally, the Go team made the correct choice between explicit and implicit error handling. Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. For a good overview of the issue: https://go.googlesource.com/proposal/+/master/design/go2draf... .

> Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. The Go team tried, but the community shot it down. Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-...

As one who didn't like either proposal: I'm thrilled that they were shot down. Both worked fine (great, even) in simple cases, but fell apart when needing to add context / wrapping to multiple possible errors.

Simple cases are already simple. It's the harder spots that need help.

Re: Eleven Years of Go

#69
post #53

Earlier quoted context omitted.

The [Removed] usually means the moderators removed the post, not Reddit itself.

> OP will probably think this thread was deleted for censorship, but I wanted to note here specifically that I reported and blocked because of his disgusting sentiments at the end of this rant. The reddit mod said this, so yeah. Another user described it: > I could have understood your perspective on a lot of the earlier parts of your post, but then you ruined it with that evil statement at the end. We don't have to…

If you're keen to read it, it's out there. Google the phrase, in quotes, "A while ago I created an issue on the github.com/golang/go issue tracker because the I find the choice of fonts"

I don't want to link it or paste here, but yeah, there it is.

Re: Eleven Years of Go

#70
post #68

Earlier quoted context omitted.

> Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch. The Go team tried, but the community shot it down. Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-...

As one who didn't like either proposal: I'm thrilled that they were shot down. Both worked fine (great, even) in simple cases, but fell apart when needing to add context / wrapping to multiple possible errors. Simple cases are already simple. It's the harder spots that need help.

Can you please share some examples of the harder spots?
Post reply on HN