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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

421–430 of 670 posts

Re: Toward Go 2

#421

Post by grogenaut »

tsuraan wrote: post #364
grogenaut wrote: post #341

Earlier quoted context omitted.

You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.

Have you used erlang? Pattern matching is a big part of it, and pattern match failures always result in errors. So, if you have some function foo() that always returns ok or {error, Reason}, then in the "follow the happy path" style, you'd just have a line reading "ok = foo(),", and then if foo actually returns something else, you get a "crash". There's no assuming anything there, it's just the way the language works…

Yes I have. but I see the erlang blindness still runs strong. Just because you have pattern matching doesn't mean you don't have bugs cause by humans. It can be syntactically correct and also logically not match the problem domain.

For example what if you screw up and forget to encode that it SHOUDN'T return OK?

you know that many other frameworks also have these safeguards right? Java server frameworks have been doing it forevever. You can code dirty if you want and deal with no issues or you can be error prone. Hell you can do the same thing in go. You can catch panics. It's not pretty but you can definitely do it.

I forgot one can only point out strengths of erlang not problems with humans coding in general. all hail erlang.

Re: Toward Go 2

#422

Post by seanmcdirmid »

herrschnapps wrote: post #253
seanmcdirmid wrote: post #117

Earlier quoted context omitted.

It is new to C#, which is slowly catching up to Scala and F# in that regards. Mads Torgesen is good friends with Martin Odersky, in fact, when I first met Mads back in 2006 or so, they were talking about adding pattern matching to C#. C# is a much more conservative language, and it makes sense it would take a while to add. There are good reasons to use C#, so when it gets a new feature that other languages have had f…

It's just become a Stage 0 proposal: https://github.com/tc39/proposal-pattern-matching

Woo hoo, can't wait. Especially with what TypeScript can do with this.

Re: Toward Go 2

#423

Post by zemo »

vec wrote: post #291
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

> I'm not even a Go developer

> Using `interface{}` to temporarily escape the type system

tbh if you program Go correctly, you use interface{} pretty rarely.

Re: Toward Go 2

#424

Post by grogenaut »

pmarreck wrote: post #352
grogenaut wrote: post #341

Earlier quoted context omitted.

You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.

Why wouldn't it, if you're pattern-matching correctly? And in any event, it seems far easier to get into that situation in Go (which ignores errors unless you explicitly check for them) than in Erlang (which crashes on every error because restarting is cheap)

My point is... "Pattern matching correctly"... assumes no mistakes on the coder's part. Go back and re-read my comment. Or don't. Downvote me because I dare question your skill in the context of the mighty erlang.

Re: Toward Go 2

#425

Post by vacri »

artursapek wrote: post #93
brango wrote: post #68

Earlier quoted context omitted.

There's no obvious way to separate personal work, from work work, from exploratory work, from any other way you want to categorise your source directories. You just have to chuck them all in the same root and hope you can remember what each project is for.

What? Manage it the way you'd manage any other environment variables, like AWS_SECRET_ACCESS_KEY. That's exactly what a bash environment is for.

You want to manage GOPATH as if it were a secret key!? Not ever storing it in repos, having weird dotfiles storing them locally, having to set up a keystore cluster like consul in production? Yuck.

Re: Toward Go 2

#426

Post by spyspy »

vec wrote: post #291
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

Re: Toward Go 2

#427

Post by throwaway91111 »

willtim wrote: post #108
jcstk wrote: post #88

Earlier quoted context omitted.

Ditto on generic methods both changing the game for Dart and being necessary. I spend most of my time in Dart, Swift and ObjC, and I've built serious applications in Erlang and Java. All of which I like for different reasons. My opinion is that Dart's type system is the optimal type system. It allows for statically typed API surface, but at the same time, I can still add some dynamic voodoo under the surface and enab…

As a far as I can tell, an "optional type system" is just an unsound type system with a marketing name. Any decent static type system would allow one to progressively increase the level of typing, the weakest form being using a Variant type to hold all other types. The advantage here is that any invariants/proofs that are captured in the system are not compromised by unsoundness.

As a whole, you are correct. Pragmatically it allows defining the boundaries of soundness.

Re: Toward Go 2

#428

Post by kevhito »

wwweston wrote: post #121
crawshaw wrote: post #5

Earlier quoted context omitted.

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough. As other respondents to the GP comment show, it's not at all…

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough"

And that's just in your first sentence.

My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team members contradicts that. I'm open to citations if you can give any.

In contrast, a lot of Go users and proponents seem to be vehemently against generics, for wildly differing reasons. Some seem to be against them just for the lulz, others for crazy conspiracy theory or obscure philosophical reasons.

Me, I miss generics sometimes, but not enough to get riled up about it. I hope the Go folks come up with a clean, simple, and efficient way to get them, but until then I'm happy with the features Go has.

Re: Toward Go 2

#429

Post by rbehrends »

spyspy wrote: post #426
vec wrote: post #291

Earlier quoted context omitted.

I'm not even a Go developer, I just played with it a bit a couple of years ago and used it for a small one-off internal API thing, and I can think of a dozen real-world use cases for generics off the top of my head. * type-safe containers (linked lists, trees, etc.) * higher order functions (map, reduce, filter, etc.) * database adapters (i.e. something like `sql.NullColumn ` instead of half a dozen variations on `sq…

It's generally the opinion of the Go community that map, reduce and filter are bad ideas due to how easily they are abused. A for loop gets the job done easily enough. If you've ever worked with data scientists working with Python, you'll quite often see them all chained together, probably with some other list comprehensions thrown in until it becomes one incomprehensible line.

The same argument applies, mutatis mutandis, to imperative iteration constructs such as range.

Re: Toward Go 2

#430

Post by lemoncucumber »

lemoncucumber wrote: post #158

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write: for foo := range(bar) Instead of: for _, foo := range(bar) When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the val…

Here's a toy version of a real bug that I wasted a bit of time debugging which was due to this behavior: https://play.golang.org/p/6pBUPBTTvj
Post reply on HN