Eleven Years of Go
61–70 of 170 posts
Re: Eleven Years of Go
#62Earlier 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…
Re: Eleven Years of Go
#63I 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
Re: Eleven Years of Go
#64I'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?
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
#65Earlier 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?
Re: Eleven Years of Go
#66Re: Eleven Years of Go
#67I 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.
Re: Eleven Years of Go
#68Earlier 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-...
Simple cases are already simple. It's the harder spots that need help.
Re: Eleven Years of Go
#69Earlier 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…
I don't want to link it or paste here, but yeah, there it is.
Re: Eleven Years of Go
#70Earlier 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.