Spf13 is leaving Google | Hacker News Reader

Spf13 is leaving Google

spf13.com

239 pointsArmandGrillet165 comments

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

also https://github.com/samber/lo

2 has been possible since version 1.0

https://go.dev/doc/effective_go#maps

While it won't win the hearts of Gophers, I would use a utility function that panics if error, at least on throw away code.

There are some instances of it in the stdlib, e.g. <https://pkg.go.dev/html/template@go1.18.4#Must>

I'd guess with generics we can expect a generic "Must" to replace them.

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

Deleting go was the best move I've made.

What language do you use nowadays, if I may ask?

Mostly C#, Lisp, and Python, very very occasionally some C.

>Add simple conveniences - e.g. "contains" to check if a key is present in a map.

Why though? it doesn't even save you much space compared to standard use:

if _, ok := m[key]; ok { }

if contains(m, key) { }

I'm not strictly against it, but it can open pandora's box of all kinds of weird sugar flavors.

I know zero go, despite having worked with it professionally for a short stint that I try and block out of my memory (not go's fault), anyway that first example looks like gibberish to me while the second is super clear.

It is deeply idiomatic in the language.

But only because there's no `contains` function!

If perl has taught us anything... 3 ways to do something is worse than 1.

what `contains` what?

you could write this in Go

   if m[key] { }

the comma ok idiom simply lets you distinguish a "zero" value from a missing value.

Agreed that `key in m` or `m.contains(key)` would be clearer, but checking the value rather than the presence is asking for trouble.

`if m[key] { }` is only valid Go if m is a map from something to bool, so I don't know what you even mean.

Well, that's because you do not work with go much I guess?

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)

FWIW i also know zero Go but the first example made sense (though while i don't know Go, i do know it has multiple return values): the "m[key]" part returns two values which are assigned to the "_, ok" expression which represents a value to be ignored and an "ok" variable which is later used in the "; ok" part (i guess ; separates multiple subexpressions similar to C's "," and the overall expression's value is the last subexpression) and so the two values returned from "m[key]" are the map's value and a boolean (or something that can be used like that) that checks if the value was found. In which case "if _,ok := m[key] {" would be the same as something like "if m.contains(key) {".

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

No, but IMO the cognitive load for the second one is a lot lower; it says what it does, not how it does it. It's like using `for i := i; i < len(slice); i++` vs `for i in range(slice)` or other languages' versions thereof; it reads in what you want it to do instead of how it should do it.

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.

the difference is visible cognitive load. The first has me looking at commas and underscores and colons and equals, for a map lookup.

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

The examples of what map, reduce etc. could look like in "Why Go Getting Generics Will Not Change Idiomatic Go" are very awful, but chiefly because they repeatedly state many types that in most programming languages would be deducted or unneeded.

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?

I dont know why the Go designers put in implicit null and left out proper sum-types and pattern matching.

Where they actually trying to copy other's well-known-to-be mistakes?

I don't know about null, but wouldn't sum types and pattern matching make the language spefication and the toolchains a lot more complex? Their goal has always been to be simple and have longevity, but I think it's been at the cost of "safety", e.g. being able to just ignore errors, allowing nulls (although that's only for pointer types, value types have sane zero values and should be used as much as possible; some pointer types can handle null values as well), etc.

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.

> I think it's a bad thing that some people advocate for every language to have every feature from every other language

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.

One of the problems with simple things is that everyone wants more features, and then they stop being simple.

I'd really love to see container constants. As of this writing only strings or numbers can be set constant.

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

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.

> You may know me from building the Go Language, Docker, MongoDB, Hugo, Cobra, Drupal and spf13-vim

Actually this is the first time i heard from this guy, but this is an impressive list of projects to be involved in, wow!

Am I the only one who finds that type of phrasing distasteful?

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.

Afaik the last 3-4 are actually largely his personal projects that he probably built most of himself. But yeah, kinda agree for the other ones, the phrasing feels a little self-aggrandizing to my ear. Not sure how intentional it is though, that kind of phrasing I think sort just sneaks into the lexicon for some.

So basically a Googler, nonetheless.

Have you found Googlers to be self-aggrandizing on average? That's not been my experience working there. (But might be different for "Googlers who talk a lot/are well-known publicly".)

From the outside peering in, the only Googlers are the ones who talk a lot or loudly leverage their ex-googler status on other projects.

Well but the ones who aren't loud and don't bring it up constantly, you wouldn't know that about them.

That's exactly my point.

It's our way of trying to make something out of all the lost years working away in the salt^H^H^H^Hprotobuf mines. We have to use the 'leverage' because all else we'd have left is money in the bank account and skill sets incompatible with most other places in the industry.

Right, that's what I meant. I don't think the average Googler is self-aggrandizing, but if you don't work at Google or have a big friend circle that works there, then there's a selection bias for the Googlers you do know.

I'm just speculating, but it might be due to all the practice with writing promo packets...

Heh, as much as I hate painting with that wide of a brush it does seem accurate. Something about Google breeds hubris and self aggrandizement.

There are certain phrases that just saying them as a matter of fact will always risk sounding self aggrandizing.

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

> Something about Google breeds hubris and self aggrandizement.

This is true about any successful institution in general. I noticed it first with Universities but it applies to jobs as well.

I know an MIT PhD (natural sciences) who thinks too highly of herself--when I beat her in the Chinese game of Wuziqi (She's Chinese and has beaten the computer and played nearly all her 20+ years), she was so pissed off....She still had that hubris and self-aggrandizement though, until she discovered by chance, that I used to teach mathematics at one of her Alma maters. After that she became sort of an enemy. This is the problem with self-aggrandizing people.

> Am I the only one who finds that type of phrasing distasteful?

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.

Creating something is often just a small group, but teams build things.

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.

I never intended this statement to be taken as if I built these alone. Thanks for this candid feedback.

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"

Helped building it or actually built it... Impressive just the same!

Congratulations on your new role. Two Sigma seems super-exciting.

This much more clear and honestly more impressive (because the first four are so obviously group effort that I discounted the last two - I had my suspicions about spf13-vim, though).

I think your wording was fine. I didn’t read that into it at all. Of course you worked with folks to do them. You also spent the majority of the post thanking people you worked with.

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

No, Steve that is not accurate. You didn't build MongoDB, Docker or Go. They were all wildly successful before you came on board. It's dishonest of you to insinuate that you built or helped build the core products. I can speak first hand for 10gen. For Docker you were not even there for a year, and for Go Rob was pretty clear who helped build it - Ian, Russ, Adam and a long list of people. You were ancillary involved around the periphery of all these.

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.

This specific, quoted, phrase doesn't bother memuch, but I agree that reading the whole article gave me, from top to bottom, a sour taste of personal branding and developer marketing that really doesn't sell it (to me).

I contribute to open source projects as well - in various capacities - and it's fine for a maintainer of a huge project to use that wording.

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.

Yeah, wow, exaggerations everywhere ! Very distasteful. His LinkedIn profile says: "I’m responsible for taking Go Language, Docker and MongoDB from niche technologies to widespread mainstream enterprise adoption."

W O W, really ?

Yeah, he's a consummate self-promoter and exaggerator I was at Mongo at the same time. He worked on the drupal website which was a godawful mess. Then there was the Drivers team. He spent 3 years there, was absent most of the time working on Hugo while employed at Mongo. Mongo probably owns most of the IP for it. I am not sure what he did at Docker but he'd like you to believe the 10 months he spent there was pivotal to docker adoption, nevermind the fact it was already on fire.

Wow! Jealous much.

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.

Jealous? NO. Someone just needed to finally call him out on his bullshit.

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.

What a strange world 2022 is, wherein former employees of MongoDB openly catfight on HN over who was most responsible for suckering some of the Fortune 500 into buying a truckload of technical debt. Arguing over that like it’s taking principal credit for achieving sustained cold fusion. Baffling.

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.

It would serve you better to become clearer in what you are trying to say.

Are you agreeing with the "whistleblower" or not?

Thanks for taking the time to leave this comment.

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.

Thank you for calling out this behavior!

> responsible for taking Go Language, Docker and MongoDB from niche technologies to widespread mainstream enterprise adoption.

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)

To be clear, nobody is claiming that he didn’t write viper, or that he isn’t a brand name in OSS. The claim is that he was responsible for “taking go language from niche technologies to widespread adoption”, which seems like a pretty big one to make.

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.

I mean not only did he create Cobra and Viper, two of the most popular Go libraries, but he also led the Go project for the last 6 years.

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.

In contrast, I think someone like Fabrice Bellard could absolutely use such phrasing without overselling himself... but then again, Bellard doesn't seem to exactly brag about his accomplishments either.

These comments are why i stopped sharing my work. You can clearly tell that it is not the authors intent but someone (you) will always take things personal when given the chance.

I briefly used youtube's spfjs library for something people now a days call island architecture.

Given the name similarity, I was wondering if the author also had some involvement in that library, but looks like not.

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.

Thanks a bunch!

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?

I’d recommend lunar vim

I would recommend Neovim. The plugin ecosystem is way richer due to them fully embracing Lua.

It's the first I've heard of it. What am I missing out on as a (fairly vanilla) vim user?

> Over the past 6 years Go’s user base has grown ~10x and Go users have increased their frequency from occasional to daily usage.

Impressive. How accurate is this?

I can confirm it's quite accurate. I've been the person responsible for these metrics the entire time cited.

Technically I don't think "author of article says they can confirm that numbers they used in their article are accurate" really holds up as a valid argument ;).

Tongue-in-cheek feedback aside, congrats on all your achievements and good luck on your future projects!

Reading the post you see there are user surveys. Looking for results of those surveys we find this:

> Over half (55%) of respondents use Go at work on a daily basis.

https://go.dev/blog/survey2021-results

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.

Two Sigma (and others) have been poaching senior level google talent at a quicker and quicker clip.

Very exciting to watch the exodus happen!

Hedge funds/hf trading companies can't compete with monopolies in printing money. I wonder how they are getting all these people.

Google has to try to hire and keep satisfied thousands upon thousands of engineers of various talent levels.

A smaller team just has to pay more than that for a few tens, and perhaps offer more interesting work besides.

Google hasn't kept up with industry pay. As a senior Google engineer, you can get much better pay in other firms.

High performing hedge funds make way more money per employee than Google.

Snowflake and Databricks also hoover up a bunch of engineers, snowflake in particular extracted a large number of extremely senior folks. I assume they match base comp, offer equity, and then give people a lot more freedom than they would have at BigCo.

I don't know what you mean by this.

Are you saying trading companies aren't profitable enough?

> I led the team that designed MongoDB’s pioneering user experience

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!

Perhaps Mongo Atlas?

Steve left many years before MongoDB Atlas launched

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.

Thanks, appreciate your response! Didn’t occur to me that you were talking about the UX for the entire ecosystem. Will read your blog for more details.

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

Google search turned up https://www.mongodb.com/docs/manual/ as the MongoDB user manual.

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.

I know nothing about the parent comment but to be fair, he has only 12 commits with about 600 total line changes (additions and deletions) which places him 50th on the contributor list. That doesn't mean much in regards to spf13's involvement.

Thanks, Steve, for all your efforts - Two Sigma will be lucky to have you.

TwoSigma are lucky to have you spf13, thank you for everything you've given Go and the community.

Could use some editing to reduce the occurrence of "I".

No doubt spf13 is a very smart and capable person.

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 :)

does it help that the title is in third person?

I mean... the lead-in photo screams narcissism.

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.

You should be proud of the work you’ve done on Go. Shipping a widely used language and bootstrapping a new ecosystem is no small task.

Thank you for your work on all those different technologies that have made our life easier! Feel proud of all of it!

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

They are a very famous quant fund

For the normal distribution, 2-sigma events happen around 5% of the time:

    >>> import statistics                                                         
    >>> 2*statistics.NormalDist().cdf(-2)                                         
    0.04550026389635842

I believe it is "five sigma" which carries this stigma (because many value-at-risk models saw the market moves in 2008 as a 5 sigma event).

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.

Such a great collection of projects, he in a lot of ways reshaped basic software tooling. Also met him at gophercon one year and he was a cool guy

Good luck and thanks for all your work on Go!

Thank you!

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?

I'm really curious about that also

Two Sigma is notoriously tightlipped about everything. This guy's short post about interning there in 2015 is probably the most I've even seen about working there: https://evjang.com/2015/08/17/internship-experiences.html

In terms of "tightlippness", they don't come close to TGS Mgmt. All of their employees can't even list their employment at TGS Mgmt on LinkedIn.

I worked at a firm who had the same policy in 2014.

It was more common than you may have realized.

Honestly, most boutique, government-involved security consulting firms have similar requirements. Given how much of tech is outsourced these days, obscurity is often the only line of defense some organisations have.

So smart stock trading. Cool. The best and brightest are off solving math problems to make bank in the stock market.

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.

What kind of engineering culture do they have? Can people continue down the technical route without needing to jump into management?

One of the few places that will pay competitive to GOOG.

*Much better than Google. Two Sigma is one of the top paying companies: https://www.levels.fyi/leaderboard/Software-Engineer/Entry-L...

They pay _interns_ $70 per hour

Depends on the role, in general they’re not going to blow Google out of the water.

They typically can for Individual Contributors that are software engineers

GOOG is no longer known for high pay. Given the same level, even Meta has exceeded Google pay for a long time now. That's not to mention hedge funds like Two Sigma or Citadel.

Looking at their careers postings, it seems spf13 will have to spend some time refreshing his C++ and Python skills.

Cool = Money

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

#1 Continue working with exceptional people.

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

Wow, thanks for all those great contributions.

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?

Say what you will about Google but at least it's not a complete fucking parasite on society and the economy like a hedge fund.

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.

It's not intellectually honest to weigh Google's worst actions (like tricking poor people into clicking on ads, when they would obviously much rather trick rich people to click on ads) without also weighing their contributions to the world, of which the hedge fund has none.

Nah, it just does data mining across all their platforms to feed their ads infrastructure, what is wrong about that.

Thanks for the work you do/did on Hugo! All the best for your journey at Two Sigma! \o/

Thank you for everything you’ve done spf13. I wish you the best of luck on your next venture!

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.

That's an exceptionally garbage link color scheme

Yeah the flashy gradients are a bit distracting.

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.

Who cares, seriously?

> Who cares, seriously?

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?

Reply on news.ycombinator.com