Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 4:44 PM Space A.  wrote:

> Did you ever read below the title
>

Yes, I did. I even read the full proposal, all the comments and related
issues in the issue tracker, and all the messages in this thread and other
threads on golang-nuts. This is why I wrote this message :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG3yVS6SbxSsD4jxft3s1X0i%3DUnGfjNWQ3_uCbay1vcob%3Dn4TQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 3:36 PM Wojciech S. Czarnecki 
wrote:

> Because given piece of contemporary production code may succeed in
> only ONE way, but it may FAIL in many ways.


If a piece of code may fail in many ways, then it will probably have
several if blocks, and try will not be used. I don't see how this is an
argument against try…

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG3yVS4_hRtNcbXq21pigzkq8ZvxDuSM9NWamsj8NrH%3DAADtFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 2:00 PM Ian Davis  wrote:

> It's quite a bit more than a just new function since it brings some new
> behaviours that we don't have for functions in Go at the moment:
>
> 1. like panic it interrupts its caller's control flow
>
> 2. It may only be used within functions/methods that have a particular
> signature. Presumably it's a compile error to attempt to use it elsewhere.
>
> 3. It accepts any number of mixed type arguments without boxing into an
> interface{}
>

try is not a new function, it's a new *built-in* function. The behaviours
you are mentioning are normal for a built-in function. Robert Griesemer has
already commented about this several times in the issue tracker, for
example here:
https://github.com/golang/go/issues/32437#issuecomment-509337453

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG3yVS4%2BmRzobDA_JQnzQ8%3DRBM6y2F9-mwnM2X0auJV9dX93Ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: `on err` alternative to `try()` has traction...?

[Nicolas Grilly]

On Tue, Jul 9, 2019 at 1:57 PM Jan Mercl <0xj...@gmail.com> wrote:

> It's not verbosity. It's error handling. And because error handling is
> usually not the happy path, it's good when it stands out clearly. That
> improves readability as the important part catches attention easier.
>

I agree that the "sad" path is as important as the "happy" path, but I
wouldn't say it's more important to the point of dominating the number of
lines in a function. In some functions, 2/3 or 3/4 of the lines are
dedicated to error handling.


> Hiding important code in one line instead, or with even using nested
> try constructs, makes the important path easier to overlook or to not
> be aware of it at all.
>

try "hides" nothing. try is only useful for returning the error. If there
is some important error handling code in the if statement block, then try
cannot be used and the code stays the same.

Don't you think we could get used to try after using it a bit? This is what
happens to Steve Klabnik when the ? operator was added to Rust. He was
against it, and changed his mind after writing code using it.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAG3yVS6W2SXaeHQYia%2BtynPk5vC1gMkBz6%3DgXjacCe1OQSD3CA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: `on err` alternative to `try()` has traction...?

[Nicolas Grilly]

On Thursday, July 4, 2019 at 5:14:40 PM UTC+2, Michael Ellis wrote:
>
> In my view, saving a few keystrokes is not the reason to support such a 
> test. I've already got an editor snippet that generates a default "if err 
> != nil ... " clause.
>

The goal of the try proposal is not to "save a few keystrokes".  The goal 
is to reduce error handling verbosity when reading code.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d01e3498-3f04-45ad-867b-7b85b3b14399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: `on err` alternative to `try()` has traction...?

[Nicolas Grilly]

On Thursday, July 4, 2019 at 10:55:50 AM UTC+2, Slawomir Pryczek wrote:
>
> going to turn code into unreadable, fragmented mess
>

Do you really think that replacing:

f, err := os.Open("file.txt")
if err != nil { 
  return err
}

By:

f := try(os.Open("file.txt"))

Will "turn code into unreadable, fragmented mess"? Isn't it a bit of an 
overstatement?
 

> My point is it doesn't fix anything, it doesn't provide any clear 
> benefit... it's an attempt to fix something which works great and is 
> clearly not broken. 
>

try fixes error handling verbosity, while keeping the language grammar and 
semantics unchanged. I respect that error handling verbosity is not an 
issue for you, but when you wrote that it is "clearly not broken" you're 
denying it can be an issue for other Go developers.
 

> So why complicate the language with a new keyword which has really no 
> purpose.
>

As mentioned in the proposal, try is not a new keyword, it's just a new 
built-in function.

Maybe adding a warning about unhandled errors to VET would be better idea 
> (which would probably be complicated to do properly, but at least it'll 
> have some real, positive effect on code quality).
>

The compiler and vet already report unhandled errors. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3153b982-7b8b-45ac-9a33-29f661b468da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Monday, July 1, 2019 at 8:46:29 AM UTC+2, Sanjay wrote:
>
> His actual proposal paper is also an interesting read: 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf.
>

This is fascinating read about language design in general and error 
handling in particular. Thanks for sharing. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b85e005e-62f1-4b9a-903d-2ac8e173d7c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The "leave "if err != nil" alone?" anti-proposal

[Nicolas Grilly]

On Saturday, July 6, 2019 at 12:22:33 AM UTC+2, Jakub Labath wrote:
>
> Some of us had to fix so much broken java/python code with invisible and 
> anonymous goto statements (aka exceptions) that even just seeing the 
> keyword try prompts a physical reaction.
>

"Just seeing the keyword try prompts a physical reaction"?… Maybe this is 
the issue with this discussion: too much emotions, not enough rational 
arguments. 

try is just syntactic sugar for `if err != nil { return ..., err }` and 
nothing more. 

try doesn't change the language grammar and semantics at all: 
- error handling is still explicit;
- error are still values;
- there is still no stack unwinding;
- etc. 

The comparison with exceptions (and anonymous goto statements) is 
completely uncalled for.

I'm baffled by the amount of negative emotions, strong feelings and harsh 
reactions to the addition of a minor built-in function whose sole goal is 
to reduce verbosity by factoring out a repetitive pattern.

I'm seeing people lecturing the Go team about the "language philosophy" and 
submitting "alternative proposals" without understanding the difference 
between a keyword, a built-in function and a statement…

Maybe the try proposal is not perfect and maybe it needs to be improved. 
It's open to discussion. The Go team has made it clear they will listen, as 
they already did in the past with the check/handle proposal. But instead of 
bringing constructive arguments to improve the proposal, many comments are 
about killing the proposal, "leave if != err alone", and change nothing. 
These comments summon the "community", but I'm afraid it's not the kind of 
community I want to be in.

I have an immense respect for the design documents produced by the Go team 
these last few years on many subjects: garbage collection, dependency 
management, error handling, generics, etc. This is exactly the kind of 
engineering I want to see and that made me use Go.

So please fellow gophers, continue to tell the Go team what you'd want to 
be improved in the try proposal, but have a little faith in their work :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e337d6d6-3e73-4132-9776-11c904fabe5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go += Package Versioning

[Nicolas Grilly]

On Fri, Feb 23, 2018 at 8:20 AM, David Anderson  wrote:

> The date+hash format is irritating to construct by hand, but could be
> trivially lifted into a tool (perhaps even vgo itself).
>

Very true. I suffered from the same issue while trying vgo. This could be
improved to ease the adoption of vgo by projects with many dependencies
that are not already compatible with vgo semver.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go += Package Versioning

[Nicolas Grilly]

I like this!

One question:

Some of us commit their `vendor` folder, to be able to build the project 
without any network access after the initial checkout ("offline mode").

Since the `vendor` folder is gone, is vgo able to manage and use a kind of 
`mirror` folder, which would contain the .zip archives of the project 
dependencies? This folder could be committed with the project source code.

The yarn package manager, for example, has a similar feature:
https://yarnpkg.com/blog/2016/11/24/offline-mirror/

On Tuesday, February 20, 2018 at 6:20:54 PM UTC+1, Russ Cox wrote:
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Ternary operator needed in Go

[Nicolas Grilly]

On Monday, October 16, 2017 at 8:37:25 PM UTC+2, Dave Cheney wrote:
>
> Prior to this recent post, this thread had been dormant for eight years. I 
> think the results speak for themselves and this topic does not need to be 
> revisited again.


At least, it proves people are searching in the mailing list archive before 
posting, which is great, isn't it? ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Make error handling less verbose with Zig %% operator and %return expression?

[Nicolas Grilly]

On Wednesday, October 18, 2017 at 4:50:32 AM UTC+2, Bryan Mills wrote:
>
> There are lots of similar proposals in the issue tracker.
> Of those, https://golang.org/issue/21161 seems to have the most traffic.
>

Bryan, thanks for the link. I wasn't aware of Ian's proposal.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Make error handling less verbose with Zig %% operator and %return expression?

[Nicolas Grilly]

I just read about Zig, a new programming language designed to replace C.

The error handling philosophy is very similar to Go: control flow in 
general and error handling in particular is explicit. Zig has even a defer 
statement inspired by Go ;-)

I noticed that Zig provides a %% operator and %return expression meant to 
make error handling less verbose:

http://ziglang.org/documentation/master/#errors

I'd be curious to know if something similar would be possible in a future 
version of Go?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Compile-time parameters in Zig: a possible solution to generic functions and data structures in Go?

[Nicolas Grilly]

Hello,

I just read about the concept of compile-time parameters in Zig (a new 
programming language designed to replace C):

http://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html

Could it be a way to provide generic functions and data structures in Go?

I note we already have some kind of "compile-time feature" with constants.

Nicolas Grilly

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] What dependency management tool do you use?

[Nicolas Grilly]

On Saturday, July 16, 2016 at 3:17:11 PM UTC+2, Peter Mogensen wrote: 
>
> It's somewhat the same as we use: 
> * Don't use "go get" 
> * Have GOTPATH=${PWD} in project root. 
> * Have a /src directory in the project containing a link to project root 
> (often ../..) at the package name. 
> * Use gvt for vendoring everything into /vendor 
>
> I ended up with this since I had a multi-language project which I needed 
> to build debian pakcages too. And I could fulfill all the laguagees 
> different "demands" for layout (incl. go) at the same time as having 
> deb-helper recognize the build systems. 
>

This is an excellent "recipe". I do something similar for a multi-language 
project (Python + Go).

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.