Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Manlio Perillo]

On Wednesday, February 19, 2020 at 7:26:32 PM UTC+1, ohir wrote:
>
> Dnia 2020-02-18, o godz. 10:16:57 
> Manlio Perillo > napisał(a): 
>
> > Here is an example of a diff with a lot of noise, where the actual 
> change 
> > is very hard to see: 
> > https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd 
>
> > Manlio 
>
> I just posted a brief proposal — keep tabs on it, as I neither have a time 
> for, 
> nor I long for next round of defending the obvious again. 
>
> https://github.com/golang/go/issues/37299 
>
> TC, 
>
>
Thanks.  However I have to admit that is a bit complex and the cs-mark is a 
bit obtrusive.


Manlio 

-- 
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/f8b0897e-15a8-4b75-b96b-73b77af85132%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Brian Candler]

I just don't like the implication that these things *haven't* been thought 
about, because nobody could be bothered to polish the "rough edges".

-- 
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/d67826aa-675a-41a3-8376-ff789cad55a2%40googlegroups.com.

Re: [go-nuts] Re: stringer command and generated String() function

[David Finkel]

On Tue, Feb 18, 2020 at 8:57 AM Vincent Blanchon 
wrote:

> Yes, definitely, good point.
> Both are them are good depending on the case actually.
>
>
> Le mardi 18 février 2020 16:55:02 UTC+4, Jan Mercl a écrit :
>>
>> On Tue, Feb 18, 2020 at 1:47 PM Vincent Blanchon
>>  wrote:
>>
>> > However, in real code, I guess we will have that many constants, so it
>> does not make really sense to increase the number.
>>
>> Design decisions may be driven by the desire to maximize the
>> performance in the average case or in the worst case scenario.
>>
>> That's why Go has a regexp package that's slower in the average case
>> wrt PCRE, but it guarantees linear, not exponential, performance of
>> the worst case.
>>
>
 In this case there's a blog post explaining the decision.  Mostly focusing
on memory savings. https://blog.golang.org/generate

There's no question the generated method is ugly. That's OK, though,
> because humans don't need to work on it; machine-generated code is often
> ugly. It's working hard to be efficient. All the names are smashed together
> into a single string, which saves memory (only one string header for all
> the names, even if there are zillions of them). Then an array, _Pill_index,
> maps from value to name by a simple, efficient technique. Note too that
> _Pill_index is an array (not a slice; one more header eliminated) of uint8,
> the smallest integer sufficient to span the space of values. If there were
> more values, or there were negatives ones, the generated type of
> _Pill_index might change to uint16 or int8: whatever works best.


(the blog then discusses decisions for bitfield enums as 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/69db18c0-31a4-4d52-94c6-a168ef815e0a%40googlegroups.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/CANrC0Bh5OdQG_Lg0R8jRybwQ9S9HgNRUfELFZ7%2BtfaGP%2BcCsMw%40mail.gmail.com.

Re: [go-nuts] Re: [Proposal] Change how gofmt formats struct fields

[Wojciech S. Czarnecki]

Dnia 2020-02-18, o godz. 10:16:57
Manlio Perillo  napisał(a):

> Here is an example of a diff with a lot of noise, where the actual change 
> is very hard to see:
> https://gist.github.com/perillo/c5b3bdff9e8db9c89f316670d129c0dd

> Manlio

I just posted a brief proposal — keep tabs on it, as I neither have a time for,
nor I long for next round of defending the obvious again.

https://github.com/golang/go/issues/37299

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/20200219192557.54e8cbba%40xmint.

[go-nuts] [Proposal] cmd/gofmt Minimize adjacent whitespace changes on struct layout edits.

[Wojciech S. Czarnecki]

Proposal: Minimize adjacent whitespace changes on struct layout edits.

With current gofmt rules slight changes to a struct declaration make for
avalanche changes across declaration whitespace due to gofmt trying to layout
struct declaration "pretty". Produced changeset size make diffs unreadable
if any field identifier or type changes its length.

  1. Fix relative indent position of the type of the field, then
  2. Let code author hint gofmt where comments should line up.

Comment-start hint has a form of a "/<" digraph (slash, less-than) put into
the comment that follows the opening brace of the block.

https://github.com/golang/go/issues/37299

-- 
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/20200219191658.33dde792%40xmint.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Michel Levieux]

Though I think I *do* agree with you on that particular point (zero-value
design), I'd say this argument is rarely a real one. Let me explain myself:
However clever Google's thousands of programmers are, there might be places
for improvement and I personally want people to try and propose evolutions
they consider positive for the language and everything gravitating around
it, so we can discuss it together (I mean the community, of course) . That
part seems to be a dead end (at least from the angle we have taken here),
but if every time someone had a thought about a way to improve the
language, the first thing they'd say was "Google's programmers have already
thought about that so there's nothing to be done", Go wouldn't be the
language it is today. There will always be "rough edges", particularly
because the concept of "being a programmer" evolves in itself.

So, yes, and I honestly think you didn't mean we should fall in the other
extreme behaviour, but I just wanted to state that, IMO, that is the last
argument to consider. :)

Le mer. 19 févr. 2020 à 17:32, Brian Candler  a écrit :

> On Wednesday, 19 February 2020 10:59:33 UTC, klos...@gmail.com wrote:
>>
>> I see in a programming language as my most important tool. I use it every
>> single day to make a living. It is because of that importance that I want
>> me (and my team) to be as efficient as possible when working with it, so
>> every detail matters a lot. When you create small short-living
>> applications, it is ok if the language is not perfect.
>>
> ...
>
>> It is because I like so much the way Go approaches programming that I
>> would love to polish those edges that, in my opinion, do make a difference.
>>
>
> You seem to be implying that the Go language designers have not thought
> about these "rough edges".
>
> Perhaps if you read some of the Go history, and the design documents, you
> will find that these issues *have* been considered, in very great detail,
> and there are very good reasons for how things were chosen today.  Not
> because they couldn't be bothered to think of the perfect solution, but
> because in fact the solutions they have come up with have been very
> carefully chosen indeed.
>
> Go came from Google.  Google has thousands of programmers.  It is in
> Google's interest for the language to be as usable, understandable,
> efficient and productive as possible.
>
> --
> 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/6bb009a2-a63e-4a76-a8d6-3d6c1287f78b%40googlegroups.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/CANgi337FYLxawe5Tqmf%3D%3Dy_n0g6JTWXv-2SCvk9x6MaHh68dfQ%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Brian Candler]

On Wednesday, 19 February 2020 10:59:33 UTC, klos...@gmail.com wrote:
>
> I see in a programming language as my most important tool. I use it every 
> single day to make a living. It is because of that importance that I want 
> me (and my team) to be as efficient as possible when working with it, so 
> every detail matters a lot. When you create small short-living 
> applications, it is ok if the language is not perfect.
>
... 

> It is because I like so much the way Go approaches programming that I 
> would love to polish those edges that, in my opinion, do make a difference. 
>

You seem to be implying that the Go language designers have not thought 
about these "rough edges".

Perhaps if you read some of the Go history, and the design documents, you 
will find that these issues *have* been considered, in very great detail, 
and there are very good reasons for how things were chosen today.  Not 
because they couldn't be bothered to think of the perfect solution, but 
because in fact the solutions they have come up with have been very 
carefully chosen indeed.

Go came from Google.  Google has thousands of programmers.  It is in 
Google's interest for the language to be as usable, understandable, 
efficient and productive as possible.

-- 
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/6bb009a2-a63e-4a76-a8d6-3d6c1287f78b%40googlegroups.com.

[go-nuts] array json streaming inside json object

[Jérôme LAFORGE]

Hello,
Do you know an elegant, simple and clean way to stream an json array inside 
json object?

Here an example, that does the job, but I find it complicated (and how we 
manage the comma when document has error and we have to ignore it)

https://play.golang.org/p/lZa8iVaQAKg

thx in adv
BR
Jérôme

-- 
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/026af744-eb21-410e-a22f-6e9f3621d20d%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Volker Dobler]

On Wednesday, 19 February 2020 11:59:33 UTC+1, klos...@gmail.com wrote:
>
> [...]
> But if you create wood houses for people, you don't even think of using a 
> hammer! You will use a much more reliable tool. Or if you use it, it will 
> probably be the best hammer in the market, with a perfect weight balance, 
> with an amazingly ergonomic handle, etc.
>

Sorry, No. You still use conventional hammers.

You do not use bad tools, but nothing fancy either because
there is no such thing as "perfect weight balance" of a
hammer and no "amazingly ergonomic handle[s]" as you
and your coworker will have different hand sizes and
sometimes you will be wearing gloves and sometimes you
will be forced to grip the hammer near to its head because
you operate in confined space.

So basically you use the exactly same hammer to build
a dog house as for a three store wood house.

(There have been advances in hammer technology, e.g.
special kinds of plastic heads which do not stretch metal
and are more durable than wood, but nothing that fancy
like you seem to assume.)

Tooling must be robust. Low and medium grade tooling
is more robust than hightech tooling.

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/43b31021-60a9-4c8f-9d65-666d4c74b3ca%40googlegroups.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[kloster08]

Thanks a lot for your response. All your points make sense and I can 
understand your point of view. I simply have a slightly different point of 
view that my experience has shaped.

I see in a programming language as my most important tool. I use it every 
single day to make a living. It is because of that importance that I want 
me (and my team) to be as efficient as possible when working with it, so 
every detail matters a lot. When you create small short-living 
applications, it is ok if the language is not perfect. But when you create 
applications that must work every single minute and they are so big that 
you need a team of more than 10 people (yes, they are split and the 
application uses microservices/serverless), then you care a lot about the 
nuances of the programming language.

Imagine you need to create a wood dog house for your dog. You are probably 
fine using a simple hammer and nails.
But if you create wood houses for people, you don't even think of using a 
hammer! You will use a much more reliable tool. Or if you use it, it will 
probably be the best hammer in the market, with a perfect weight balance, 
with an amazingly ergonomic handle, etc.

But don't get me wrong. I love Go and the trade-off the Go team has chosen. 
It is very refreshing seeing such a simple and useful language. There are 
others that already have this nil-pointer problem resolved, like Rust, 
Haskell, etc. but they are too complex and, as I mentioned, the thinking 
energy goes to "fighting" with the language, not to the problem you want to 
solve.

It is because I like so much the way Go approaches programming that I would 
love to polish those edges that, in my opinion, do make a difference. 
Maybe there is no good solution to this while keeping the actual balance Go 
has, but I'm willing to try.


El martes, 18 de febrero de 2020, 19:14:07 (UTC), Jake Montgomery escribió:
>
> The problem with that reasoning is that you could use it for anything and 
>> then we would never improve any programming language or create others. 
>> Ideally, the compiler will catch all the bugs it possibly can so that the 
>> programmer can spend the thinking energy on resolving the problem. 
>>
>  
> That is a good point. However, in reality, creating a language is about 
> trade offs. There may be a place for a language that does not allow nil 
> pointers, but it is a trade off that the designers of go decided not to 
> make. 
>  
>
>>  
>>>
>>> I'd say that's not solving the problem, but making it bigger. Do not 
>>> recover from nil panics, instead fix the nil dereference bug and avoid 
>>> the panic completely. 
>>>
>>
>> It is never that easy in a medium to big application with a 10+ people 
>> team working on it. 
>>
>
> I have to agree with Jan here, that is a bad idea. If you have a bug, it 
> has to be fixed, not covered up. It may not always be "that easy", but it 
> is always necessary.  And if you are finding it to be consistently 
> difficult to find and fix nil dereference bugs, then you probably have a 
> problem with your culture or code design that really is not about Go at 
> all. 
>
> I have worked on large go projects with many developers, and frankly nil 
> pointer dereference was not a significant source of bugs. If it is for your 
> team, then maybe you need to look at the bigger picture. There are a number 
> of things you can do, both technically and culturally to reduce this. Some 
> general ideas are below. You may be already be doing some or all of these 
> ...
>
>- On the team level, I would start with the fact that you have 10+ 
>people on a team. If you actually have 10 programmers all working on the 
>same code, then IMHO, you are bound to fail. Break the code up into 
>separate projects with clearly defined boundaries, so you can have smaller 
>teams responsible for their own code. 
>- Null pointer references are often going to be the result of poor 
>detail design. (More about the technical thing you can do later). I have 
>found that thorough code reviews of all commits are invaluable. At least 
>one senior engineer should be on every code review, and preferably every 
>team member will at least look at the commit, and the code review 
> comments. 
>This seems like a big burden, and it is, but it pays off many fold. There 
>will be fewer bugs, better overall design, and better low level design, 
>like function signatures and documentation that help prevent these 
>problems. But most importantly, everyone learns from everyone else, and 
>code consistency and hygiene continually increases. My experience is that 
>bugs like null pointer defer will be reduced or disappear.
>- Of course, the item above relies on each team having one or more 
>talented programmers to lead the way. And there are simply some folks who 
>are incompetent, and will never write reliable code. But even "middle of 
>the road" programmers can write reli