FWIW, I'm in the "I like how it is now better than any other proposal so
far" camp; I think this happens as you get used to the Go way. Go is Go.
The only thing I would consider is making *interface* types (only)
implicitly usable in a boolean context, e.g.
if err { ... }
However, I suppose people would ask "why not pointers? why not channels?"
etc. I'm not suggesting it should become like Python where every non-zero
value is treated as "true". Interface values are special, and there's very
little you can do with a nil interface (whereas for example, a nil pointer
can still have methods called on it). But this does add a special case,
and Go already has its share of surprises you have to learn.
On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote:
> Yes. Go is no longer the simple language it was. I suspect because of
> internal pressures within Google as evidenced by multiple innovations that
> seem to come from nowhere eg dir embedding and associated fs package that
> duplicated perfectly good ways of doing things. The module system while
> useful is quite complex. Generics and all the associated packages inflated
> the mental burden of learning and reading Go code significantly. And having
> the go 1 compatibility guarantee means that old stuff remains valid code
> and must be learned too.
>
> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote:
>
>> Yeah.. I mean, the "idiom" `err != nil return` err is something of the
>> language. I complain about the boilerplate that idiom produces and that is
>> fact fact (no one can deny it).
>>
>> You know, your approach implies making the language a little more
>> complicated as new ways to deal with errors appear. I do understand that
>> some folks provide some push back on the idea simply because there is
>> nothing wrong with the language right now regarding error handling.
>>
>> As I see things, the language was simple in their origins, but from time
>> to time they complicated a little more some things, for example "what about
>> generics?" (are they really necessary?, I mean... I think using interfaces
>> provides all the genericity you may need). So I guess there is room to make
>> some changes and make the language easier. I would say that both ways of
>> handling errors are valid, the most important is to be as simple
>> as possible so you ensure that other people understand it. Like Generics,
>> you don't have to use them. So I would praise it for adding another way,
>> less repetitive.
>>
>> Also like to see how people react and what their opinions are. So far
>> what I read is just personal taste.
>>
>>
>> El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (<
>> golan...@googlegroups.com>) escribió:
>>
>>> And of course I forgot the "if" at the beginning of all those
>>> conditional. *sigh*
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/golang-nuts/dRLR4hxxI8A/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> golang-nuts...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com
>>>
>>> <https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>> --
>> V
>>
>
--
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/11d57ab3-e7d8-4636-8ef7-6de64404bc54n%40googlegroups.com.
