Re: [go-nuts] YAEHI (Yet another error-handling idea)

[Andrey Tcherepanov]

Thank you Michael.

I honestly never looked at it from a human-language prospective! Maybe 
because 25+ years of interacting with programming languages made me a bit 
deaf to the sound of it, and my head is kind of translating it back and 
forth transparently. To think of it, it might explain why I find sometimes 
it is easier to express ideas in code than a just plain old English... 
*sigh*

Andrey

On Saturday, June 29, 2019 at 5:05:44 PM UTC-6, Michael Jones wrote:
>
> My personal thought, though it may seem strange, is that the best argument 
> for it lies in the single word sentence at the bottom of your email. You 
> write "Thoughts?" -- and that is very expressive in English in just the way 
> that you mean above in your examples. I don't know enough other languages 
> to really know if the parallels are universal, but it's pretty clear to me 
> what it means why "file?.close()" and "os.Open(filename)?" are "punctuated" 
> as they are -- where the question is. I feel like you're asking this 
> compiler, "is there anything about this value that you need to tell me?" I 
> like that.
>
> The long (crazy long!) discussion of error handling has among its many 
> branches an analysis from the Go team about '?' and this kind of postfix 
> interrogation. I'm watching it all with a bit of wonder, but I wanted to 
> speak up and say how your human-language phrasing matches your idea of 
> computer-language phrasing. That seems a powerful kind of naturalness to 
> take advantage of in this issue and future ones.
>
> On Sat, Jun 29, 2019 at 2:56 PM Andrey Tcherepanov <
> xnow4f...@sneakemail.com > wrote:
>
>> Hello mighty fighters of errors!
>>
>> Here comes my half-thought idea of another way to express error handling:
>>
>> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND 
>> an error for nil. *
>>
>> (Denis have shred it to pieces already in 
>> https://github.com/golang/go/issues/32852. Thank you Denis.)
>>
>> I am not good with expressing my inner talk, so there are couple examples
>>
>> original , Go 1 function
>>
>> func stat(filename string) (os.FileInfo, error) {
>>
>> var info os.FileInfo
>> {
>> var a1 *os.File
>> if a1, err := os.Open(filename); err != nil || a1 == nil {
>> return _, err
>> }
>> var a2 os.FileInfo
>> if a2, err := a1.Stat(); err != nil || a2 == nil {
>> return _, err
>> }
>> info = a2
>> }
>> return info, nil
>> }
>>
>>
>> And with "?", trying to avoid original try() proposal handle leak
>>
>> // would return _, err, but since there is no err in signature, will return 
>> default value in case of error
>> // uses ? on func call that returns (value, error)
>> func stat2(filename string) (os.FileInfo) {
>>  file := os.Open(filename)? 
>>  defer file.Close()
>>  return file.Stat()?
>> }
>> // would return error too, uses ? as "not nil" on a variable too
>> func stat3(filename string) (_ os.FileInfo, err error) {
>>  var file *os.File
>>  defer file?.Close()
>>  file := os.Open(filename)?
>>  return file.Stat()
>> }
>>
>>
>> Thoughts?
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b7520ffe-ec38-4157-8f95-92844dcb0d0f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

-- 
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/12572785-f0aa-4f84-a0c4-1096364a1f94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: YAEHI (Yet another error-handling idea)

[Andrey Tcherepanov]

I think it is no different from regular "if err != nil {}" handling, sorry

My thought behind ? is to make is working for a simple cases. If you are 
doing an error translation/transform/wrapping - this is a case that I feel 
is better handled by existing explicit "if err != nil" construct.

A.

On Sunday, June 30, 2019 at 3:12:18 AM UTC-6, mh cbon wrote:
>
> f := file.Open() ? error {
> //f is nill
> return erors.Wrap("nop",err)
> }
> defer f.Close()
>
> On Saturday, June 29, 2019 at 11:56:09 PM UTC+2, Andrey Tcherepanov wrote:
>>
>> Hello mighty fighters of errors!
>>
>> Here comes my half-thought idea of another way to express error handling:
>>
>> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND 
>> an error for nil. *
>>
>> (Denis have shred it to pieces already in 
>> https://github.com/golang/go/issues/32852. Thank you Denis.)
>>
>> I am not good with expressing my inner talk, so there are couple examples
>>
>> original , Go 1 function
>>
>> func stat(filename string) (os.FileInfo, error) {
>>
>> var info os.FileInfo
>> {
>> var a1 *os.File
>> if a1, err := os.Open(filename); err != nil || a1 == nil {
>> return _, err
>> }
>> var a2 os.FileInfo
>> if a2, err := a1.Stat(); err != nil || a2 == nil {
>> return _, err
>> }
>> info = a2
>> }
>> return info, nil
>> }
>>
>>
>> And with "?", trying to avoid original try() proposal handle leak
>>
>> // would return _, err, but since there is no err in signature, will return 
>> default value in case of error
>> // uses ? on func call that returns (value, error)
>> func stat2(filename string) (os.FileInfo) {
>>  file := os.Open(filename)? 
>>  defer file.Close()
>>  return file.Stat()?
>> }
>> // would return error too, uses ? as "not nil" on a variable too
>> func stat3(filename string) (_ os.FileInfo, err error) {
>>  var file *os.File
>>  defer file?.Close()
>>  file := os.Open(filename)?
>>  return file.Stat()
>> }
>>
>>
>> Thoughts?
>>
>

-- 
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/e71bc0cc-61d7-4f3c-ab3f-5972c87b6663%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Counter-counter-counter proposals

[andrey mirtchovski]

"Users don't care about what the designer does. They care about what
they do. If every time you drove a car, you had to learn the meaning
of 100 knobs, the whole system wouldn't work. Simplicity comes from
tuning down the tasks required to drive the car into a certain set of
understood paradigms and tools. Yes, there are many people who would
love to pull up the hood and start tinkering with things. You can let
them, as long as that is all under the hood."

On Sun, Jun 30, 2019 at 8:50 PM Michael Jones  wrote:
>
> With so many strongly worded emotional emails flying it might be helpful to 
> remember that language design is about other people and other use cases than 
> your own. The truly good answer meets the needs of many and harms few, 
> anticipates that no answer is final, and is flexible. Here is a nice way to 
> think about it:
>
> Taste and Aesthetics, A Conversation with Ken Arnold, Part II
> by Bill Venners, September 16, 2002
> https://www.artima.com/intv/taste.html
>
>
> Responsibility for others means focusing on issues beyond your own. As CTO of 
> Google Maps, Earth, and Local Search, I had to think about what was good for 
> 1.5 billion unique monthly users, not what was good to me as a map guy. The 
> Go designers are in the same situation. When we offer advice to them, we 
> might best think that way too.
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>
> --
> 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/CALoEmQze-1ZuY5NTijiTmrpzbnbRzUT_kKD88s0XBzNHzqHjdw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAK4xykVM%2ByivZJGPSVYj%3D5PPNwyZDDpfuA8pKyjQAOuRv7Mx3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Counter-counter-counter proposals

[Jan Mercl]

On Mon, Jul 1, 2019 at 4:50 AM Michael Jones  wrote:

> ... language design is about other people and other use cases than your own.

That nicely explains C++ existence.

-- 
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/CAA40n-UHdpZuAMTESusufRmmtBEt5cUyGAPo5F4wen9do%3DXyoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Counter-counter-counter proposals

[Dan Kortschak]

Thank you for sending that. That is a wonderful interview.

On Sun, 2019-06-30 at 19:49 -0700, Michael Jones wrote:
> With so many strongly worded emotional emails flying it might be
> helpful to
> remember that language design is about other people and other use
> cases
> than your own. The truly good answer meets the needs of many and
> harms few,
> anticipates that no answer is final, and is flexible. Here is a nice
> way to
> think about it:
> 
> Taste and Aesthetics, A Conversation with Ken Arnold, Part II
> by Bill Venners, September 16, 2002
> https://www.artima.com/intv/taste.html
> 
> 
> Responsibility for others means focusing on issues beyond your own.
> As CTO
> of Google Maps, Earth, and Local Search, I had to think about what
> was good
> for 1.5 billion unique monthly users, not what was good to me as a
> map guy.
> The Go designers are in the same situation. When we offer advice to
> them,
> we might best think that way too.
> 
> -- 
> 
> *Michael T. jonesmichael.jo...@gmail.com *
> 

-- 
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/f36652f56d215c675d5b453aa5a0caff184abbde.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Counter-counter-counter proposals

[Michael Jones]

With so many strongly worded emotional emails flying it might be helpful to
remember that language design is about other people and other use cases
than your own. The truly good answer meets the needs of many and harms few,
anticipates that no answer is final, and is flexible. Here is a nice way to
think about it:

Taste and Aesthetics, A Conversation with Ken Arnold, Part II
by Bill Venners, September 16, 2002
https://www.artima.com/intv/taste.html


Responsibility for others means focusing on issues beyond your own. As CTO
of Google Maps, Earth, and Local Search, I had to think about what was good
for 1.5 billion unique monthly users, not what was good to me as a map guy.
The Go designers are in the same situation. When we offer advice to them,
we might best think that way too.

-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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/CALoEmQze-1ZuY5NTijiTmrpzbnbRzUT_kKD88s0XBzNHzqHjdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

I’ve developed systems that wrap checked exceptions in unchecked ones, but in 
every case I can think of it was to “abort to the top” - returning control (or 
exiting) - it is a specialized case of the re-throw, but I would argue it is 
rarely used in anything other than framework type code, with applications code 
typically wrapping the specific exception in an “higher-level application 
checked exception”, that the upper layers handle (possibly inspecting the 
“cause” exception.

As to not answering the question about transferring across Go routines, I 
apologize. It was not intentional - I read the statement a few times and didn’t 
quite get the concern - and meant to get back to it and forgot - but I read it 
again a few times and still don’t understand the problem.

What is particular about Go that makes this difficult? It is pretty common 
practice to pass exceptions across threads in Java and C++ - e.g. fork/join and 
the worker thread throws an exception - the exception is passed to the joining 
thread. Conceptually, it is as if the function was called serially and the 
exception thrown at the fork point. In these cases the exception is wrapped, 
but it has to be because of the strong type system. It is also pretty trivial 
to declare a wrapper function that declares the checked exceptions for clarity 
- this is done routinely in rpc using proxies.

> On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Jun 30, 2019 at 5:23 PM robert engels  wrote:
>> 
>> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
>> behavior. Addressing the points from the Joeal  article,
> 
> Checked exceptions address some of the difficulties with exceptions.
> However, they introduce new difficulties, and I do not believe they
> work in large-scale programs.  In practice, checked exceptions
> degenerate into unchecked exceptions.  Changing the set of exceptions
> that a function throws forces all callers to adjust their set of
> exceptions.  In practice this is so painful that programs catch
> exceptions and turn into them into unchecked exceptions.  There are a
> number of discussions on the Interwebs about the problems with checked
> exceptions; here's one: https://www.artima.com/intv/handcuffs.html .
> 
> I note that you didn't reply to my comment about passing errors across
> goroutines.
> 
> Ian
> 
> -- 
> 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/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/BAD8DE0B-3A77-415D-B8D8-D376E74636B7%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 5:23 PM robert engels  wrote:
>
> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
> behavior. Addressing the points from the Joeal  article,

Checked exceptions address some of the difficulties with exceptions.
However, they introduce new difficulties, and I do not believe they
work in large-scale programs.  In practice, checked exceptions
degenerate into unchecked exceptions.  Changing the set of exceptions
that a function throws forces all callers to adjust their set of
exceptions.  In practice this is so painful that programs catch
exceptions and turn into them into unchecked exceptions.  There are a
number of discussions on the Interwebs about the problems with checked
exceptions; here's one: https://www.artima.com/intv/handcuffs.html .

I note that you didn't reply to my comment about passing errors across
goroutines.

Ian

-- 
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/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this 
behavior. Addressing the points from the Joeal  article,

Point#1
"They are invisible in the source code. Looking at a block of code, including 
functions which may or may not throw exceptions, there is no way to see which 
exceptions might be thrown and from where. This means that even careful code 
inspection doesn’t reveal potential bugs.”

This is not true. It is a limitation of the editor. There are IDEs that will 
annotate every line with the exceptions possibly thrown by the function call - 
it is part of the function signature. The compiler will also clearly complain 
if a checked exception is not handled or re-thrown. The information is there, 
and it is certainly better than having to read documentation (which may not be 
correct) in the Go case. In the Go case, all the compiler knows is that either 
no return values or all return values must be captured (including their types), 
with nothing about possible error values, so how is the developer supposed to 
handle them - I don’t see how that is an improvement. The exception signature 
is far more powerful and self-documenting.

Point #2:

"They create too many possible exit points for a function. To write correct 
code, you really have to think about every possible code path through your 
function. Every time you call a function that can raise an exception and don’t 
catch it on the spot, you create opportunities for surprise bugs caused by 
functions that terminated abruptly, leaving data in an inconsistent state, or 
other code paths that you didn’t think about."

This is not true as well. It is common understanding when working with 
exceptions, that there are 3 typical outcomes: 1. retry 2. re-throw 3. log and 
return from function. The catch and log and continue is an anti-pattern used by 
inexperienced developers.

Granted, much of exception handling is simplified in the case of GC 
environment, and finalizers for other resources, but the latter can be too 
lazy, and thus try-with-resource which completely handles the inconsistent 
state aspect of Point #2.

Furthermore, the ‘think about every possible code path through your function” 
is pretty much nonsense. A developer does this every time they write a loop, or 
any other control structure. If anything, checked exceptions force the 
developer to think even deeper about handling errors, which a Go should be 
doing too (but can even ignore more easily).

Like I said, I think Go error handling is fine for C size applications, it 
breaks down quickly in large applications that must be resilient, mainly when 
attempting to incorporate library (internal or external code). For small 
applications developers will use if err!= nil panic(err)




> On Jun 30, 2019, at 6:09 PM, Ian Lance Taylor  wrote:
> 
> On Sun, Jun 30, 2019 at 4:16 AM robert engels  wrote:
>> 
>> I am not sure the ‘unexpected flow control’ concern is of the same 
>> importance as when this statement was first written, given paradigms like 
>> ‘reactive programming’ (I don’t like it, but it seems most others are not 
>> bothered by it).
>> 
>> I am curious more though in the belief that exceptions are unexpected flow 
>> control. At least with caught exceptions, this is not the case IMO. You know 
>> the exact point at which the exceptions can occur - this is part of the 
>> beauty of exceptions in that the code is self documenting to a higher degree 
>> and can be subject to automated analysis far more easily 
>> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go 
>> should be handled, but the compiler does not enforce this. I also think that 
>> try-with-resource solves many of the life-cycle concerns very elegantly 
>> (whether you like Java or not, a lot can be learned from the evolution the 
>> language). Still caught exceptions cause problems with functional methods 
>> (and so does error return), although I’m not a big fan of functional either 
>> (for lack of readability).
> 
> The unexpected flow of control when using exceptions is not at the
> point where the exception is thrown, nor at the point where the
> exception is caught.  It is the functions in between that point.  When
> exceptions are used routinely, every single function call is a
> possible change in flow of control.
> 
> That is of course true in Go today because any function may call
> panic, but we we can cope with that in practice because calling is
> panic is discouraged and rare, especially if an unrecovered panic
> crosses a package boundary.  But errors must be routinely returned
> across package boundaries, so if we use exceptions to handle errors
> then we inevitably have unexpected flow of control.
> 
> This is hardly a novel view, of course.  E.g.,
> https://www.joelonsoftware.com/2003/10/13/13/ .
> 
> And since Go programs routinely require transferring an error between
> one goroutine and another, in Go we would have to have to some clean
> and 

[go-nuts] golang gcc c++ existing static library can not be used when making a PIE object; recompile with -fPIC

[czhang41]

I posted this question in SO, and was suggested to post here for more help:


--

I tried to link an existing C++ library to go code. The C++ library only 
has a static library and a header file, no source code.

I used swigc to generate a libfoo.go and I wrote a simple libb.go to build 
this library. This worked well on ubuntu 16.04 with gcc-6 earlier.

However, once I upgraded to ubuntu 18, and even with older go1.9 and gcc-6, 
which used to work, I am hitting the following error:

/usr/bin/ld: ./lib/libfoo.a(parser.o): relocation R_X86_64_32S against symbol 
`xmlSAX2IgnorableWhitespace' can not be used when making a PIE object; 
recompile with -fPIC
/usr/bin/ld: ./lib/libfoo.a(tree.o): relocation R_X86_64_32 against 
`.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC

I have downgraded both go compiler and gcc to the version that used to work.

The following is the libb.go that used to work

/*
#cgo CXXFLAGS: -std=c++11 -D_GLIBCXX_USE_CXX11_ABI=0 -w
#cgo CFLAGS: -I${SRCDIR}/include -w
#cgo LDFLAGS: -Wl -rpath,./lib, -L${SRCDIR}/lib -l:libfoo.a  -l:libxml2.a 
*/import "C"

What should I do get this fixed? I searched and it seems that I have to 
recompile that static library, which is mission impossible in my case. I 
tried to pass the -no-pie parameter to LDFLAGS, that didn't work either.



Thanks!

--


1, first thing first, I don't have the c++ source code, so I can't 
recompile it. 

2, I am using ubuntu 18, initially, I believe I install go via "apt-get 
install", but later I uninstall that version using "apt-get remove" , and 
then downloaded go1.9 pkg from official website and install directly. 

3, go env gives:

GOARCH="amd64"

GOBIN=""

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

GOOS="linux"

GOPATH="/home/coolart/work/go"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"

GCCGO="gccgo"

CC="gcc"

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build628698308=/tmp/go-build 
-gno-record-gcc-switches"

CXX="g++"

CGO_ENABLED="1"

CGO_CFLAGS="-g -O2"

CGO_CPPFLAGS=""

CGO_CXXFLAGS="-g -O2"

CGO_FFLAGS="-g -O2"

CGO_LDFLAGS="-g -O2"

PKG_CONFIG="pkg-config"


4, some system information


go version go1.9.7 linux/amd64


No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 18.04.2 LTS

Release: 18.04

Codename: bionic


Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
5.5.0-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin 
--enable-default-pie --with-system-zlib --enable-objc-gc --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu

Thread model: posix

gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1)


Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
5.5.0-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-5 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin 
--enable-default-pie --with-system-zlib --enable-objc-gc --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu

Thread model: posix

gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1)





-- 
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/9d2d1b5b-ba0c-45a9-a950-482dd661c35c%40googlegroups.com.
For 

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

[Ian Lance Taylor]

On Sun, Jun 30, 2019 at 4:16 AM robert engels  wrote:
>
> I am not sure the ‘unexpected flow control’ concern is of the same importance 
> as when this statement was first written, given paradigms like ‘reactive 
> programming’ (I don’t like it, but it seems most others are not bothered by 
> it).
>
> I am curious more though in the belief that exceptions are unexpected flow 
> control. At least with caught exceptions, this is not the case IMO. You know 
> the exact point at which the exceptions can occur - this is part of the 
> beauty of exceptions in that the code is self documenting to a higher degree 
> and can be subject to automated analysis far more easily 
> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
> be handled, but the compiler does not enforce this. I also think that 
> try-with-resource solves many of the life-cycle concerns very elegantly 
> (whether you like Java or not, a lot can be learned from the evolution the 
> language). Still caught exceptions cause problems with functional methods 
> (and so does error return), although I’m not a big fan of functional either 
> (for lack of readability).

The unexpected flow of control when using exceptions is not at the
point where the exception is thrown, nor at the point where the
exception is caught.  It is the functions in between that point.  When
exceptions are used routinely, every single function call is a
possible change in flow of control.

That is of course true in Go today because any function may call
panic, but we we can cope with that in practice because calling is
panic is discouraged and rare, especially if an unrecovered panic
crosses a package boundary.  But errors must be routinely returned
across package boundaries, so if we use exceptions to handle errors
then we inevitably have unexpected flow of control.

This is hardly a novel view, of course.  E.g.,
https://www.joelonsoftware.com/2003/10/13/13/ .

And since Go programs routinely require transferring an error between
one goroutine and another, in Go we would have to have to some clean
and simple way to transfer an exception between goroutines.

Ian

-- 
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/CAOyqgcVJiXjVbxRCidDrN7hfwiftqs280on2fuwypPphJqpC1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jan Mercl]

On Sun, Jun 30, 2019 at 3:19 PM Jesper Louis Andersen
 wrote:

> This is where the try-construct will definitely improve the ergonomics of the 
> programming.

With full respect to you opinion and/or personal preferences,
"definitely improve" is just and only that. I _definitely_ don't share
that opinion/personal preference.

-- 
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/CAA40n-VLoDYs_PS1BQMCEmS03YfsHoXBE4vb4cmjLjto4k94pg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] is there any type that cannot be sent on a channel?

[Michal Strba]

Not sure where you read that. Anything can be sent on a channel. Even
channels can be sent over channels. That's often used when one goroutine
needs to reply to a message from another goroutine.

ne 30. 6. 2019 o 18:31 Sathish VJ  napísal(a):

> I thought I read somewhere that functions cannot be sent on channels.  But
> I tried it out and it can be.  Play link:
> https://play.golang.org/p/OeLpQsNwnCn
>
> So, is there anything that cannot be sent on channels?
>
> --
> 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/608c41d5-a226-4d77-a8fc-c4563d69f5db%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAO6k0uuhmC6ryBnQp4kb3pG94Ly5o5r0ktVfCseeXK4_kZ91aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A counter proposal to the try proposal - catch

[Robert Engels]

I think both of the proposals are fine, but they suffer from the “lack of 
completeness”. In that, they improve things, but don’t go far enough so the 
incremental benefit is not high enough. A key component of exceptions is the 
concept of ‘throws’ which is both self documenting, and requires handling, 
which enables flow analysis (manual and automated). These proposals don’t 
supply this functionality. They also don’t cover automatic stack capture, which 
is essential in diagnosing problems in large, complex systems. 

> On Jun 30, 2019, at 11:04 AM, Liam  wrote:
> 
> If you really care to "catch" errors, you want this:
> https://github.com/golang/go/issues/27519
> 
> If all you need is to allocate a line to check an error and take an action, 
> you want this:
> https://github.com/golang/go/issues/32611
> 
> But it's all moot. the Go team has told us we must prove that try is 
> inadequate for existing Go projects, and altho that can be proved, it won't 
> be clear for a couple years until use of Error Values propagates.
> 
>> On Thursday, June 27, 2019 at 11:44:23 AM UTC-7, Nate Finch wrote:
>> I really don't like the try proposal, because I think it hurts readabiity of 
>> the code.  But I think the fix is not too hard, so I made a counter 
>> proposal, catch:
>> 
>> https://github.com/golang/go/issues/32811
>> 
>> Catch works just like try, except it has to be a statement and has to be 
>> passed an error explicitly, rather than returning arguments to the left hand 
>> side.  This make the conversion of old code to new code look a lot more like 
>> normal go 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/68e3407a-57cc-42f2-8819-7c0369f5ca4b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/5A743793-FDAB-494F-B297-6486AE30839D%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] is there any type that cannot be sent on a channel?

[Sathish VJ]

I thought I read somewhere that functions cannot be sent on channels.  But 
I tried it out and it can be.  Play link: 
https://play.golang.org/p/OeLpQsNwnCn

So, is there anything that cannot be sent on channels?

-- 
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/608c41d5-a226-4d77-a8fc-c4563d69f5db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Does your Windows app rely on os.Rename() or .Remove() ?

[Liam]

Microsoft has suggested that Go change syscall.Open() to fix this. Please 
pipe up if that might break your app!

Details quoted...

On Tuesday, June 25, 2019 at 8:25:24 AM UTC-7, Liam wrote:
>
> Microsoft recommends changing this, so we need to know whether existing 
> apps rely on it:
>
> On Windows (but not elsewhere) this fails with a "sharing violation":
>
> path := "rename-after-open"
> fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
> if err != nil { ... }
> err = os.Rename(path_a, path_b)// or os.Remove(path)
> if err != nil { ... }  // sharing violation
> fd.Close()
>
>
> Do you know of Windows apps that expect this error, which is undocumented 
> in package "os" ?
>
> Microsoft has suggested that Go on Windows should switch to Unix-like 
> behavior:
> https://github.com/golang/go/issues/32088
>
>

-- 
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/19674267-25a6-484b-93e6-c12d78c8e218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: A counter proposal to the try proposal - catch

[Liam]

If you really care to "catch" errors, you want this:
https://github.com/golang/go/issues/27519

If all you need is to allocate a line to check an error and take an action, 
you want this:
https://github.com/golang/go/issues/32611

But it's all moot. the Go team has told us we must prove that try is 
inadequate for existing Go projects, and altho that can be proved, it won't 
be clear for a couple years until use of Error Values propagates.

On Thursday, June 27, 2019 at 11:44:23 AM UTC-7, Nate Finch wrote:
>
> I really don't like the try proposal 
> , because I think it hurts 
> readabiity of the code.  But I think the fix is not too hard, so I made a 
> counter proposal, catch:
>
> https://github.com/golang/go/issues/32811
>
> Catch works just like try, except it has to be a statement and has to be 
> passed an error explicitly, rather than returning arguments to the left 
> hand side.  This make the conversion of old code to new code look a lot 
> more like normal go 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/68e3407a-57cc-42f2-8819-7c0369f5ca4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Zach Jeyakaran]

If good Go code handles or wraps every error, that code would never use 
'try'. It seems weird to add a language feature that many codebases would 
discourage the use of.

-- 
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/aa7d1566-3299-412a-8b4e-c25f2e418ebd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Liam]

I wrote a proposal with function-scope named handlers that uses a per-call 
try flag and offers most features of 'catch', but it hasn't received any 
attention...
https://github.com/golang/go/issues/27519

On Saturday, June 29, 2019 at 12:45:37 PM UTC-7, Robert Engels wrote:
>
> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
> proposal is barely better than the current  situation. There is as a reason 
> exception handling with try catch was designed along with OO. It simplifies 
> error handling immensely. “Try” as you might, you might think you are 
> improving on it, but you’re not. 
>
> Go should implement caught exceptions and be done with it. Stop trying to 
> be cute. Take what works elsewhere and stop thinking you’re always the 
> smartest person in the room. 
>
>

-- 
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/7e3c1225-cc66-4bd0-b8f7-250ee5bb0e53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Michael Jones]

It seems to me that the try() mechanism could easily be undone by gofmt.
That is, if it does not work out it could be changed with low pain. This is
a virtue. Maybe the lesson is lost on some, but Go 1.0 was incompatible
with primordial Go and the Go team provided GoFix to mutate code. That was
beautiful to me. Any new idea that seems promising but could be undone
automatically if necessary is not risky.

On Sun, Jun 30, 2019 at 6:19 AM Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

> On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson 
> wrote:
>
>>
>> I have a feeling that there is a quite large "silent majority" that
>> pretty much agrees with me.
>>
>>
> Go is a language with the following properties, among other things:
>
> * Massive concurrency through a high amount of gorutines
> * Identity of channels, but not goroutines (goroutines don't have a Pid by
> construction, channels do have identity)
> * Shared memory space among the goroutines
>
> Such a language has a subtle property as an implication: cleanup of a
> failure must happen in the goroutine which made it. That is, error handling
> must be localized. As a result, error handling is mostly a game of treating
> it as data-flow in the program, where errors are values.
>
> There is a common case in such data flow. If an error occurs, we want to
> just return that error. This is where the try-construct will definitely
> improve the ergonomics of the programming. Go is a fairly small language.
> Certainly smaller than e.g., Javascript or Typescript. So I don't think we
> are adding that much cognitive load on people with a specialized
> construction. Of course YMMV... Haskell or OCaml programmers would just
> define a monad and call it a day, heh.
>
>
>
>
> --
> 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/CAGrdgiVU42ep%2BzJFUHc8FiZ_yQWrw2YOTCJEjMbLkyiFeC_C%3DA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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/CALoEmQx3fY2CdaNGn41bOB50ESqxQ551HKTmeYM48o8gNscm9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jesper Louis Andersen]

On Sat, Jun 29, 2019 at 9:30 PM Henrik Johansson 
wrote:

>
> I have a feeling that there is a quite large "silent majority" that pretty
> much agrees with me.
>
>
Go is a language with the following properties, among other things:

* Massive concurrency through a high amount of gorutines
* Identity of channels, but not goroutines (goroutines don't have a Pid by
construction, channels do have identity)
* Shared memory space among the goroutines

Such a language has a subtle property as an implication: cleanup of a
failure must happen in the goroutine which made it. That is, error handling
must be localized. As a result, error handling is mostly a game of treating
it as data-flow in the program, where errors are values.

There is a common case in such data flow. If an error occurs, we want to
just return that error. This is where the try-construct will definitely
improve the ergonomics of the programming. Go is a fairly small language.
Certainly smaller than e.g., Javascript or Typescript. So I don't think we
are adding that much cognitive load on people with a specialized
construction. Of course YMMV... Haskell or OCaml programmers would just
define a monad and call it a day, heh.

-- 
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/CAGrdgiVU42ep%2BzJFUHc8FiZ_yQWrw2YOTCJEjMbLkyiFeC_C%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[pierre . curto]

Indeed.

I think many people like the proposal but are not vocal about it. It is not 
perfect but it *does *bring value to the table if you read the proposal in 
its entirety and think about how you would use/could use it in a real life 
scenario.

I do *decorate *errors a lot, I do care about the *control flow* (I have 
been along time user of *defer *for error handling and find it not magical 
or ugly but fitting beautifully with the language), which are the main 
topics people are complaining about... And I think it actually works fine 
in those situations.

In fact, the try() approach has started growing on me as I write code now, 
I feel it would help in quite a few situations and simplify, not in a 
drastic way, but subtle and valuable one.

My 2c.

Le samedi 29 juin 2019 21:31:19 UTC+2, Henrik Johansson a écrit :

> I for one like the try proposal. It removes much of my gripes with the 
> verbosity of error handling.
>
> I think that it will become more readable than explicit error handling 
> quite fast. Note that it is still explicit, if you don't use the try 
> notation the error can be handled as it is now or ignored as it sometimes 
> is now.
>
> I have a feeling that there is a quite large "silent majority" that pretty 
> much agrees with me.
>
> On Sat, Jun 29, 2019, 21:18 Denis Cheremisov  > wrote:
>
>> And prepare for wider audience in shitty “try” proposal after 1 July.
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/c99b3572-427c-4b7d-91ff-2fb4e4cb9177%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/473c9666-aef5-4d25-a2fe-5832ab76eb8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

And a further example from the same blog post suggests:

ew := {w: fd}
ew.write(p0[a:b])
ew.write(p1[c:d])
ew.write(p2[e:f])
// and so on
if ew.err != nil {
return ew.err
}

This suffers from the same problem - you need to know the internals of 
errWriter to understand the flow, and certainly has unexpected flow, as an 
error in the first write causes the others to be no-ops, or does it? You need 
to both understand the flow of the API, and have the behind the scenes code 
written correctly. 

Imagine an maintainer sees this code and changes it to:

ew := {w: fd}
ew.write(p0[a:b])
log(“this happened”);
ew.write(p1[c:d])
log(“this also happened”);
ew.write(p2[e:f])
log(“so did this”);
// and so on
if ew.err != nil {
return ew.err
}

The log is just an example of a related operation - these are possibly all very 
wrong. You might say, well you need to understand X - but this is a very simple 
example - think about it in the context of a larger more complex procedure.

Very difficult to maintain and audit IMO.

> On Jun 30, 2019, at 6:27 AM, robert engels  wrote:
> 
> Just one other important point, I think the Go documentation makes the case 
> for exceptions. If you read the blog post 
> https://blog.golang.org/errors-are-values you’ll see this suggested code 
> cited as a “better way”:
> 
> scanner := bufio.NewScanner(input)
> for scanner.Scan() {
>token := scanner.Text()
>// process token
> }
> if err := scanner.Err(); err != nil {
>// process the error
> }
> 
> so in this case, not only do you not check errors on the scanner.Scan(), you 
> have to possess deeper knowledge of the API to know that scanner.Err() needs 
> to be called (and checked) post processing.
> 
> Imagine doing code reviews of a large code base where this technique was used 
> extensively - you would need to have every internal and external API 
> memorized.
> 
> Contrast this with scanner.Scan() throwing a caught exception - it either 
> must be caught there or propagated - self documenting for the code reviewer.
> 
> 
> 
> 
>> On Jun 30, 2019, at 6:16 AM, robert engels  wrote:
>> 
>> I am not sure the ‘unexpected flow control’ concern is of the same 
>> importance as when this statement was first written, given paradigms like 
>> ‘reactive programming’ (I don’t like it, but it seems most others are not 
>> bothered by it).
>> 
>> I am curious more though in the belief that exceptions are unexpected flow 
>> control. At least with caught exceptions, this is not the case IMO. You know 
>> the exact point at which the exceptions can occur - this is part of the 
>> beauty of exceptions in that the code is self documenting to a higher degree 
>> and can be subject to automated analysis far more easily 
>> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go 
>> should be handled, but the compiler does not enforce this. I also think that 
>> try-with-resource solves many of the life-cycle concerns very elegantly 
>> (whether you like Java or not, a lot can be learned from the evolution the 
>> language). Still caught exceptions cause problems with functional methods 
>> (and so does error return), although I’m not a big fan of functional either 
>> (for lack of readability).
>> 
>> Personally, and I’ve stated it before, but I’ll go on record again, I 
>> wouldn’t change Go’s error handling at this point. I don’t think the sweet 
>> spot for Go applications requires it, and the difference in mixed code-bases 
>> would make things worse not better (e.g. exception based code calling error 
>> return based code).
>> 
>> But if I were to expand the scope, I would make breaking changes in Go2 (so 
>> no mixing of methodology) for both error handling, and generics, and 
>> probably a few other things, without regards to backwards compatibility. Go 
>> is definitely a better C, but C is a systems language, not a large scale 
>> application language. There’s a possibility that Go could be both a great 
>> systems language and a great applications language, but I’m doubtful as the 
>> concerns are too distinct.
>> 
>>> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
>>> 
>>> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  
>>> wrote:
 
 If you don’t understand the history you are doomed to repeat it. The ‘try’ 
 proposal is barely better than the current  situation. There is as a 
 reason exception handling with try catch was designed along with OO. It 
 simplifies error handling immensely. “Try” as you might, you might think 
 you are improving on it, but you’re not.
 
 Go should implement caught exceptions and be done with it. Stop trying to 
 be cute. Take what works elsewhere and stop thinking you’re always the 
 smartest person in the room.
>>> 
>>> I think that https://golang.org/doc/faq#exceptions is still true.
>>> 
>>> One of the commonly mentioned objections to the "try" proposal is that
>>> the try function causes a change in flow of control without 

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

[robert engels]

Just one other important point, I think the Go documentation makes the case for 
exceptions. If you read the blog post https://blog.golang.org/errors-are-values 
you’ll see this suggested code cited as a “better way”:

scanner := bufio.NewScanner(input)
for scanner.Scan() {
token := scanner.Text()
// process token
}
if err := scanner.Err(); err != nil {
// process the error
}

so in this case, not only do you not check errors on the scanner.Scan(), you 
have to possess deeper knowledge of the API to know that scanner.Err() needs to 
be called (and checked) post processing.

Imagine doing code reviews of a large code base where this technique was used 
extensively - you would need to have every internal and external API memorized.

Contrast this with scanner.Scan() throwing a caught exception - it either must 
be caught there or propagated - self documenting for the code reviewer.




> On Jun 30, 2019, at 6:16 AM, robert engels  wrote:
> 
> I am not sure the ‘unexpected flow control’ concern is of the same importance 
> as when this statement was first written, given paradigms like ‘reactive 
> programming’ (I don’t like it, but it seems most others are not bothered by 
> it).
> 
> I am curious more though in the belief that exceptions are unexpected flow 
> control. At least with caught exceptions, this is not the case IMO. You know 
> the exact point at which the exceptions can occur - this is part of the 
> beauty of exceptions in that the code is self documenting to a higher degree 
> and can be subject to automated analysis far more easily 
> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
> be handled, but the compiler does not enforce this. I also think that 
> try-with-resource solves many of the life-cycle concerns very elegantly 
> (whether you like Java or not, a lot can be learned from the evolution the 
> language). Still caught exceptions cause problems with functional methods 
> (and so does error return), although I’m not a big fan of functional either 
> (for lack of readability).
> 
> Personally, and I’ve stated it before, but I’ll go on record again, I 
> wouldn’t change Go’s error handling at this point. I don’t think the sweet 
> spot for Go applications requires it, and the difference in mixed code-bases 
> would make things worse not better (e.g. exception based code calling error 
> return based code).
> 
> But if I were to expand the scope, I would make breaking changes in Go2 (so 
> no mixing of methodology) for both error handling, and generics, and probably 
> a few other things, without regards to backwards compatibility. Go is 
> definitely a better C, but C is a systems language, not a large scale 
> application language. There’s a possibility that Go could be both a great 
> systems language and a great applications language, but I’m doubtful as the 
> concerns are too distinct.
> 
>> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
>> 
>> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  wrote:
>>> 
>>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>>> proposal is barely better than the current  situation. There is as a reason 
>>> exception handling with try catch was designed along with OO. It simplifies 
>>> error handling immensely. “Try” as you might, you might think you are 
>>> improving on it, but you’re not.
>>> 
>>> Go should implement caught exceptions and be done with it. Stop trying to 
>>> be cute. Take what works elsewhere and stop thinking you’re always the 
>>> smartest person in the room.
>> 
>> I think that https://golang.org/doc/faq#exceptions is still true.
>> 
>> One of the commonly mentioned objections to the "try" proposal is that
>> the try function causes a change in flow of control without clearly
>> signaling that.  In a language where exceptions are thrown to handle
>> errors, unexpected flow of control is routine.  Go does support
>> exceptions in the form of the panic and recover functions, but they
>> are stylistically discouraged, so few people use them for error
>> handling.  Experience has shown that unexpected flow of control from
>> exceptions makes it harder to write correct programs.  That is even
>> more true in a language Go which allocates objects on the stack but
>> does not have destructors.
>> 
>> Ian
> 
> -- 
> 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/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

[robert engels]

I am not sure the ‘unexpected flow control’ concern is of the same importance 
as when this statement was first written, given paradigms like ‘reactive 
programming’ (I don’t like it, but it seems most others are not bothered by it).

I am curious more though in the belief that exceptions are unexpected flow 
control. At least with caught exceptions, this is not the case IMO. You know 
the exact point at which the exceptions can occur - this is part of the beauty 
of exceptions in that the code is self documenting to a higher degree and can 
be subject to automated analysis far more easily 
(https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should 
be handled, but the compiler does not enforce this. I also think that 
try-with-resource solves many of the life-cycle concerns very elegantly 
(whether you like Java or not, a lot can be learned from the evolution the 
language). Still caught exceptions cause problems with functional methods (and 
so does error return), although I’m not a big fan of functional either (for 
lack of readability).

Personally, and I’ve stated it before, but I’ll go on record again, I wouldn’t 
change Go’s error handling at this point. I don’t think the sweet spot for Go 
applications requires it, and the difference in mixed code-bases would make 
things worse not better (e.g. exception based code calling error return based 
code).

But if I were to expand the scope, I would make breaking changes in Go2 (so no 
mixing of methodology) for both error handling, and generics, and probably a 
few other things, without regards to backwards compatibility. Go is definitely 
a better C, but C is a systems language, not a large scale application 
language. There’s a possibility that Go could be both a great systems language 
and a great applications language, but I’m doubtful as the concerns are too 
distinct.

> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor  wrote:
> 
> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels  wrote:
>> 
>> If you don’t understand the history you are doomed to repeat it. The ‘try’ 
>> proposal is barely better than the current  situation. There is as a reason 
>> exception handling with try catch was designed along with OO. It simplifies 
>> error handling immensely. “Try” as you might, you might think you are 
>> improving on it, but you’re not.
>> 
>> Go should implement caught exceptions and be done with it. Stop trying to be 
>> cute. Take what works elsewhere and stop thinking you’re always the smartest 
>> person in the room.
> 
> I think that https://golang.org/doc/faq#exceptions is still true.
> 
> One of the commonly mentioned objections to the "try" proposal is that
> the try function causes a change in flow of control without clearly
> signaling that.  In a language where exceptions are thrown to handle
> errors, unexpected flow of control is routine.  Go does support
> exceptions in the form of the panic and recover functions, but they
> are stylistically discouraged, so few people use them for error
> handling.  Experience has shown that unexpected flow of control from
> exceptions makes it harder to write correct programs.  That is even
> more true in a language Go which allocates objects on the stack but
> does not have destructors.
> 
> Ian

-- 
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/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: A proof-of-concept implementation of my generics proposal for Go

[Michal Strba]

I fixed the importing issues people were having with version of Go newer
than 1.10.

If you haven't tried the generics tool yet and you're interested, now it
should work for you!

It's a tool that takes a Go file which uses generics and translates it into
a regular Go code that you can run. It also does full type-checking of the
generic code.

On Fri, Jun 28, 2019, 05:14 Randall O'Reilly  wrote:

> I also like this proposal, and have a related proposal with a somewhat
> different syntax that is even simpler and is essentially identical to
> existing Go code, just with “Generic Native Types” (GNT).  Here’s a couple
> of side-by-side comparisons:
>
> ///
> // Min
>
> Michal’s:
>
> func Min(x, y type T ord) T {
> if x < y {
> return x
> }
> return y
> }
>
> GNT:
>
> func Min(x, y number) type(x) {
> …
> }
>
> ///
> // SyncMap
>
> Michal’s:
>
> type SyncMap(type K eq, type V) struct {
> mu sync.Mutex
> m  map[K]V
> }
>
> func (sm *SyncMap(type K eq, type V)) Store(key K, value V) {
> sm.mu.Lock()
> sm.m[key] = value
> sm.mu.Unlock()
> }
>
> GNT:
>
> type SyncMap struct interface {
> mu sync.RWMutex
> m  map   // a generic map
> }
>
> func (m *SyncMap) Store(k key(m.Map), v elem(m.Map)) {
> …
> }
>
> A struct interface is like an interface, specialized for struct -- any
> struct with the specified fields gets the generic methods, instantiated for
> the concrete type, e.g.,:
>
> // MySyncMap instantiates the SyncMap struct interface...
> type MySyncMap struct {
> mu sync.RWMutex
> m  map[string]string
> }
>
> Here’s a significantly improved version of the proposal originally posted
> a few weeks ago:
> https://gist.github.com/rcoreilly/bfbee2add03c76ada82810423d81e53d  This
> proposal also specifies a complete set of *fixed* “contracts” that are
> isomorphic to the existing native types, so it might appeal to people who
> prefer more explicit semantics for the generic args, compared to more
> generic generics.  Cheers,
>
> - Randy
>
> > On Jun 27, 2019, at 8:13 PM, Ben Hoyt  wrote:
> >
> > I really, really like this. I liked the original proposal, but using the
> "type" keyword seems very natural. And I like the 80/20 constraints thing
> with eq/ord/num. Good work -- I hope this gets turned into an official
> proposal and debated.
> >
> > -Ben
> >
> >
> > On Thursday, June 27, 2019 at 10:29:03 AM UTC-4, Michal Strba wrote:
> > Hey everybody!
> >
> > A few weeks ago, I posted about my proposal for generics in Go 2. You
> can find it here.
> >
> > Today, I finished a proof-of-concept implementation. It was a lot of fun
> and I learned a lot about the internals of Go.
> >
> > The implementation is a program that takes a Go file that uses generics
> and translates it to a regular Go file that you can run.
> >
> > Try it out here :)
> >
> > I'm looking forwad to all your feedback!
> >
> > Michal Štrba
> >
> > --
> > 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/199bad6c-ed62-44a6-960b-86503242537a%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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/655EEB98-6928-48E9-84C4-24C259660E7D%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAO6k0uv%2BCpg%2BLBVb9SgM8-pF8D_DqqjjJcvMA3LKQmyjGu%2BfbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[robert engels]

ma·jor
/ˈmājər/

adjective
• 1. 
important, serious, or significant.

so I’ll apologize for my transpose, and I’ll ask it in your exact words, please 
name a significant new project in the last 2 years that wasn’t written in Java 
or C++ because it seems by your quote

> Fortunately for the mankind both C++ and Java are dying
> (no significant new projects announced for over 2 yrs afaik).

you are claiming that they are dying, and by corollary, others must not be 
(because if they all are, it is meaningless statement of comparison).

Maybe by citing these new projects that you consider significant we can better 
understand the types of projects you have in mind (in reference to my other 
email regarding focus).

> On Jun 30, 2019, at 3:38 AM, Wojciech S. Czarnecki  wrote:
> 
> On Sat, 29 Jun 2019 18:25:37 -0500
> Robert Engels  wrote:
> 
>> What exactly are you basing your incorrect opinions on? 
>> When you use terms like ‘major’ do you mean important,
>> infrastructure critical, number of users, number of developers?
>> Maybe as a frame of reference you can name a single
>> ‘major’ 
> 
> Strawman. I mentioned neither 'major' nor any other things
> you are relating to. I was precise as to the scope:
> 
>>>  no significant new projects announced for over 2 yrs afaik
> 
> Note the very word **NEW**. 
> 
>> Maybe as a frame of reference you can name a single
>> ‘major’ application that was not developed in these languages
>> that was released in the last 2 years?
> 
> What? I just said I can not name a one. I also said that what is being
> developed (maintained, enhanced) in both languages possibly will
> live for the century. At least until AI will be able to make unattended
> transpilation. 
> 
> 
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
> 
> -- 
> 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/20190630103854.5be358dd%40zuzia.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/0BEB35D3-865E-447E-8B50-37CA87A7D69C%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.

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

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 22:09:10 -0700 (PDT)
Lucio  wrote:

> a lot of people have presumably realised that the consequencesof tackling
> the verbosity of the current iteration of error handling comes with a big 
> price tag.

I personally am in horror I would lose the clear sight of the flow.
Current verbosity saves hundreds of manhours even in moderate size projects.
Go's verbosity makes almost all reads strictly local and speeds up code reviews.

> Go is not just simple, it is mostly "elegant". Go2 must not be allowed to 
> become a second generation design, by democratic dictum.

The "try" problem at hand is deeper and more serious I think.
"Try" is now on the fast track because it is a brainchild of one
of Go founder fathers. 

So it is not 'by democratic dictum' per se. 'Dictum' was just an impulse, IMO.
(I'd say dictum of "the stubborn and vocal minority of fresh convertites". 
I was in this camp myself for some months, too).

Anyway I still have hope that our leading team consist of great people.

And great people, people of merit are able and willing to say
'I was wrong' when faced with real flaws in their design even
if pointed to by a dilettante stranger.

TC,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20190630112433.509d99fd%40zuzia.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: YAEHI (Yet another error-handling idea)

[mh cbon]

f := file.Open() ? error {
//f is nill
return erors.Wrap("nop",err)
}
defer f.Close()

On Saturday, June 29, 2019 at 11:56:09 PM UTC+2, Andrey Tcherepanov wrote:
>
> Hello mighty fighters of errors!
>
> Here comes my half-thought idea of another way to express error handling:
>
> *Add a postfix '?' that checks value for **emptiness (nil, 0, "") **AND 
> an error for nil. *
>
> (Denis have shred it to pieces already in 
> https://github.com/golang/go/issues/32852. Thank you Denis.)
>
> I am not good with expressing my inner talk, so there are couple examples
>
> original , Go 1 function
>
> func stat(filename string) (os.FileInfo, error) {
>
> var info os.FileInfo
> {
> var a1 *os.File
> if a1, err := os.Open(filename); err != nil || a1 == nil {
> return _, err
> }
> var a2 os.FileInfo
> if a2, err := a1.Stat(); err != nil || a2 == nil {
> return _, err
> }
> info = a2
> }
> return info, nil
> }
>
>
> And with "?", trying to avoid original try() proposal handle leak
>
> // would return _, err, but since there is no err in signature, will return 
> default value in case of error
> // uses ? on func call that returns (value, error)
> func stat2(filename string) (os.FileInfo) {
>  file := os.Open(filename)? 
>  defer file.Close()
>  return file.Stat()?
> }
> // would return error too, uses ? as "not nil" on a variable too
> func stat3(filename string) (_ os.FileInfo, err error) {
>  var file *os.File
>  defer file?.Close()
>  file := os.Open(filename)?
>  return file.Stat()
> }
>
>
> Thoughts?
>

-- 
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/15446c5e-bc26-47cc-aa4e-9b5fba398a50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [cgo ] Export go function to C - illegal character

[nicolas_boiteux via golang-nuts]

Hello

Finaly, Isegal helps me to solve this problem. You can have a complete 
description on how to proceed here:
https://github.com/golang/go/issues/32851

Le dimanche 23 juin 2019 13:49:33 UTC+2, nobody nobodye a écrit :
>
> Hello,
>
> I need some assistance to export a GO dll function to a C program.
>
> The C program (wich i m not the author) required to call a function with 
> this name: _RVExtension@12
>
> so, i simply declare my go function like this:
>
> //export _RVExtension@12
> func _RVExtension@12(output *C.char, outputsize C.size_t, input *C.char) {
> Saisissez le code ici...
>
> but when i try to compile it, it returns an illegal character U+0040 '@' 
> error.
>
> Do you know if there is a workaround about this ? I m not familiar with C 
> code and i don't understand why there is @12 in the function name.
>
> note: for the 64 bits the entry point is simple : RVExtension and it 
> works perfectly well.
>

-- 
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/4c600346-6e0b-4c2b-b813-fb2cc7b7e950%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Wojciech S. Czarnecki]

On Sat, 29 Jun 2019 18:25:37 -0500
Robert Engels  wrote:

> What exactly are you basing your incorrect opinions on? 
> When you use terms like ‘major’ do you mean important,
> infrastructure critical, number of users, number of developers?
> Maybe as a frame of reference you can name a single
> ‘major’ 

Strawman. I mentioned neither 'major' nor any other things
you are relating to. I was precise as to the scope:

>>   no significant new projects announced for over 2 yrs afaik

Note the very word **NEW**. 

> Maybe as a frame of reference you can name a single
> ‘major’ application that was not developed in these languages
> that was released in the last 2 years?

What? I just said I can not name a one. I also said that what is being
developed (maintained, enhanced) in both languages possibly will
live for the century. At least until AI will be able to make unattended
transpilation. 


-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20190630103854.5be358dd%40zuzia.
For more options, visit https://groups.google.com/d/optout.