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

141–150 of 179 posts

Re: Spf13 is leaving Google

#141

Post by pjmlp »

herval wrote: post #94
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…

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.

Re: Spf13 is leaving Google

#142

Post by cies »

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…

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?

Re: Spf13 is leaving Google

#143

Post by ndr »

peoplefromibiza wrote: post #129
IshKebab wrote: post #119

Earlier quoted context omitted.

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

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.

Re: Spf13 is leaving Google

#144

Post by Cthulhu_ »

cies wrote: post #142
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…

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.

Re: Spf13 is leaving Google

#145

Post by simiones »

peoplefromibiza wrote: post #129
IshKebab wrote: post #119

Earlier quoted context omitted.

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

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.

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

Re: Spf13 is leaving Google

#146

Post by hnfong »

alecbz wrote: post #23
1-6 wrote: post #20

Earlier quoted context omitted.

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

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

Re: Spf13 is leaving Google

#147

Post by badsectoracula »

giveupitscrazy wrote: post #116
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.

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.

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

Re: Spf13 is leaving Google

#148

Post by Gentil »

mikevm wrote: post #137

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?

Re: Spf13 is leaving Google

#149

Post by HelloNurse »

Cthulhu_ wrote: post #135
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…

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

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

Post reply on HN