Live data from Hacker News

Eleven Years of Go

blog.golang.org

51–60 of 170 posts

Re: Eleven Years of Go

#51
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 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 would acknowledge the problem even existed.

The kicker is that the maintainers at Google then followed up with wanting me to submit another PR with additional changes that they wanted to see instead either merging the fix or adding the additional changes themselves.

Now my attitude towards Google's open source projects is if they want contributions, they can pay me. I'm not wasting my time for free again for them.

Re: Eleven Years of Go

#52
post #42

Happy birthday Go! I'm currently working on a little side-project and I wanted to write (part of) it in Go. As a side-note, the last time I wrote Go was all the way back when I made a few small contributions to the http standard library, circa 2009. As soon as I set up my environment, my gears were already turning (coming from Python, TypeScript, Java, etc.): how should I structure things? Where should this live? Wha…

To add to the list of things other languages make you think about: setting up a CI job for building your code packages and uploading them to the appropriate repository, setting up a CI job for building your documentation packages and a website to host them, deciding on a test framework, drafting a style document (and policing contributions accordingly), configuring a web server (e.g., tomcat, uwsgi, etc) if your project is a service, figuring out how to distribute your code to your target platform (while making sure all of the right runtime dependencies are installed), etc. This is all stuff you don't really have to learn or think about with Go because it's all solved for you out of the box.

Re: Eleven Years of Go

#53
post #34

Earlier quoted context omitted.

Thankfully Reddit removed the post for my own safety. I hate seeing both sides of a conversation.

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 agree on the perspective but wishing harm or death to people and their families over it is just dark.

Which matches their current sentiment:

> You made an enemy that day. You always meet twice in life. I'll pay that back to you.

Re: Eleven Years of Go

#54
post #2

Generics Update: "We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas."

Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :) https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling

My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I prefer it to the try/catch paradigm where the error is maybe handled somewhere up the call stack

Re: Eleven Years of Go

#55
Great post to highlight what has happened in the last year in GoLang and what is up for the next year! Very concise and to the point.

Even without having used much GoLang this last year it gave me a very clear view of what to be looking for!

Re: Eleven Years of Go

#56
post #30
post #2

Generics Update: "We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas."

This carefulness and emphasis on stability and simplicity is one of the reasons I'm attracted to the language. Currently I personally don't really see a use-case that isn't covered by my tool-belt otherwise but every time I peek into a Go repository or read about Go I get a bit jealous.

I don't think Go does anything other languages cant do, it just does things better. It makes things simple. In some ways its like the Mac OS of programming languages. In certain ways its restricting, but 99% of the time its going to make your life much easier.

Re: Eleven Years of Go

#57

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…

> 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 think you hit on something that so many miss and it's the tooling for the job, as it were. Go and Rust are fundamentally different tools designed for fundamentally different tasks. While it's possible to use them for the same tasks, it's much more difficult. I would HATE writing a full and secure operating system in Go, while writing back end systems in Rust is doable, but at an unnecessarily slower pace than Go.

Re: Eleven Years of Go

#58
Micro was on the frontpage earlier today (https://news.ycombinator.com/item?id=25044604). It's written entirely in Go, and so was its predecessor and everything I've done since 2012. Go is a phenomenal language and I'm not really sure where I'd be without it, my company basically wouldn't exist, I wouldn't be solving the problems I am. Its a phenomenal language and I owe a great deal of gratitude to the Go team for that.

The future is bright for Go, it is for sure the language that defines Cloud development for backend services and APIs. It has spawned an ecosystem of docker, kubernetes and beyond and countless companies have come to rely on it for their software. It is amazing achievement to see something go from nothing to this. It is unclear whether it would have had the same success had it not been for being within Google, but that's just part of it.

Re: Eleven Years of Go

#59

Earlier quoted context omitted.

Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :) https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling

My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I prefer it to the try/catch paradigm where the error is maybe handled somewhere up the call stack

Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of assertions to validate code invariants. On assertion failure, which obviously never happens as I write perfect code that never violates invariants, all I want to happen is 'write the error in the logs and return 50x'. I suppose panic/recover is the way to go, but I have the impression they are shunned by the community and not recommended by Golang official docs.

https://golang.org/doc/faq#assertions

> Why does Go not have assertions?

> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.

> We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

Re: Eleven Years of Go

#60

Earlier quoted context omitted.

No, error handling is not the best. The lake of generics seems to get addressed with lots of pondering which is a good thing. But error handling is just awkward. I do not mean the retval, err := funccall(a,b) syntax but rather the absence of a standardized way to get stack traces.

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-...

Post reply on HN