Re: [go-nuts] About the efficency of modifying map elements.

[Matthew Holiday]

Isn't this really just another form of issue 3117
?


On Wed, Mar 17, 2021 at 3:19 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, Mar 17, 2021 at 10:06 PM tapi...@gmail.com 
> wrote:
>
>> For simple scenarios, compiler optimizations might be possible.
>> But for some complicate ones, it is hard for compiler to do optimizations.
>> For example, the element is modified by an function between the map
>> element getter and setter and the behavior of the function is hard to
>> determined at compile time, it might modify or not modify the key.
>>
>
> Yes. I would strongly prefer to have these uncommon cases be slower to
> complicating the language.
>
> FWIW, if anything, the signature would have to take a `func(T) T`, not a
> `func(*T)` - values in a map are not addressable for a reason. If we would
> use a pointer, it would allow the programmer to retain that pointer outside
> of the function, which would not be safe.
>
> But this also implies that any case covered by that function can be
> re-written as
>
> _tmp := k // temporary variable, in case k is modified
> v := m[_tmp]
> // do the same as the function would
> m[_tmp] = v
>
> which should easily recognizable by the compiler. That means we would only
> need to optimize this simple case and anyone concerned about speed could
> rewrite their code into this form to get the same result.
>
> So, I don't actually think doing it as an optimization is harder or less
> powerful than adding this function. It should cover the same cases, without
> complicating the language.
>
>
>
>>
>> On Wednesday, March 17, 2021 at 4:51:09 PM UTC-4
>> axel.wa...@googlemail.com wrote:
>>
>>> Yes, Jan's link also pretty clearly shows that this optimization isn't
>>> currently happening :) Sorry for the noise.
>>> I still believe it should be an optimization in the compiler, not a
>>> language-level feature.
>>>
>>> On Wed, Mar 17, 2021 at 9:44 PM tapi...@gmail.com 
>>> wrote:
>>>

 I found this performance difference by benchmarking the two:

 func IntAdd(words [][]byte) map[string]int {
 var m = make(map[string]int)
 for _, w := range words {
 m[string(w)] = m[string(w)] + 1

 }
 return m
 }

 func IntIncrement(words [][]byte) map[string]int {
 var m = make(map[string]int)
 for _, w := range words {
 m[string(w)]++
 }
 return m
 }

 IntAdd is obviously slower than IntIncrement.

 On Wednesday, March 17, 2021 at 4:22:53 PM UTC-4
 axel.wa...@googlemail.com wrote:

> Hi,
>
> have you verified this using a disassembler or benchmarks? Just asking
> because this is, as far as I'm concerned, a job for the compiler, to
> eliminate the overhead automatically - and I could well imagine that it's
> already doing it. There definitely shouldn't be a new language construct
> for this.
>
> On Wed, Mar 17, 2021 at 9:19 PM tapi...@gmail.com 
> wrote:
>
>> Now, to modify a map element, especially the element type is not a
>> basic type, two hashes are needed to compute. This is often unnecessary 
>> and
>> inefficient. For example:
>>
>> package main
>>
>> type T struct{
>> N int
>> // ... more fields
>> }
>>
>> func main() {
>> var m = map[string]T{}
>> m["foo"] = T{N: 0}
>>
>> // modify
>> t := m["foo"] // first hashing
>> t.N++
>> m["foo"] = t  // second hashing
>> }
>>
>> Will it be good to add a new builtin function, modify(m
>> Map[Key]Value, k Key, func(v *Value)), to modify map elements with only 
>> one
>> hash? A use example:
>>
>> package main
>>
>> type T struct{
>> N int
>> // ... more fields
>> }
>>
>> func main() {
>> var m = map[string]T{}
>> m["foo"] = T{N: 0}
>>
>> // modify
>> modify(m. "foo", func(t *T) {
>> t.N++
>> })
>> }
>>
>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/ba7b2c95-829b-4da4-916a-d53a06ec3428n%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

Re: [go-nuts] Go PostgreSQL? pg versus pgx

[Matthew Holiday]

I don't know of a way without re-writing the library (it's not mine, btw :-)

Most of that appears to be internal stuff except xerrors and crypto; that's
not a bad dependency list compared to some

Maybe pq was one very large package, less stuff broken into subpackages?

On Mon, Feb 22, 2021 at 7:56 AM Paul Förster 
wrote:

> Hi Matthew,
>
> > On 22. Feb, 2021, at 15:28, Matthew Holiday 
> wrote:
> >
> > From the "status" section at the bottom of the README for pq:
> >
> > "This package is effectively in maintenance mode and is not actively
> developed. Small patches and features are only rarely reviewed and merged.
> We recommend using pgx which is actively maintained."
>
> in this case, can I reduce the heavyweight somehow? Why would I need all
> this stuff? I only want to be able to connect and do a few selects, no DML,
> no DDL, just a few select statements. Also, I'm a fan of small footprints.
> :-)
>
> I'm new to Go, so please bear with me if my question seems somewhat
> strange to you.
>
> Cheers,
> Paul
>
>
> $ go get github.com/jackc/pgx/v4
> go: downloading github.com/jackc/pgx/v4 v4.10.1
> go: downloading github.com/jackc/pgx v3.6.2+incompatible
> go: downloading github.com/jackc/pgio v1.0.0
> go: downloading github.com/jackc/pgconn v1.8.0
> go: downloading github.com/jackc/pgproto3 v1.1.0
> go: downloading github.com/jackc/pgtype v1.6.2
> go: downloading golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
> go: downloading github.com/jackc/chunkreader v1.0.0
> go: downloading github.com/jackc/pgpassfile v1.0.0
> go: downloading github.com/jackc/pgservicefile
> v0.0.0-20200714003250-2b9c44734f2b
> go: downloading golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9
> go: downloading github.com/jackc/pgproto3/v2 v2.0.6
> go: downloading golang.org/x/text v0.3.3
> go: downloading github.com/jackc/chunkreader/v2 v2.0.1
>
>

-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.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/CAGSa1CnZm59ziqZf6UbAoja2okYrVQKJ_m6WjB3-sBueZAhoMQ%40mail.gmail.com.

Re: [go-nuts] Go PostgreSQL? pg versus pgx

[Matthew Holiday]

>From the "status" section at the bottom of the README for pq:

"This package is effectively in maintenance mode and is not actively
developed. Small patches and features are only rarely reviewed and merged.
We recommend using pgx which is actively maintained."

On Mon, Feb 22, 2021 at 7:19 AM Paul Förster 
wrote:

> Hi,
>
> is there any important advantage of using github.com/jackc/pgx/v4 instead
> of github.com/lib/pq? I ask because in my view, pgx is bloated beyond
> repair.
>
> Please consider this:
>
> $ go clean --modcache
> $ du -sh ~/go/pkg; find ~/go/pkg -type f | wc -l
> 4.0K~/go/pkg
>1
>
> $ go get github.com/lib/pq
> go: downloading github.com/lib/pq v1.9.0
> $ du -sh ~/go/pkg; find ~/go/pkg -type f | wc -l
> 712K~/go/pkg
>   74
>
> So, only 712K in 74 files, which is good. But:
>
> $ go clean --modcache
> $ du -sh ~/go/pkg; find ~/go/pkg -type f | wc -l
> 4.0K~/go/pkg
>1
> $ go get github.com/jackc/pgx/v4
> go: downloading github.com/jackc/pgx v3.6.2+incompatible
> go: downloading github.com/jackc/pgx/v4 v4.10.1
> go: downloading github.com/jackc/pgio v1.0.0
> go: downloading github.com/jackc/pgconn v1.8.0
> go: downloading github.com/jackc/pgproto3 v1.1.0
> go: downloading github.com/jackc/pgtype v1.6.2
> go: downloading golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
> go: downloading github.com/jackc/chunkreader v1.0.0
> go: downloading github.com/jackc/pgservicefile
> v0.0.0-20200714003250-2b9c44734f2b
> go: downloading github.com/jackc/pgpassfile v1.0.0
> go: downloading golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9
> go: downloading golang.org/x/text v0.3.3
> go: downloading github.com/jackc/pgproto3/v2 v2.0.6
> go: downloading github.com/jackc/chunkreader/v2 v2.0.1
> $ du -sh ~/go/pkg; find ~/go/pkg -type f | wc -l
>  56M~/go/pkg
> 2178
>
> 56M in 2178 files??? I just can't see the advantage of this, even though
> pgx obviously has more features. But that does not justify it being 80
> times as big, does it?
>
> Any thought beyond the usage of some data types which pgx can handle and
> pg can't?
>
> Cheers,
> Paul
>
> --
> 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/F77C0E34-B761-4573-9E21-D4AE838527AC%40gmail.com
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.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/CAGSa1CmNy-zgin24fEDyQvTvNzGTFrLkr6t10b58oxYzBiQyWg%40mail.gmail.com.

Re: [go-nuts] Error handling

[Matthew Holiday]

I'm referring to errors found in the function (i.e., by calling
other functions). It's the responsibility of the callers of a function to
handle the errors it returns, and not the function itself. How can one
function claim responsibility for the error handling strategy of all
programs using it?

Yes, I suppose in some sense exceptions guarantee all errors are handled
somewhere. Unfortunately, what I've seen of exception handling over the
years is that it's often "log the stack trace and keep moving", which isn't
all that useful, and tends to cover up real bugs. A better approach would
be not to catch exceptions at all, and let them crash the program (which is
what Go's panic will do); this ensures the bugs are really handled by
removing them from the program.

[And given this type of exception "handling" it's not much value to the
author of a single function to know that the errors will all be "handled"
somewhere.]

Unfortunately, exception handling languages tend to put all types of
errors, normal and abnormal *, into the same basket. Which means you can't
do sensible error handling for, e.g., JSON that doesn't decode, while
allowing the program to crash when there's a logic bug. (For non-safety
critical software, a crash failure is typically the safest way to fail.
Safety-critical software, on the other hand, avoids exception handling like
the plague.)

* A normal error is some behavior that can reasonably be expected, such as
"file not found" or "no route to host", etc. Abnormal errors are logic bugs
in the program.

An aside:

Assuming you had a cyclomatic complexity calculator that took exceptions
into consideration, such that exceptions passing through a function counted
as a branch, what kind of numbers would you get? Probably pretty awful,
given just about any line of code would be capable of throwing an
exception. But exceptions typically aren't counted, so that functions are
thought to be far less complex than they really are in the presence of
exceptions.

Invisible (magic) return paths through a function go against the notion of
"the code does what it says on the page".

On Sat, Feb 20, 2021 at 1:11 PM Robert Engels  wrote:

> Can you clarify what you mean mean by “the code does exactly what it shows
> on the page”? How do you know by looking at the code, or even compiling the
> code, that all possible errors returned by a function are handled? That to
> me is biggest difficult in reading (or using) others Go code. Exceptions
> (well written) handle this by declaring all possible error (or categories)
> thrown by the method.
>
> This seems a real problem with long term maintenance of Go code.
>
> On Feb 20, 2021, at 1:39 PM, Matthew Holiday 
> wrote:
>
> 
> Roger beat me to it.
>
> But allow me to rephrase,
>
> "The users of Go for a long time have resisted any changes to its simple,
> clear method of error handling despite it being a major concern of folks
> who don't use Go much." *
>
> * I'm referring to the original survey, which was worded along the lines
> of "what keeps you from adopting Go?"
> (implying that the responders are those who haven't adopted Go)
>
> Any type of error handling that creates invisible returns in a function is
> a bad idea IMNSHO (an opinion backed up by various researches into the
> complexity of exception handling). Speaking for myself, I'd like to retain
> that quality of Go whereby "the code does exactly what it says on the page."
>
>
> On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:
>
>>
>>
>> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>>
>>> Rust lang, very early in its evolution, saw the need to create its
>>> operator '?'  to more efficiently manage error handling. But the guardians
>>> of Go lang have resisted any changes to its clumsy method of error handling
>>> despite it being a major concern of Go users for a very long time.
>>
>>
>> Actually the "guardians of Go" (by which I guess you mean the Go team at
>> Google) tried quite hard recently to propose an improved way of handling
>> errors, but it was resisted by "Go users". So what you're saying is just
>> not true, I'm afraid.
>>
>>
>>>
>>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>>
>>>> Dnia 2021-02-13, o godz. 17:44:47
>>>> Michael MacInnis  napisał(a):
>>>>
>>>> > I've been playing around with reducing error handling boilerplate
>>>>
>>>> You're not alone. Hundreds of us went into such thinking in the first
>>>> weeks
>>>> of reading/using Go - yet before we noticed how much more productive we
>>>> are with 

Re: [go-nuts] Error handling

[Matthew Holiday]

Roger beat me to it.

But allow me to rephrase,

"The users of Go for a long time have resisted any changes to its simple,
clear method of error handling despite it being a major concern of folks
who don't use Go much." *

* I'm referring to the original survey, which was worded along the lines of
"what keeps you from adopting Go?"
(implying that the responders are those who haven't adopted Go)

Any type of error handling that creates invisible returns in a function is
a bad idea IMNSHO (an opinion backed up by various researches into the
complexity of exception handling). Speaking for myself, I'd like to retain
that quality of Go whereby "the code does exactly what it says on the page."


On Sat, Feb 20, 2021 at 11:31 AM roger peppe  wrote:

>
>
> On Sat, 20 Feb 2021, 16:31 L Godioleskky,  wrote:
>
>> Rust lang, very early in its evolution, saw the need to create its
>> operator '?'  to more efficiently manage error handling. But the guardians
>> of Go lang have resisted any changes to its clumsy method of error handling
>> despite it being a major concern of Go users for a very long time.
>
>
> Actually the "guardians of Go" (by which I guess you mean the Go team at
> Google) tried quite hard recently to propose an improved way of handling
> errors, but it was resisted by "Go users". So what you're saying is just
> not true, I'm afraid.
>
>
>>
>> On Sunday, February 14, 2021 at 11:14:11 AM UTC-5 ohir wrote:
>>
>>> Dnia 2021-02-13, o godz. 17:44:47
>>> Michael MacInnis  napisał(a):
>>>
>>> > I've been playing around with reducing error handling boilerplate
>>>
>>> You're not alone. Hundreds of us went into such thinking in the first
>>> weeks
>>> of reading/using Go - yet before we noticed how much more productive we
>>> are with Go's "boilerplate" than we were in languages where handling
>>> errors
>>> (failures) was "a problem of others", including future-us as "others".
>>>
>>> Perceived consensus of the Go community is that "error handling
>>> boilerplate"
>>> is a strong feature. I.e. in normal production software you MUST handle
>>> failures
>>> and you should do it as close as possible to the source of said failure.
>>>
>>> Go helps with that. Even team's proposal was finally retracted:
>>> https://github.com/golang/go/issues/32437 Discussion there is lengthy,
>>> but worth
>>> reading to sense why wider community considers "boilerplate" as asset.
>>>
>>> Error handling proposals umbrella:
>>> https://github.com/golang/go/issues/40432
>>>
>>> > Michael.
>>>
>>> Hope this helps,
>>>
>>> --
>>> 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/2b2b2ecc-18e6-4e4c-b71c-581d6ff0fc16n%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/CAJhgacim5uPaik2_QxgafB5uZ589ojWmbFdy54U6etHn4x5z0g%40mail.gmail.com
> 
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.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/CAGSa1C%3DyS48YXZ95ut_LaEiBU2MKCKF5pERgkW5q7%2BHVFv4Stw%40mail.gmail.com.

Re: [go-nuts] Re: Possible Go 2 proposal for built-in Remove method for Slices.

[Matthew Holiday]

See also this graphical cheat sheet:
https://ueokande.github.io/go-slice-tricks/

On Fri, Feb 5, 2021 at 2:09 AM Brian Candler  wrote:

> See: https://github.com/golang/go/wiki/SliceTricks#delete
> (and lots of other neat tricks there).
>
> There's no need to add new syntax or functions when the existing ones do
> the job.
>
> On Thursday, 4 February 2021 at 23:55:36 UTC selahad...@gmail.com wrote:
>
>> Hi,
>> I wonder if there are any proposals for the Remove method for Slices,
>> which removes an element from a Slice.
>>
>> Since the status of the latest generics draft is `likely accepted` and
>> it'd be possible to implement this with `generics`. I believe such an
>> addition to language would alleviate the need to `loop + swap + resize`
>> each time, and enhance the overall readability since there is a consensus.
>>
>> This may seem trivial, but I want to highlight some examples from other
>> langs just to further* concretize*:
>> arraylist.remove(object o) => java
>> list.remove(val) => python
>> array.remove(at: 0) => swift
>>
>> I have looked for the proposals for Go 2 but couldn't find any regarding
>> this issue.
>>
>> There are obviously more things to consider, like whether the operation
>> should keep the order.
>>
>> I'd be very happy with your responses to this pseudo-proposal.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e43d26b0-d259-43e6-aa3b-f52f22f38556n%40googlegroups.com
> 
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.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/CAGSa1CkCLkiAFUfiuwWwT8m18qj9Sn2_Q6HQVn54GKKD7Ydh2g%40mail.gmail.com.

Re: [go-nuts] Code compiles with unused var block

[Matthew Holiday]

You are correct sir, and unfortunately, go vet doesn't find it either.
But if you lint your code with golangci-lint (
https://github.com/golangci/golangci-lint)
the deadcode linter will find it for you.

On Wed, Feb 3, 2021 at 9:35 AM Danny Hart  wrote:

> Hello all,
>
> Very new gopher here (also first time using Groups, please excuse poor
> etiquette).  I was curious why the following basic program compiles with an
> unused var. Is it the case that the compiler only complains about unused
> vars in a function body?
>
> package main
>
> import (
> "fmt"
> )
>
> var (
> x int
> )
>
> func main() {
> fmt.Println("Hello, playground")
> }
>
> --
> 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/d4e80994-8f42-4fe9-888f-26dd973ccbc3n%40googlegroups.com
> 
> .
>


-- 
*Matt Holiday*
Senior Gopher, Marketing Technologies

620 Eighth Avenue

New York, NY 10018

matthew.holi...@nytimes.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/CAGSa1CnQ4D698AEZACqoE_dCCmJEy4V5exSj3Y50oBGWz4mSLA%40mail.gmail.com.