41–50 of 170 posts
Earlier quoted context omitted.
Ian Lance Taylor has been nothing but tirelessly patient and helpful when interacting with the community from what I've seen. This story doesn't pass muster without more details, least of all because you seem to think Ian joined Go in 2019.
He seems to be this honest and stable user: https://www.reddit.com/r/golang/comments/gzvf70/comment/ftim...
And, like a breath of fresh air, I started remembering how Go works: it's a very simple, stupid language -- in the best possible way -- and it just works. You start writing code, and then you write more code. You write a function. And then you write another one. Slowly, your program gets bigger. Sometimes you need to split up functions.
And that's it. No fiddling with project structure, with taxonomies, and with hierarchies. I forgot what it felt like to just sit down and write some code. I've gotten used to battling tooling, fighting with opinionated frameworks, and having a zillion ways of doing something -- stuck in an eternal analysis paralysis.
I missed Go.
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 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 a lot about the mentality of the maintainers behind the project.
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…
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.
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
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.
Earlier quoted context omitted.
It's more likely to be downvoting an unsubstantiated allegation of plagiarism which, in the circumstances, could easily be argued with public evidence.
You seem more uptight about it than I am. I didn't see it as anything so formal as "plagiarism", I just thought it was rude and ungrateful. If digging up work from 2014 is easy, you must be more organised than I am.
[1]: go-review.googlesource.com
I implemented a few services in Go like 5 years ago and they still work. I think some have uptime of 2 years or more. I love that once you get good test coverage, Go programs are extremely stable. I still prefer to do things in Python, but if I need extra stability I go with Go.
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…
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…
As someone who's been writing Go full-time for over eight years, and has also done some Rust as well, I'll say that the business/corporate focus that you're noticing is a fairly recent development. My impression is that it's mostly a function of the size and the market demand for the language - ie, as the language has grown and is being used for more mission-critical stuff, a wider range of businesses have a vested interest in it.
Rust is a bit younger than Go. If we're judging by the first stable release, it's about half the age (5 years vs. 8). It's not as far along the adoption curve in many ways yet, although it's growing fast. Rust is being used for more things today than it was, say, three years ago, but it's still a narrower range (and number) of companies that are interested in Rust. Given Rust's trajectory, I think that's just a matter of time, so what you see today in Go will probably be more visible in Rust in a year or two. It's already drawing a wider range of corporate interest than it was even one year ago, and if it continues to be successful, that's inevitable.
I don't think that's a bad thing, though. The communities get wider, but that doesn't mean that the stuff you're looking for isn't there; you just have to look a little harder for it. That's definitely true for Go, and I would bet it will be true for Rust as well.
I also think that Rust and Go are not really comparable, and it's a shame that they often come up together so often in discussions, because they're compared more often than is really warranted IMO. But that's a separate matter.
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
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.
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....