When I initially started Go, it felt so easy to pick up. Then I wrote a component in it and it felt overly verbose. Then I had to revisit the component and had to do some heavy refactoring/additional testing and realized that the language, to certain extent, didn't stand in the way. After all these iterations, I think Go is leaving an-even-bigger-adoption on the table for the want of following:
1. Functional operators like map/filter/reduce - all of these would be optional but would save SO many lines of code.
2. Add simple conveniences - e.g. "contains" to check if a key is present in a map. Again those who don't want to use these, don't have to.
3. Error handling boilerplate - something to the tune of "?" operator in Rust
> 1. Functional operators like map/filter/reduce - all of these would be optional but would save SO many lines of code.
But at the cost of performance; Go is not (yet?) optimized for functional programming constructs, and its function syntax adds a LOT of mental overhead to reading the code; http://www.jerf.org/iri/post/2955 was a good post on that. Remember the Go proverb: clear is better than clever. In this case, not only for readability but also performance.
I have no objections to your point #2 though, I always found Go's constructs like `len(slice)` or `slice = append(slice, value)` a bit awkward. With generics support, `slice.len()` and `slice.append(value)` should now be possible. Actually I'm not sure why the latter was not possible all along, I'm sure there's a reason somewhere. I know you can implement the latter yourself as well, even before generics.
As for #3, I got nothing; I sorta followed along with a Big Discussion about different error handling in Go a few years ago, but it basically ended with "Well... actually how it is now is absolutely fine"; all the offered alternatives added complexity, magic behaviour, or reduced readability to the language. As it is, error handling is obvious. I wouldn't mind some syntactic sugar though; a one-line error handler at the moment is `if err := doSomething(); err != nil {` which is a bit awkward. The other Issue I have is with variable reuse and shadowing, it's a risk that may cause unhandled errors.
>When I initially started Go, it felt so easy to pick up.
Same. It felt freeing to just say "fuck it, I'll use a struct" and have the built-ins required to automagically marshall json on the wire to structs in memory. That was pretty cool. You're spawning threads^H^H^H^H^H^H^Hgoroutines and passing messages and not giving a fuck because the language protects you.
Then I wanted to make v2 of my package.
Go's packaging (and module) system is just so indescribably, generally, and thoroughly bad that it put me off the language and I won't be back. I spent more time fucking around with dependencies and wondering why `go get` was giving me cryptic and unhelpful errors that were unaddressed by the docs than I did writing my code.
1 and 2 are now possible to implement, since 1.18 - I'm using this and it does save quite a bit of boilerplate: github.com/life4/genesis
I'd love to see less verbose error handling too, but Rust's ? IMHO is not the best way to go - it adds quite a bit of magic and makes debugging difficult, when a question mark at the end of a line "injects" an unexpected return statement.
And then we have folks running silly function calls for the sake of avoiding mutability.
Don't get me wrong, I understand why this hasn't been done.
We've all read the arguments against adding things to the language, but I accept in part, and reject in part that argument. Complexity always increases, so it's understandable to put the brake on run-away complexity. But GO is slightly pathological when it comes to the avoidance of adding sensible language features. The thing is most folks would rather have a slightly more complex compiler than a limiting programing language.
The rats are leaving the sinking ship, is what comes to mind.
Go has become so mainstream and the talent has moved on.
I see it in so many cases.
Established packages only do dep upgrades and rarely add any innovation anymore.
Many of the original writers have abandoned the projects. Skeleton crews remain which lack the talent to be creative.
Gin for instance has a broken streaming api. No one is going to fix it. It would mean rewriting it from the ground up. Their contrib packages are mostly outdated and not functional.
Gorilla is also in maintenance mode.
The talent is leaving Go.
Go is also missing "the one true framework", e.g. what Spring is for Java. Or rails for Ruby or dotnet for C#.
I've been with Go since mid 2013. I loved the Go+ community on Google+. I loved the language because it removed a lot of mental burden and allowed me to focus on problem solving instead of listening to people telling me "what's proper" when I had done it my way for 13 years before the new hype, successfully.
I loved the bright minds using and developing Go.
But now it feels like it's dying or stagnating.
I thought spf13 was a company, not a pseudonyme of a Google employee. I use cobra in 99% of my projects, but cobra and viper leave much to be desired especially the interoperability out of the box and documentation.
About 10 years ago, spf13-vim showed me what vim could be and changed my coding life forever. I finally ejected it and spun my own .vimrc a few years ago, but I wouldn't be where I am today without it.
As someone who uses VS Code as their daily driver, I'm starting to tire of it and was considering trying out emacs or vim. Would you say spf13-vim is a good starter resource (curated plugins and all) or should I look elsewhere as a beginner?
Anecdata: I've been doing all my projects in Go for many years now. My current production backend with 20+ services all run in Go on Kubernetes and serve 100k+ users.
It's an amazing language since it's so productive. Sometimes I write services in on go (pun intended) for an hour and after turning it on it just runs. Never experiences something like that with another language.
It's also very low on resource consumption. My server barely needs anything to serve that many users.
“I led the team that designed MongoDB’s pioneering user experience."
Let's break this down and I'll explain why he is a total liar and bullshit artist.
This makes it sound like he designed the mongodb query language. Only he could pass off inflicting the crappy Drupal website as designing MongoDB's pioneering user experience. He can't be talking about MongoDB the company, it was 10gen so obviously insinuating it was the DB.
The entire Driver and integrations ecosystem had to be cleaned up. His mess. Was barely ever in the office.
MongoDB user manual? You mean the book that Kristina wrote - who worked on the Server team and had nothing to do with you.
I built and led the team that was responsible for the MongoDB user experience. We designed and built MongoDB's integrations with programming languages & third party systems (Drupal, Hadoop, Storm, Spark, etc). Our team wrote the MongoDB user manual too and we were responsible for the websites.
My blog has a lot of talks / posts about the work our team did if you want to read up more about it.
I started learning Go maybe 2 months ago, and we're now using it at work in production for small-scale projects, with plans to make it our default server-side language. The onboarding experience has been quite easy and effective I must say.
I have only written javascript for the past ~5 years and while I've never gone bored of writing code in a ~15y career, Go has brought some pleasant freshness to my work.
All that to say that this guy and the whole Go team have done some good work.
JS was an awesome refresher, especially as React came about and front-end dev became fun with any challenge; while backend seemed mostly mundane crud. Go re-ignited my passion as an engineer, and has been such an awesome tool in the age of microservices and performant distributed architectures. We're running large ML model architectures at scale with Go now.
A bit off topic, but does anyone else find a data/financial company name "two sigma" to be...either troubling (how often two sigma events happen randomly and their lack of meaning beyond random fluctuation), or really on the nose?
A few more off-topic thoughts about this comment: (a) Two Sigma is an investment firm (a wrapper around a hedge fund), not really a financial company, (b) pretty much no one at Two Sigma is unaware of how often 2 sigma events happen, so I think neither? and (c) two sigma events can totally have meaning beyond random chance, in fact they're usually a leading indicator that there is some connection beyond luck :).
All this time I thought spf13 was just Some Guy that did a pair of libraries for CLIs in Go, I didn't realize they were such a big contributor to the Go community. Thank you for helping the language escape its "this is a tool by Google for Google to fix Google-scale problems at Google" reputation; I've used it at a previous project for 2.5 years, it has its issues of course but overall I would use it again, in big part thanks to the community and resources available.
This article made me _really_ curious what manner of awesomeness is going on at Two Sigma, but couldn't figure it out from the website. @spf13, any pointers on where to find a good article on why TS is cool?
Can’t speak for two sigma but I work in a similar company. They are generally only open enough to hire people, there is a huge competitive advantage in sharing as little as possible.
Lots of finance firms have a bunch of interesting problems, from scaling to security and many are getting better at treating engineers well. But usually it comes down to the fact they pay really well.
> This article made me _really_ curious what manner of awesomeness is going on at Two Sigma
This is probably a major reason he’s being hired.
I haven’t experienced too much of this phenomenon but “famous” OSS folks get coddled and showered with money by many companies in hopes of attracting talent.
And to be fair, its not the worst strategy. Instead of some silly values document they pay real engineers and usually give them a ton of freedom.
This is what I miss the most nowadays. Being the number one item is proper placement IMO.
Go is fantastic and makes it easy to build. Hugo is great too - I'm currently using the Docsy template to avoid/replace multiple software products for a crypto/blockchain project.
I don’t know if writing software as an incidental expense to efficiently allocate capital is actually worse than writing software as an incidental expense to conduct mass surveillance to trick old and poor people into clicking ads.
spf13, congratulations on your move and thank you for what you’ve already done. Was a really cool experience watching your live interview during the recent HugoConf 2022 event.
On the flip side, I didnt realize background clip was now available in all mainstream browsers. I am surprised it is not more common in websites. I might use it in titles or captions but maybe not in something that is inline and so frequent.
Read the guidelines. This is an unproductive useless comment which isn't encouraged in HN.
Also, others buddy! Others care. He didn't submit this. Others who follow his work did. I just knew this alias "spf13" until today. Not the person or his whereabouts. I run my website with Hugo. So while I didn't care before, NOW I DO! This is how you learn about new stuff. If you don't want, just move on from HN!
Why is this kind of unproductive comments cropping up again and again? Haven't these folks read HN guidelines? If you don't care, move on! Why comment anything at all?
noisy_boy|3 years ago
1. Functional operators like map/filter/reduce - all of these would be optional but would save SO many lines of code.
2. Add simple conveniences - e.g. "contains" to check if a key is present in a map. Again those who don't want to use these, don't have to.
3. Error handling boilerplate - something to the tune of "?" operator in Rust
Cthulhu_|3 years ago
But at the cost of performance; Go is not (yet?) optimized for functional programming constructs, and its function syntax adds a LOT of mental overhead to reading the code; http://www.jerf.org/iri/post/2955 was a good post on that. Remember the Go proverb: clear is better than clever. In this case, not only for readability but also performance.
I have no objections to your point #2 though, I always found Go's constructs like `len(slice)` or `slice = append(slice, value)` a bit awkward. With generics support, `slice.len()` and `slice.append(value)` should now be possible. Actually I'm not sure why the latter was not possible all along, I'm sure there's a reason somewhere. I know you can implement the latter yourself as well, even before generics.
As for #3, I got nothing; I sorta followed along with a Big Discussion about different error handling in Go a few years ago, but it basically ended with "Well... actually how it is now is absolutely fine"; all the offered alternatives added complexity, magic behaviour, or reduced readability to the language. As it is, error handling is obvious. I wouldn't mind some syntactic sugar though; a one-line error handler at the moment is `if err := doSomething(); err != nil {` which is a bit awkward. The other Issue I have is with variable reuse and shadowing, it's a risk that may cause unhandled errors.
na85|3 years ago
Same. It felt freeing to just say "fuck it, I'll use a struct" and have the built-ins required to automagically marshall json on the wire to structs in memory. That was pretty cool. You're spawning threads^H^H^H^H^H^H^Hgoroutines and passing messages and not giving a fuck because the language protects you.
Then I wanted to make v2 of my package.
Go's packaging (and module) system is just so indescribably, generally, and thoroughly bad that it put me off the language and I won't be back. I spent more time fucking around with dependencies and wondering why `go get` was giving me cryptic and unhelpful errors that were unaddressed by the docs than I did writing my code.
Deleting go was the best move I've made.
herval|3 years ago
I'd love to see less verbose error handling too, but Rust's ? IMHO is not the best way to go - it adds quite a bit of magic and makes debugging difficult, when a question mark at the end of a line "injects" an unexpected return statement.
parasense|3 years ago
``` const map[uint8]string { 0: "thing1", 1: "thing2", } ``` That way tables of data can be made immutable at compile.
Folks are left to invent stupid hacks, that don't really work. For example, a function that defines a template and returns:
``` func my_data() map[uint8]string { return map[uint8]string { 0: "thing1", 1: "thing2", } } ```
And then we have folks running silly function calls for the sake of avoiding mutability.
Don't get me wrong, I understand why this hasn't been done. We've all read the arguments against adding things to the language, but I accept in part, and reject in part that argument. Complexity always increases, so it's understandable to put the brake on run-away complexity. But GO is slightly pathological when it comes to the avoidance of adding sensible language features. The thing is most folks would rather have a slightly more complex compiler than a limiting programing language.
bigbluedots|3 years ago
konart|3 years ago
Why though? it doesn't even save you much space compared to standard use:
if _, ok := m[key]; ok { }
vs
if contains(m, key) { }
I'm not strictly against it, but it can open pandora's box of all kinds of weird sugar flavors.
cies|3 years ago
Where they actually trying to copy other's well-known-to-be mistakes?
unknown|3 years ago
[deleted]
lakomen|3 years ago
Gin for instance has a broken streaming api. No one is going to fix it. It would mean rewriting it from the ground up. Their contrib packages are mostly outdated and not functional. Gorilla is also in maintenance mode.
The talent is leaving Go. Go is also missing "the one true framework", e.g. what Spring is for Java. Or rails for Ruby or dotnet for C#. I've been with Go since mid 2013. I loved the Go+ community on Google+. I loved the language because it removed a lot of mental burden and allowed me to focus on problem solving instead of listening to people telling me "what's proper" when I had done it my way for 13 years before the new hype, successfully.
I loved the bright minds using and developing Go.
But now it feels like it's dying or stagnating.
I thought spf13 was a company, not a pseudonyme of a Google employee. I use cobra in 99% of my projects, but cobra and viper leave much to be desired especially the interoperability out of the box and documentation.
DrinkWater|3 years ago
Actually this is the first time i heard from this guy, but this is an impressive list of projects to be involved in, wow!
lf-non|3 years ago
Given the name similarity, I was wondering if the author also had some involvement in that library, but looks like not.
mupuff1234|3 years ago
I'm sure he didn't build any of those alone, and as a "leader" and a product person he probably didn't do much of the "building".
Seems like he was mostly in an advisory role for Drupal, Docker and MongoDB, he didn't exactly build them.
akomtu|3 years ago
[deleted]
frob|3 years ago
Thanks a bunch!
anitil|3 years ago
hoten|3 years ago
threatofrain|3 years ago
Impressive. How accurate is this?
spf13|3 years ago
davidkuennen|3 years ago
It's an amazing language since it's so productive. Sometimes I write services in on go (pun intended) for an hour and after turning it on it just runs. Never experiences something like that with another language.
It's also very low on resource consumption. My server barely needs anything to serve that many users.
nojito|3 years ago
Very exciting to watch the exodus happen!
samfisher83|3 years ago
Karupan|3 years ago
As someone who has used mongo, genuinely curious about which part of the user experience is being highlighted here.
Thanks for all your work with the Go community and good luck with the new team!
mbd64|3 years ago
Let's break this down and I'll explain why he is a total liar and bullshit artist.
This makes it sound like he designed the mongodb query language. Only he could pass off inflicting the crappy Drupal website as designing MongoDB's pioneering user experience. He can't be talking about MongoDB the company, it was 10gen so obviously insinuating it was the DB.
The entire Driver and integrations ecosystem had to be cleaned up. His mess. Was barely ever in the office.
MongoDB user manual? You mean the book that Kristina wrote - who worked on the Server team and had nothing to do with you.
spf13|3 years ago
My blog has a lot of talks / posts about the work our team did if you want to read up more about it.
Redsquare|3 years ago
daviddever23box|3 years ago
n3tfox|3 years ago
mbd64|3 years ago
[deleted]
dboreham|3 years ago
2143|3 years ago
But the excessive use of "I" does stick out. In my culture (where spf13 is not from), excessive use of "I" is considered a sign of arrogance.
That's probably just cultural difference though. He might really be a nice humble person :)
mrfox321|3 years ago
waynesonfire|3 years ago
bleuarff|3 years ago
I have only written javascript for the past ~5 years and while I've never gone bored of writing code in a ~15y career, Go has brought some pleasant freshness to my work.
All that to say that this guy and the whole Go team have done some good work.
ramoz|3 years ago
mattgreenrocks|3 years ago
juliand|3 years ago
podiki|3 years ago
singhrac|3 years ago
d0mine|3 years ago
abm53|3 years ago
Cthulhu_|3 years ago
mountainriver|3 years ago
sigzero|3 years ago
spf13|3 years ago
rfeague|3 years ago
lelandfe|3 years ago
ThrowawayFin|3 years ago
Lots of finance firms have a bunch of interesting problems, from scaling to security and many are getting better at treating engineers well. But usually it comes down to the fact they pay really well.
pm90|3 years ago
This is probably a major reason he’s being hired.
I haven’t experienced too much of this phenomenon but “famous” OSS folks get coddled and showered with money by many companies in hopes of attracting talent.
And to be fair, its not the worst strategy. Instead of some silly values document they pay real engineers and usually give them a ton of freedom.
nr2x|3 years ago
pjmlp|3 years ago
yellow_lead|3 years ago
moharoune|3 years ago
JaggerFoo|3 years ago
This is what I miss the most nowadays. Being the number one item is proper placement IMO.
Go is fantastic and makes it easy to build. Hugo is great too - I'm currently using the Docsy template to avoid/replace multiple software products for a crypto/blockchain project.
Cheers
jpcapdevila|3 years ago
Looks like you have a good eye for picking good tech & teams to join and work with.
Any insights or things you saw in common?
spoonjim|3 years ago
halffaday|3 years ago
pjmlp|3 years ago
Gentil|3 years ago
fieu|3 years ago
brycewray|3 years ago
TheRealNGenius|3 years ago
lf-non|3 years ago
On the flip side, I didnt realize background clip was now available in all mainstream browsers. I am surprised it is not more common in websites. I might use it in titles or captions but maybe not in something that is inline and so frequent.
mikevm|3 years ago
Gentil|3 years ago
First of all - https://news.ycombinator.com/newsguidelines.html
Read the guidelines. This is an unproductive useless comment which isn't encouraged in HN.
Also, others buddy! Others care. He didn't submit this. Others who follow his work did. I just knew this alias "spf13" until today. Not the person or his whereabouts. I run my website with Hugo. So while I didn't care before, NOW I DO! This is how you learn about new stuff. If you don't want, just move on from HN!
Why is this kind of unproductive comments cropping up again and again? Haven't these folks read HN guidelines? If you don't care, move on! Why comment anything at all?
unknown|3 years ago
[deleted]
newaccount2021|3 years ago
[deleted]
anewpersonality|3 years ago
[deleted]
dang|3 years ago