Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spf13 is leaving Google

spf13.com

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Spf13 is leaving Google

#151

Post by Cthulhu_ »

konart wrote: post #111
noisy_boy wrote: post #92

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 operator…

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

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

Re: Spf13 is leaving Google

#152

Post by cies »

Cthulhu_ wrote: post #144
cies wrote: post #142

Earlier quoted context omitted.

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 p…

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

Re: Spf13 is leaving Google

#153

Post by bigbluedots »

noisy_boy wrote: post #92

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 operator…

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

Re: Spf13 is leaving Google

#154

Post by yakubin »

pjmlp wrote: post #141
herval wrote: post #94

Earlier quoted context omitted.

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.

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.

Re: Spf13 is leaving Google

#155

Post by Tarq0n »

bee_rider wrote: post #70
tick_tock_tick wrote: post #44

Earlier quoted context omitted.

I'd hope so; it would be pretty damn embarrassing if you couldn't do a slightly advanced fuzz buzz.

A tree is just a type of graph. A graph can be represented as an adjacency matrix. So come up with that matrix, then drop it into lapack for inversion. Lapack is well optimized so this is probably a very good solution.

Isn't that the idea behind graphBLAS? http://graphblas.engr.ucsb.edu/

Re: Spf13 is leaving Google

#156

Post by [deleted] »

Cthulhu_ wrote: post #151
konart wrote: post #111

Earlier quoted context omitted.

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

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

[deleted]

Re: Spf13 is leaving Google

#158

Post by pm90 »

rfeague wrote: post #45

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?

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

Re: Spf13 is leaving Google

#159

Post by marricks »

lelandfe wrote: post #49
rfeague wrote: post #45

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?

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

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

Re: Spf13 is leaving Google

#160

Post by dekhn »

konart wrote: post #111
noisy_boy wrote: post #92

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 operator…

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

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