Spf13 is leaving Google(spf13.com) |
Spf13 is leaving Google(spf13.com) |
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?
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 },...
should contain no occurrence of 'bool' (it is implicit in the definition of a Filter) and at most one occurrence of 'string' (it is a filter over a string sequence if and only if the input of its defining predicate is a string).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!
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.04550026389635842This 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.
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.
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 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
I'd guess with generics we can expect a generic "Must" to replace them.
> Over half (55%) of respondents use Go at work on a daily basis.
Not what I'm saying. I'm saying when smart people created Go, the forgot that null is a mistake, and sum-types are simply too useful in modelling the world to miss out on (pattern matching makes them a joy to use).
This was both well understood in the 20XXies; and I have never seen any reason from the creators of Go as to why...
> Scala
Scala is a multi-paradigm lang; that sucks on whole different levels. I'm not advocating at all that Go should be multi-paradigm.
Having worked on all these should be good enough you don't need to embellish and constantly overstate and lie about your contributions. Let other people talk about how great you are.
I’ve also read your code. I enjoy it and learned a lot more of go that way.
Whatever. Thanks for helping make Go so much fun for me. I look for excuses to write CLIs with Cobra/Viper. They’re of a very few set of libraries I look forward to using.
I use Hugo for much more than it was intended for.
Heck, I wrote a CLI with Cobra around Hugo and a simple theme for my personal note taking and todo management. I was annoyed with other markdown note tools and DIY was a fun waste of time :).
Congratulations on your new role. Two Sigma seems super-exciting.
It was more common than you may have realized.
Of course this is all guesswork based on similar stuff i've seen elsewhere, so i might be off, but i think despite not knowing the language it still looks readable if you know any other mainstream language (and exercise some guesswork/imagination :-P).
I can say the same about Fennel, List or Haskell.
The first example is the way to go in Go. It's idiomatic, not a hack. And it works the same way for many things (for example checking if a channel's closed)
you could write this in Go
if m[key] { }
the comma ok idiom simply lets you distinguish a "zero" value from a missing value."I work for Google" has become one. "I'm a Googler" just has me pivot and walk away.
Another infamous one, "I work at the White House."
This is true about any successful institution in general. I noticed it first with Universities but it applies to jobs as well.
While it may be read as some sort of Jealous screed, I have observed similar behaviors from people who fall under this collection of traits. People that might at first be seen as having accomplished a lot, but on further examination, its maybe a few things, and the rest of the things are generally exaggerations.
To a certain extent I understand the need to self promote if one wants to continue to work on OSS but without corporate sponsorship/funding.
His LinkedIn says he started at MongoDB in 2011. The first commit to Hugo was in 2013, a full two years later. Your story doesn't add up at all.
He left in the middle of 2014. He was checked out for a long time. I'd say that timeline adds up pretty nicely.
So while Steve would like take credit for Mongo's enterprise adoption he barely had anything to do with it. Not with the Server, not with Cloud, not with Sales, Marketing or Education.
In terms of proliferating Go I think that statement is fair. spf13 is like brand name in open source.
I recall years back on GitHub, spf13 was like a name you were guaranteed to come across if you were sinking your teeth into Go. I ended up using cast / viper: https://github.com/tony/vcsync/commit/a76681b. (Not that I'm anything special at golang)
No doubt his contributions did in fact help that process, but as I read it, the claim asserts him as the driver of that process, which he was not.
Did you not read the post?
The post is full of evidence of the things that he did or the team that he led did that drove Go's growth.
He definitely was a major contributor to Go's widespread adoption both as an OSS contributor and as a project leader.
We all contribute to poop. Our level of contribution to said poop does not diminish that, in fact, we all work on poop so we’re all in the same poop boat. Take it easy on each other, and reserve the bullshit calling for those who really earn it, like the folks who initially built the poop you’re claiming by cleverly offshoring their minimum maturity on the financial and sweat equity of every early adopter. Like, say, for example, for no particular reason, my team at the exact time you’re arguing about.
It’s fine, though, I get it, that’s valley capital, fake it until you make it, give us ops teams ulcers, we make goodish money. Just weird to see resentment over who can claim MongoDB success with that kind of perspective is all. Particularly since the success at the time was all lazy developer mindshare (no disrespect, I’m lazy too), and the technical weaknesses started a few ten-year roadmaps that are now in the market and obsolete MongoDB.
Are you agreeing with the "whistleblower" or not?