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

Go 1.13: xerrors

crawshaw.io

Post reply on HN
Print view View original

121–130 of 150 posts

Re: Go 1.13: xerrors

#121

Post by AsyncAwait »

apta wrote: post #100
AsyncAwait wrote: post #79

Earlier quoted context omitted.

> I wouldn't necessarily call Go's concurrency model superior Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. > I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os Is that OS written in Java or C#, because that's what the discussion was about. Also, CSP is not the only way of doing…

> the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency. > Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. golang doesn'…

> Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency.

Kotlin does that today and I like Kotlin, however the fact is that the class-everywhere Java approach just doesn't sync with me. Go's and Rust approach to OO with value-based types (structs) suits me much better.

> golang doesn't even have concurrent data structures

Not strictly true. It does have sync.Map There's also 3rd party packages offering this.

Re: Go 1.13: xerrors

#122

Post by grey-area »

RHSeeger wrote: post #85
grey-area wrote: post #81

Earlier quoted context omitted.

Language design has nothing to do with discussions on HN (at least I hope not!). It’s very easy and not very useful to come up with vague criticisms based on generalities, it’s much harder, but infinitely more fertile and interesting, to come up with a coherent thesis as to what should be done. The OP posited a right way, I’m curious as to which of the right ways they mean.

I would say that design has a lot to do with discussion.

There are different kinds of discussion, I don't think a discussion site is the right forum for design, do you?

Also discussion requires some content, not empty complaints without any backup. For example propose a different mechanism for reporting errors, like optional types or exceptions (both have potential problems). The OP would be more interesting if it actually tried to engage with the problem.

Re: Go 1.13: xerrors

#123

Post by hu3 »

apta wrote: post #101
hu3 wrote: post #90

Earlier quoted context omitted.

Ever considered that in 1995 some aspects of Limbo weren't as appealing as they are today and that this played a great deal in its adoption? For example its CSP concurrency model, similar to Go, was hardly pertinent when common processors were 150 MHz Pentiums with 1 core. Completely different scenarios. Not to mention Bell Labs had enormous influence on Computer Science at the time so it's not like Limbo had no stro…

> For example its CSP concurrency model, similar to Go, was hardly pertinent when common processors were 150 MHz Pentiums with 1 core. Completely different scenarios. There was always demand for having servers that processed high numbers of requests (e.g. C10K). Just because single core processing was common does not mean that there wasn't need for high concurrency. > Not to mention Bell Labs had enormous influence o…

> There was always demand for having servers that processed high numbers of requests (e.g. C10K)

Demand is not binary. In 1995 the demand for concurrency was a fraction what it is today. Not only multicore processing was an extremely rare sighting in comparison to what we have today but also:

1. Internet was accessed by 10% of the population vs today's 80%+

2. Capable smartphones? First iPhone came only 12 years later. There was no such thing as internet during commute.

3. C10K for example was coined only in 1999.

The 20 years between 1995 and 2015 did change the IT landscape wildly regardless of your beliefs.

Re: Go 1.13: xerrors

#124

Post by lenkite »

I think this is a positive development and should be cheered by Go programmers. Slowly but surely they progress on the road to implementing Exceptions. (ducks and runs like a scaredy cat to avoid the wrath of Go Fans)

Re: Go 1.13: xerrors

#125

Post by jrockway »

fauigerzigerk wrote: post #120
jrockway wrote: post #113

Earlier quoted context omitted.

If that's correct, then our systems are built on false assumptions. SSDs should not see an ECC error and write the data to a new block; that error should kill your program. TCP should not detect packet loss and retransmit, it should kill your program? My point is, a lot of good error handling is built at the lowest level, close to the point of failure. That code knows what the problems are and how to fix them. Errors…

>My point is, a lot of good error handling is built at the lowest level, close to the point of failure. This is very true for some types of errors and for some types of programs but not true at all for others, which is why this debate has been going on and on for decades. An extremely common example for the latter is programs that touch a DBMS or file system on every other line. You don't want to see error handling c…

I just don't agree with adding more syntax to the language for what basically amounts to an if statement. If it's a conditional, which it is, just use an if statement.

Look at all the monad tutorials for Haskell. Nobody knows how to use the special syntax for Maybe and Either. They read hundreds of articles and still don't get it. Meanwhile, everyone understands how "if err != nil" works, perhaps too well, which is why they complain about it.

Re: Go 1.13: xerrors

#126

Post by teabee89 »

What I'm really looking for is being able to debug any production Go binary by inspecting the stack trace behind an error. Could be gated by an environment variable.

Re: Go 1.13: xerrors

#127

Post by apta »

Bendingo wrote: post #112
apta wrote: post #75

Earlier quoted context omitted.

Except that TypeScript's designer had strong and established experience in language design, and he made a lot of correct choices when implementing TypeScript. Can't say that about golang.

I'm not sure if you're casting aspersions on Rob Pike and Ken Thompson. But they are truly giants of computer science giants and they are behind golang. Can't say that about typescript (or any other language I can think of).

They have contributions, but not in programming language design. I was specific to point that out.

Re: Go 1.13: xerrors

#128

Post by apta »

hu3 wrote: post #123
apta wrote: post #101

Earlier quoted context omitted.

> For example its CSP concurrency model, similar to Go, was hardly pertinent when common processors were 150 MHz Pentiums with 1 core. Completely different scenarios. There was always demand for having servers that processed high numbers of requests (e.g. C10K). Just because single core processing was common does not mean that there wasn't need for high concurrency. > Not to mention Bell Labs had enormous influence o…

> There was always demand for having servers that processed high numbers of requests (e.g. C10K) Demand is not binary. In 1995 the demand for concurrency was a fraction what it is today. Not only multicore processing was an extremely rare sighting in comparison to what we have today but also: 1. Internet was accessed by 10% of the population vs today's 80%+ 2. Capable smartphones? First iPhone came only 12 years late…

When did Erlang come out? There clearly was interest in concurrency, otherwise, why make a new programming language (limbo or otherwise) just for the sake of it?

Just because multicore wasn't common doesn't mean that concurrency wasn't important. Event loops have practically always been there on widely used OS's.

Re: Go 1.13: xerrors

#129

Post by apta »

AsyncAwait wrote: post #121
apta wrote: post #100

Earlier quoted context omitted.

> the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency. > Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered. golang doesn'…

> Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency. Kotlin does that today and I like Kotlin, however the fact is that the class-everywhere Java approach just doesn't sync with me. Go's and Rust approach to OO with value-based types (structs) suits me much better. > golang doesn't even have concurrent data structures Not st…

> Kotlin does that today and I like Kotlin,

Kotlin's coroutines are still not like fibers (it's still affected by: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...)

Java is getting record types as well. That being said, one is free to use whatever JVM language they like and still get the huge benefits of the JVM, regardless of the language.

> Not strictly true. It does have sync.Map There's also 3rd party packages offering this.

Which still uses locks behind the scenes. Java's concurrent structures are lockless in general (lockless maps, lockless queues, channels, etc.). Not to mention casting to and from interface{} which is error prone and very tedious and verbose.

Re: Go 1.13: xerrors

#130

Post by llimllib »

acrispino wrote: post #25
llimllib wrote: post #19

Earlier quoted context omitted.

return errors.Wrap(err, "read failed")

That is not part of xerrors at this point. Rationale: https://github.com/golang/go/issues/29934#issuecomment-46420... Personally, I don't care for "string magic" Edit: Instead of making another post, I'll add this here. It also feels odd that concerns about xerrors.As possibly panicking at runtime are considered addressed by the addition of a go vet check: https://github.com/golang/go/issues/29934#issuecomment-46252.…

Thank you, my bad!
Post reply on HN