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
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.
For example the line
return Filter(string)(func(s string) bool { return len(s) <= 2 },...
Is there any alternative technique for functional style in Go?
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.
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.
``` 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.
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.
It's less about length of code and more about cognitive load; this is why functional programming constructs are frowned upon in Go code, because the cognitive load per line of code is much higher.
Also `if m.contains(key) { }` is even more obvious IMO.
Where they actually trying to copy other's well-known-to-be mistakes?
That said, there are other languages with proper sum-types and pattern matching, if that's what you need; I think it's a bad thing that some people advocate for every language to have every feature from every other language. Take Javascript; someone Decided that it should have classes, but the implementation has never been good (e.g. field access levels) and it's always felt bolted on. Take Scala, which borrowed every feature from every other language ever, and now you can't have two people work on one Scala codebase without them having endless discussions about which flavor or pattern to use.
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.
Actually this is the first time i heard from this guy, but this is an impressive list of projects to be involved in, wow!
Given the name similarity, I was wondering if the author also had some involvement in that library, but looks like not.
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.
Perhaps a more accurate wording is:
"You may know me from helping to build the Go Language, Docker, MongoDB, and Drupal & creating Hugo, Cobra and spf13-vim"
He pushed hugo and viper in 2013-2014: https://github.com/gohugoio/hugo/commits/v0.7, viper: https://github.com/spf13/viper/commit/98be071
Steve is a very accomplished programmer, with what hugo / viper became in the go ecosystem by itself. In my view, the projects also jumpstarted a lot of new users who were trying out golang who weren't sold on it yet. I didn't really notice his leadership or advisory roles until now, that's just icing on the cake.
Thanks for your contributions, Steve!
Edit: If it's really big ecosystem, _indirect_ contributions also matter. e.g. in python, even if you're not writing CPython patches or PEPs, community based projects do a lot to shape best practices and even bubble up into standard library.
W O W, really ?
Generally, I'm with you. In this case, I'm only half with you (the phrasing around Go and Docker could use some humility), but he really did build Hugo and Cobra. He contributed quite a bit to the Go ecosystem, he's not just some product person taking credit for work other people actually did.
Linus created Linux, but 1000s of people built it.
This guy isn't claiming to have built any of these alone, just claiming that these projects are where you'd recognize him from.
Thanks a bunch!
Impressive. How accurate is this?
Tongue-in-cheek feedback aside, congrats on all your achievements and good luck on your future projects!
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.
Very exciting to watch the exodus happen!
A smaller team just has to pay more than that for a few tens, and perhaps offer more interesting work besides.
Are you saying trading companies aren't profitable enough?
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!
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.
According to Github, he even contributed to it https://github.com/mongodb/docs/graphs/contributors
There's a lot of evidence that his claims are at least plausible if not credible.
You created a burner account and anonymously keep spreading obscure attacks and lies without any evidence.
My blog has a lot of talks / posts about the work our team did if you want to read up more about it.
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 :)
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.
>>> import statistics
>>> 2*statistics.NormalDist().cdf(-2)
0.04550026389635842Lots 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 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.
They pay _interns_ $70 per hour
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
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?
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.
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?