[go-nuts] Re: Iterator handling error

[Christoph Berger]

I like this approach.

   - bufio.Scanner-style errors are a known pattern from the stdlib
   - The approach keeps the key and value params free for their intended use
   - It doesn't require nested iter seqs
   - It is compatible with range loops

Made some sample code as PoC -> https://go.dev/play/p/6qhH6ZN6f0S (Doesn't 
work in the playground due to network restrictions)

On Saturday, August 31, 2024 at 1:38:53 PM UTC+2 gbarr wrote:

> I would likely go with something similar to how you would currently use 
> bufio.Scanner but comine the use of  .Scan()  and .Text() as Range()
>
> ```go
> iter := rows.Iter(ctx)
> for obj := iter.Range {
> // do something with obj
> }
> if err := iter.Err(); err != nil {
> return err
> }
> ```
>
> Or if rows can only have a single active iterator the there is no need for 
> the iter object
>
> ```go
> for obj := rows.Range(ctx) {
> // do something with obj
> }
> if err := rows.Err(); err != nil {
> return err
> }
> ```
>
> Graham.
>
> On Thursday, August 29, 2024 at 1:41:47 PM UTC+1 Dmitriy P wrote:
>
>> What is the best way to handle errors with iterators?
>>
>> How to handle error when we have some object and some type paginates data 
>> (e.g. database/sql.Rows or 
>> https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/s3#ListObjectsV2Paginator
>> )?
>> I found three, but which should be preferable or maybe I've missed some?
>>
>> ```go
>> type Object smth.Smth
>> type Paginator interface {
>> GetNext(ctx) ([]Object, error) // func doing heavy request over internet 
>> HaveNext() bool 
>> }
>> ```
>>
>> ```go
>> func Iter(ctx, data) iter.Seq2[Object, error]
>>
>> for obj, err := Iter(...) {
>> if err != nil {
>> return err
>> }
>> // do smth with Object
>> }
>> ```
>>
>> ```go
>> func IterWithErr(ctx, data, err *error) iter.Seq[Object]
>>
>> var err error
>> for obj := IterWithErr(..., &err) {
>> // do smth with Object
>> }
>> if err != nil {
>> return err
>> }
>> ```
>>
>> ```go
>> func IterOverIter(ctx, data) iter.Seq2[iter.Seq[Object], error]
>>
>> for page, err := IterOverIter(...) {
>> if err != nil {
>> return err
>> }
>> for obj := page(...) {
>> // do smth with Object
>> }
>> }
>> ```
>>
>>
>>

-- 
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/51042ae0-141d-452b-b1f0-94ff17cbe23cn%40googlegroups.com.

[go-nuts] Re: Iterator handling error

[Christoph Berger]

Opinionated answer: If a container type cannot iterate over its elements 
without fail, I would refrain from trying to build a standard iterator for 
this container type. You'd be shoehorning an iterator that can fail into 
the iter API that is not designed for dealing with errors. 

Putting half-witted opinions aside, this thread in /r/golang 

 might 
provide some food for thought. If you want to go with one of your three 
options, I'd favor the first one for its simplicity. It seems to work 
, and I don't see how the other two 
improve over the first one. 

On Thursday, August 29, 2024 at 2:41:47 PM UTC+2 Dmitriy P wrote:

> What is the best way to handle errors with iterators?
>
> How to handle error when we have some object and some type paginates data 
> (e.g. database/sql.Rows or 
> https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/s3#ListObjectsV2Paginator
> )?
> I found three, but which should be preferable or maybe I've missed some?
>
> ```go
> type Object smth.Smth
> type Paginator interface {
> GetNext(ctx) ([]Object, error) // func doing heavy request over internet 
> HaveNext() bool 
> }
> ```
>
> ```go
> func Iter(ctx, data) iter.Seq2[Object, error]
>
> for obj, err := Iter(...) {
> if err != nil {
> return err
> }
> // do smth with Object
> }
> ```
>
> ```go
> func IterWithErr(ctx, data, err *error) iter.Seq[Object]
>
> var err error
> for obj := IterWithErr(..., &err) {
> // do smth with Object
> }
> if err != nil {
> return err
> }
> ```
>
> ```go
> func IterOverIter(ctx, data) iter.Seq2[iter.Seq[Object], error]
>
> for page, err := IterOverIter(...) {
> if err != nil {
> return err
> }
> for obj := page(...) {
> // do smth with Object
> }
> }
> ```
>
>
>

-- 
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/bf855750-c4d7-4e22-8a79-fb2a4369ed6bn%40googlegroups.com.

[go-nuts] Re: Best IDE for GO ?

[Christoph Berger]

*> What I'm looking for is the ability to manage dependencies not only in 
code, but entirely in a project from requirements to deployment.*

I read two different aspects/levels from your question.

The first half sounds like you want a graphical/GUI equivalent of go mod 
for Go dependency management.

The second half sounds like you want extra tooling in an IDE that's not 
seen (yet) in the Go toolchain: 
- on the pre-programming end project planning, (in)formal requirements 
management, C4 maybe, 
- and on the post-programming end a CI/CD integration, maybe direct 
integration of cloud services or software orchestration services like k8s 
or Nomad.

Or maybe it's between these two?

On Saturday, August 19, 2023 at 11:27:34 AM UTC+2 alex-coder wrote:

> Hi All !
> Gophers, there is at least 10 years as GO on a market, Good job !
>
> I found a list of the best IDE and Plugins there:
> https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins
>
> As I remember Java came around 1995 and within 3-4 years several companies 
> developed really great IDEs successful or less to develop commercial 
> project 
> on Java. Here is a list of but I may miss somewhat, sorry, 
> it was relatively a long time ago:
>
> Forte for Java ( Praga, Czech republic)
> VisualCafe (Symantec)
> VisuailAge (IBM)
> JBuilder (Borland)
> Together Control Center (TogetherSoft, Germany)
> Eclipse, and set of commercial IDE on a base on: RSA,RSD,WID and so on 
> (IBM)
>
> appear later:
>
> VS Code ( Microsoft)
> IDEA (JetBrain)
>
> What I'm looking for is the ability to manage dependencies not only in 
> code, 
> but entirely in a project from requirements to deployment.
> The feature should be inbuild into IDE or at least it would be possible 
> to write plugin to implement it.
>
> It is quite possible that I'm missing somewhat here.
> Gophers, may be there is another place where I should look for IDE for GO ?
>
> Thank you.
>

-- 
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/69ce3ede-521d-4bda-a246-95b60380cd54n%40googlegroups.com.

Re: [go-nuts] Go Toolchain Management from 1.21.0 onwards

[Christoph Berger]

I would assume that GOTOOLCHAIN=local does what you want. 

The doc <https://go.dev/doc/toolchain> says,

> When GOTOOLCHAIN is set to local, the go command always runs the bundled Go 
> toolchain.

The author of this proposal 
<https://github.com/docker-library/golang/issues/472> in docker-library/golang 
also assumes that GOTOOLCHAIN=local preserves pre-1.21 behavior. 


> On 16. Aug 2023, at 10:42, Stephen Illingworth 
>  wrote:
> 
> On Wednesday, 16 August 2023 at 08:47:36 UTC+1 Christoph Berger wrote:
> 
> Thank you for replying.
>  
> What prevents you from using the new toolchains mechanism?
> 
> Nothing really. I suppose it's just that I don't really understand what it is 
> or what it's for.
> 
> The current method of dealing with the toolchain is as straightforward as it 
> can possibly be. For me at least. Automatic downloading just seems 
> unnecessarily complicated but I can accept that other people have different 
> needs.
> 
> If GOTOOLCHAIN=local disables the automatic downloading and allows me to 
> continue with my current workflow then I'm happy! The document on the change 
> was extensive but not entirely clear on this point.
> 
> Regards
> Stephen
> 
> 
> 
> 
> -- 
> 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/lu2FbQHWg5A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e2540552-ddfb-4ce4-9db3-a4aa92ca0e95n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/e2540552-ddfb-4ce4-9db3-a4aa92ca0e95n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/416BE6ED-E882-4D34-96B2-4A7C59EC857D%40gmail.com.

[go-nuts] Re: Go Toolchain Management from 1.21.0 onwards

[Christoph Berger]

As far as I understand the Toolchains document, Go projects made with Go 
1.21 or later can demand a particular toolchain for compiling a module 
(through the go and toolchain directives). If you disable downloading 
toolchains as needed, the new behavior of the go and toolchain directives 
might break your workflow.

What prevents you from using the new toolchains mechanism?

On Tuesday, August 15, 2023 at 8:39:43 AM UTC+2 Stephen Illingworth wrote:

> With regards to the new Toolchain Management feature introduced in 1.21.0
>
> Currently, my toolchain management is: download the source; compile; set 
> paths to point to the new version. I like this and it works for me.
>
> Am I correct in thinking that the environment variable, GOTOOLCHAIN=local, 
> will
> disable the automatic downloading of new Go toolchains and allow me to 
> continue
> with my current system? 
>
>
> I hope this isn't seen as a criticism of new developments. It's not meant 
> to be.
> But I don't believe I'm in the target audience for this new feature and 
> want to
> continue with my work as I am currently.
>
> Regards
> Stephen
>

-- 
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/b0bb8115-32df-4b43-a4f5-b7a879509c46n%40googlegroups.com.

Re: [go-nuts] I need confirmation about whether I'm in front of a linter false positive.

[Christoph Berger]

The linter complains because the second err occurs in a different scope. 
"if err = f(); err != nil" scopes this err instance to the if block. It 
re-uses the err from the outer scope, which might not be intended. 

If you only use either of "err = f(); if err..." or "if err = f(); err..." 
consistently, the linter should not complain anymore.

And what I personally prefer if multiple error usages occur in the same 
function is to name the return value: "f() (err error) {...". This 
pre-defines err for the whole function, and you never need to decide 
whether to use "err :=" or "err =". Useful if you move code inside the 
functions around or add new code at the top.

On Tuesday, August 15, 2023 at 11:41:59 PM UTC+2 Amnon wrote:

> I would stop using that particular linter.
>
> And keep calling your error value err. 
> It is idiomatic.
>
> On Monday, 14 August 2023 at 22:36:11 UTC+1 David Finkel wrote:
>
>> On Mon, Aug 14, 2023 at 4:54 PM Pablo Caballero  wrote:
>>
>>> I started working on a Golang project (from my work). The following 
>>> pattern makes the company configured linter to complain with:
>>> sloppyReassign: re-assignment to `err` can be replaced with `err := 
>>> myFunc2()` (gocritic)
>>>
>>> func myFunc() error {
>>> ...
>>> blah, err := getBlah()
>>> if err != nil {
>>> return err
>>> }
>>> ...
>>> if err = myFunc2; err != nil {
>>> return err
>>> }
>>> ...
>>> }
>>>
>>> What bothers me the most is the fact that if I listen to the linter and 
>>> change the code according to its suggestion I get another complaint saying 
>>> that I should use the if short version.
>>>
>>> Yes, I have found silenced sloppyReassign following this pattern.
>>>
>>> What do you think? What linter complaint should I mute? I don't like the 
>>> idea of a code base polluted with instructions to tell the linter to shut 
>>> up. Do you think I should suggest stopping using linters? :)
>>>
>> My recommendation is to stop re-using the "err" variable.
>> I eliminated missed if err != nil checks in my codebases by using unique 
>> names for my error-typed variables. (and reserving the "err" itself for 
>> innermost scopes -- short if statements like the second case you have there)
>>  
>>
>>>
>>> Thank you!
>>>
>>> -- 
>>> 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/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%40mail.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/007d5bfe-245c-46d3-b48c-0ef04a9f7fb8n%40googlegroups.com.

[go-nuts] Re: Any option to substitute plug-in package ?

[Christoph Berger]

WebAssembly comes to mind - see, for example, https://wazero.io/

A plugin would then be a .wasm binary that can be compiled in any language 
that supports WebAssembly as target.

Disclaimer: I have not yet tried this approach.

On Wednesday, August 2, 2023 at 12:14:15 PM UTC+2 alex-coder wrote:

Hi All !
Plug-in package is very interesting, but in case the development under 
windows it does not work,
So, any hint to use some option instead will be highly appreciated.

Thank you.

-- 
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/aa602732-8a37-4ebb-bd48-4efffd34144en%40googlegroups.com.

Re: [go-nuts] Please consider voting to reopen Golang subreddit

[Christoph Berger]

> Personally, I see this as an opportunity to switch to a more
> FOSS-friendly alternative: kbin, lemmy, you name it, as long as it
> rhymes with fediverse.

There is forum.golangbridge.org and maybe more, but the problem is, how to 
take 200k+ Gophers with you?

/r/golang is the largest Go community I know of, and its size makes it as 
vibrant as it is. Relocating this community as a whole is virtually 
impossible. You'd risk ending up with multiple, small, low-traffic 
communities. Join one, and you'll miss out. Join them all, and you'll see 
questions and information duplicated everywhere.

On Tuesday, June 27, 2023 at 9:26:11 AM UTC+2 Sebastien Binet wrote:

> On Tue Jun 27, 2023 at 00:09 CET, Eltjon Metko wrote:
> > > I find this a strange stance, given that most of the people actually 
> > participating in the protest are unpaid volunteers. So I don't see how
> > that
> > can be considered a "commercial dispute", to be honest.
> >
> > The commercial dispute is between Reddit and API Consumers. it has
> > nothing to do with mods or the users. No-mater how certain you may be
> > who is in the right and who is in the wrong, the most certain thing here
> > is that there is great part of the commuinty who are being held hostage
> > and used as tool for commercial disupute that has nothing to do with
> > them or this subredit. To be clear I am not accusing the mods of Golang
> > subredit for being in a powertrip (because initally it did not come from
> > them) but other users who try to force their narrow worldview onto
> > others. If this was an ethics issue, depnding on how clear it is there
> > might be ground for protests, commercial disputes should never be ground
> > for holding even a fraction of the users hostage.
>
> could we please not use this "holding hostage" expression to describe a
> situation that has *nothing* to do (in intensity, dire consequences and
> life threatening aspects) with a *real* hostage situation ?
>
> I am sure in english there are many more fitting idioms to use for a
> situation where people use their right to express their opinions in
> whatever pacific modus operandi they chose to use.
>
> [Personally, I see this as an opportunity to switch to a more
> FOSS-friendly alternative: kbin, lemmy, you name it, as long as it
> rhymes with fediverse.]
>
> thanks,
> -s
>

-- 
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/76c70424-c678-4ed2-a369-a7f3583645a5n%40googlegroups.com.

Re: [go-nuts] Hosting to deploy && run exe ?

[Christoph Berger]

Also worth having a look at:
- fly.io
- encore.dev

Fly.io lets you launch apps in micro VMs.
Encore.dev is a Go-specific deployment & orchestration framework with a 
hosting option.

Both have a free tier.
(Disclaimer: I have no affiliate relationship with any of them.)

On Sunday, June 11, 2023 at 7:47:52 PM UTC+2 Jan Mercl wrote:

> On Sun, Jun 11, 2023 at 7:40 PM alex-coder  wrote:
>
> > Could you please advise me the simple hosting to deploy && run a small 
> exe assembled from go.
>
> I'm using https://www.hetzner.com/cloud?country=us and Google Cloud
> free tier. The later natively supports deployment of Go programs.
>

-- 
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/ab09e940-73b1-49b4-94fb-1c45c56e4d66n%40googlegroups.com.

Re: [go-nuts] Re: Looking Backend Dev Learning Resources

[Christoph Berger]

> that would mean the progress made did not invalidate any of effective Go 
(which seems not possible given the addition of generics)

Adding new features makes Effective Go *incomplete* but not *invalid*. 
There is separate documentation available for Generics and other new 
features. Go documentation can only be invalidated if breaking changes are 
introduced to the language. But the Go 1 compatibility promise 
 prevents this from happening except for very 
rare cases like, for example, security fixes that cannot be implemented 
without breaking existing code. 

On Monday, December 5, 2022 at 9:55:18 PM UTC+1 ren...@ix.netcom.com wrote:

> Can you elaborate on that reference? At first review, it means you are 
> putting in lots of effort making lots of progress (anti red queen) but that 
> would mean the progress made did not invalidate any of effective Go (which 
> seems not possible given the addition of generics). I’m doubting you 
> implied little effort was put in over 10 years so little progress has been 
> made :)
>
> > On Dec 5, 2022, at 2:19 PM, 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
> > 
> > On Mon, 2022-12-05 at 09:27 -0800, Tsvetomir Lazarov wrote:
> >> How relevant is Effective Go actually, given the January 2022 update
> >> that this document has not been updated significantly since 2009?
> > 
> > Still relevant. This is one of the virtues of having a language that is
> > not built on the Red Queen model of progress[1].
> > 
> > [1]https://en.wikipedia.org/wiki/Red_Queen%27s_race
> > 
> > -- 
> > 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/0af2089eb4f34cd5f8e67f1c9b1cad62c1b76e57.camel%40kortschak.io
> .
>

-- 
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/1005a951-495b-4ad4-9303-f8f63109d160n%40googlegroups.com.

[go-nuts] Re: Looking Backend Dev Learning Resources

[Christoph Berger]

If you know the basics of Go already, Effective Go 
 and the Go FAQ are 
good starting points for learning what idiomatic Go is like and why certain 
decisions in the language design were made.

On Saturday, November 26, 2022 at 11:37:29 AM UTC+1 sksin...@gmail.com 
wrote:

> Dear fellow Gophers, 
>
> I have been looking for resources to learn the backend development in Go. 
> I want some good resources which talk about how to write Idiomatic Go Code, 
> the Best Practices to follow, Anti-Patterns to avoid and writing an overall 
> secure server. Any good resources are highly appreciated. 
>
> Thanks and Regards
> SK Singh
>

-- 
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/f2fb07c5-1f69-4523-bbfc-22ba733f5666n%40googlegroups.com.

[go-nuts] Re: Go Get Issues

[Christoph Berger]

You are right, when changing import paths, related info (go.mod contents in 
this case) need to be updated as well. This was missing from my answer, 
thanks for catching that.

Glad to hear that go-getting the private module works after including the 
VCS extension.

On Monday, September 26, 2022 at 8:39:33 PM UTC+2 Rich wrote:

> After I posted this on Friday I saw about adding .git to the end, and that 
> didn't work. Then it started saying:
>
> repository.web.mycompany.com/st_nsres.git 
> but package is
> repository.web.mycompany.com/st_nsres 
> 
>
> Or something like that. What I had to do was delete the go.mod of 
> repository.web.mycompany.com/st_nsres 
> , reinitialize go mod 
> init repository.web.mycompany.com/st_nsres.git. I then pushed that, 
> created a tag:
> git tag "v0.1.1", then git push origin "v0.1.1". 
>
> Then in the application I built that used that package I had to go get "
> repository.web.mycompany.com/st_nsres.git". --THEN it started working.
>
> When I look at the source code to go get  -- MAN the work the Go authors 
> put into that is pretty amazing. Does anybody think it might be possible to 
> write a go git command that might do the same things go get does but ... 
> just for git?  In the days before go mod, I could just go into my goroot: 
> go/src/repository.web.mycompany.com/ then do a git pull 
> repository.web.mycompany.com/st_nsres.git. From there Go would look for 
> it there and you wouldn't need to do a go get on it. I am not sure where it 
> stores it today, if it were possible to somehow cache it manually like that?
>
> Thanks for the help Christoph!!!
>
>
> On Sunday, September 25, 2022 at 7:20:48 AM UTC-4 christoph...@gmail.com 
> wrote:
>
>> Hi Rich,
>>
>> I guess, you run into the behavior described here 
>> :
>>
>>
>> *> To declare the code location, an import path of the form> *
>> repository.vcs/path
>> *> specifies the given repository, with or without the .vcs suffix, using 
>> the named version control system, and then the path inside that repository.*
>> *> (...)*
>> *> If the import path is not a known code hosting site and also lacks a 
>> version control qualifier, the go tool attempts to fetch the import over 
>> https/http and looks for a  tag in the document's HTML . *
>> (emphasis mine)
>>
>> So it seems the go get command does not recognize the import path to be a 
>> Git repository. Otherwise it would have tried SSH, too.
>>
>> I would try changing the import path to 
>> repository.web.mycompany.com/st_nsres.git to give go get a hint that the 
>> import path is a Git repo.
>>
>> On Saturday, September 24, 2022 at 1:14:45 AM UTC+2 Rich wrote:
>>
>>> Sorry the last line was messed up.
>>>
>>> The error I get is:
>>>  github.com/stretchr/testify/require: 
>>> repository.web.mycompany.com/st_nsres@ v0.2.0: unrecognized import 
>>> path "repository.web.mycompany.com/st_nsres":   https fetch: Get "
>>> https://repository.web.mycompany.com/st_nsres?go-get=1":  Unable to 
>>> connect
>>>
>>> It keeps trying to connect via https -- IT's SSH
>>> Again I have ~/.gitconfig configured:
>>>
>>> [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
>>> "]
>>>  insteadOf = https://repository.web.mycompany.com/
>>>
>>> And GOPRIVATE set to repository.web.mycompany.com
>>> On Friday, September 23, 2022 at 4:59:44 PM UTC-4 Rich wrote:
>>>
 I have been having a really hard time with Go Get It just isn't 
 working. We have a private Repositiory, that repository requires us to use 
 SSH. There is no option for using https.

 So, I've configured my git config "~/.gitconfig' 

 ```
 [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
 "]
  insteadOf = https://repository.web.mycompany.com/
 ```
 I have GOPRIVATE set
 ```
 export GOPRIVATE="repository.web.mycompany.com"
 ```
 Then when I use go get:
 ```
 repository.web.mycompany.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/e4b00b73-ee52-4049-91d2-a00c9830381en%40googlegroups.com.

[go-nuts] Re: Go Get Issues

[Christoph Berger]

Hi Rich,

I guess, you run into the behavior described here 
:


*> To declare the code location, an import path of the form> *
repository.vcs/path
*> specifies the given repository, with or without the .vcs suffix, using 
the named version control system, and then the path inside that repository.*
*> (...)*
*> If the import path is not a known code hosting site and also lacks a 
version control qualifier, the go tool attempts to fetch the import over 
https/http and looks for a  tag in the document's HTML . *
(emphasis mine)

So it seems the go get command does not recognize the import path to be a 
Git repository. Otherwise it would have tried SSH, too.

I would try changing the import path to 
repository.web.mycompany.com/st_nsres.git to give go get a hint that the 
import path is a Git repo.

On Saturday, September 24, 2022 at 1:14:45 AM UTC+2 Rich wrote:

> Sorry the last line was messed up.
>
> The error I get is:
>  github.com/stretchr/testify/require: 
> repository.web.mycompany.com/st_nsres@ v0.2.0: unrecognized import 
> path "repository.web.mycompany.com/st_nsres":   https fetch: Get "
> https://repository.web.mycompany.com/st_nsres?go-get=1":  Unable to 
> connect
>
> It keeps trying to connect via https -- IT's SSH
> Again I have ~/.gitconfig configured:
>
> [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
> "]
>  insteadOf = https://repository.web.mycompany.com/
>
> And GOPRIVATE set to repository.web.mycompany.com
> On Friday, September 23, 2022 at 4:59:44 PM UTC-4 Rich wrote:
>
>> I have been having a really hard time with Go Get It just isn't working. 
>> We have a private Repositiory, that repository requires us to use SSH. 
>> There is no option for using https.
>>
>> So, I've configured my git config "~/.gitconfig' 
>>
>> ```
>> [url "ssh://g...@internal.repository.web.mycompany.com:7999/ 
>> "]
>>  insteadOf = https://repository.web.mycompany.com/
>> ```
>> I have GOPRIVATE set
>> ```
>> export GOPRIVATE="repository.web.mycompany.com"
>> ```
>> Then when I use go get:
>> ```
>> repository.web.mycompany.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/daedf690-ce4f-4c10-8d82-878b1072f606n%40googlegroups.com.

[go-nuts] Go Vulnerability Database: integration into Go toolchain?

[Christoph Berger]

Does anybody know if there are plans to integrate vulnerability checks into 
Go tools like go get, go mod download, or go mod tidy? 

Right now, devs need to pull vuln information manually, either through 
running govulnchek or by visiting packages on pkg.go.dev and inspecting the 
package history for vuln tags.

Integration into the toolchain would provide a semi-automated way of 
checking projects for security issues.

(Side note: there is a govulncheck GitHub Action 
 available, but 
what I am looking for is a (semi-)automated mechanism that is independent 
of any software ecosystem.)

-- 
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/1c1be987-6f07-4a24-84b3-09d0f0bff71cn%40googlegroups.com.

[go-nuts] Re: Is Go 1.19 the last 1.x release?

[Christoph Berger]

The talk is from 2017. The version numbers Russ Cox used back then are 
certainly only examples.
As long as all changes and additions to Go are backward-compatible, Go will 
stay at 1.x.

On Saturday, July 16, 2022 at 4:08:26 PM UTC+2 peterGo wrote:

> Natasha,
>
> No.
>  
> Planning Go 1.20
> https://groups.google.com/g/golang-dev/c/Lu5pEF8iwV0/m/62gDPmzaBwAJ
>
> Peter
> On Saturday, July 16, 2022 at 8:19:58 AM UTC-4 natasha.s...@gmail.com 
> wrote:
>
>> As once somewhat hinted by Russ Cox 
>> .
>>
>

-- 
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/6fa3f4a7-92c2-45e6-8b9e-2f6fc44cdf70n%40googlegroups.com.

Re: [go-nuts] Generic interface compiles with incorrectly instantiated types

[Christoph Berger]

> One reason is that then your type can have a method like "Convert() T" 

But then the type parameter is not unused anymore. 

On Tuesday, June 21, 2022 at 8:14:51 PM UTC+2 b...@gmail.com wrote:

> One reason is that then your type can have a method like "Convert() T" 
> where the actual type is not relevant (i.e. you do not need to actually 
> have a generic type associated with it) but you can have a function that 
> returns a specific type anyway. As methods can not have extra type 
> parameters, this would be the only way to do something like that.
>
>
> On Tue, Jun 21, 2022 at 10:38 AM Christoph Berger  
> wrote:
>
>> > The Wrap interface ignores its type parameter
>>
>> Curious, why doesn't the compiler consider this an error? I would expect 
>> a "type parameter declared but not used" error, similar to the "variable 
>> declared but not used" error. 
>> Or are there valid use cases for types that declare a type parameter but 
>> do not use it?
>>
>>
>> On Tuesday, June 21, 2022 at 12:49:10 AM UTC+2 Ian Lance Taylor wrote:
>>
>>> On Mon, Jun 20, 2022 at 3:27 PM Tsvi Benschar  
>>> wrote: 
>>> > 
>>> > Hey everyone, reposting a question I asked on the go forum since it 
>>> isn't getting replies there. I have some code that’s compiling and running 
>>> despite there being a type error. I don’t understand go generics and 
>>> interfaces that well, so I don’t know if this behavior is intended. 
>>> > 
>>> > Here's a simple incorrect program that compiles. (Here's the correct 
>>> version.) On line 23 of the incorrect version, the function's generic 
>>> parameter is instantiated to string, but its input is of type int. It 
>>> compiles anyways and panics at runtime, even though the type switch's 
>>> default case should never be reached. 
>>> > 
>>> > I got some similar examples to compile and run, they all involve 
>>> instantiating a generic interface with one type but using it as if it had a 
>>> different type. Is this behavior intended, or maybe is there some implicit 
>>> unsafe cast happening? Or is this a bug? 
>>>
>>> Thanks for providing a complete test case. 
>>>
>>> The Wrap interface ignores its type parameter, so any type that 
>>> implements a isWrap method with no arguments and no results will 
>>> implement Wrap with any type argument. The argument to Extract is 
>>> Wrap[A], so you can pass anything with an isWrap method to Extract. 
>>> The type Val[int] does have an isWrap method, so it's fine to pass 
>>> that type to Extract[int]. 
>>>
>>> I don't understand what your code is trying to do, but the behavior 
>>> seems entirely correct to me. 
>>>
>>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/aa1f0a02-7fa3-414b-8be0-456e951cb439n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/aa1f0a02-7fa3-414b-8be0-456e951cb439n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/980e448a-564e-4950-ad40-19f5d3a80437n%40googlegroups.com.

Re: [go-nuts] Generic interface compiles with incorrectly instantiated types

[Christoph Berger]

> The Wrap interface ignores its type parameter

Curious, why doesn't the compiler consider this an error? I would expect a 
"type parameter declared but not used" error, similar to the "variable 
declared but not used" error. 
Or are there valid use cases for types that declare a type parameter but do 
not use it?


On Tuesday, June 21, 2022 at 12:49:10 AM UTC+2 Ian Lance Taylor wrote:

> On Mon, Jun 20, 2022 at 3:27 PM Tsvi Benschar  
> wrote: 
> > 
> > Hey everyone, reposting a question I asked on the go forum since it 
> isn't getting replies there. I have some code that’s compiling and running 
> despite there being a type error. I don’t understand go generics and 
> interfaces that well, so I don’t know if this behavior is intended. 
> > 
> > Here's a simple incorrect program that compiles. (Here's the correct 
> version.) On line 23 of the incorrect version, the function's generic 
> parameter is instantiated to string, but its input is of type int. It 
> compiles anyways and panics at runtime, even though the type switch's 
> default case should never be reached. 
> > 
> > I got some similar examples to compile and run, they all involve 
> instantiating a generic interface with one type but using it as if it had a 
> different type. Is this behavior intended, or maybe is there some implicit 
> unsafe cast happening? Or is this a bug? 
>
> Thanks for providing a complete test case. 
>
> The Wrap interface ignores its type parameter, so any type that 
> implements a isWrap method with no arguments and no results will 
> implement Wrap with any type argument. The argument to Extract is 
> Wrap[A], so you can pass anything with an isWrap method to Extract. 
> The type Val[int] does have an isWrap method, so it's fine to pass 
> that type to Extract[int]. 
>
> I don't understand what your code is trying to do, but the behavior 
> seems entirely correct to me. 
>
> 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/aa1f0a02-7fa3-414b-8be0-456e951cb439n%40googlegroups.com.

[go-nuts] Re: go log.Println(http.ListenAndServe(...)) blocks

[Christoph Berger]

(And I really should hit "reply to all", lol)

> https://go.dev/ref/spec#Go_statements :
>
> > The function value and parameters are evaluated as usual 
 *in the calling goroutine*, but unlike with 
a regular call, program execution does not wait for the invoked function to 
complete.
*(emphasis mine)*

This explains it. I really should read the spec a bit more often. :)

Thanks Sean & Robert!

On Friday, February 18, 2022 at 5:50:04 PM UTC+1 seank...@gmail.com wrote:

> https://go.dev/ref/spec#Go_statements :
>
> > The function value and parameters are evaluated as usual 
>  in the calling goroutine, but unlike with 
> a regular call, program execution does not wait for the invoked function to 
> complete.
>
> http.ListenAndServe is being evaluated, but it blocks.
> Only the log.Println call would run in the newly started goroutine.
>
> On Friday, February 18, 2022 at 5:35:52 PM UTC+1 christoph...@gmail.com 
> wrote:
>
>> Hi gophers, 
>>
>> I hope someone can help finding out why a particular goroutine call can 
>> block the main goroutine.
>>
>> In the following code, all "go" calls spawn off a goroutine and return as 
>> expected, except for the last one that blocks the main goroutine. 
>>
>> Is this a bug, or am I missing something subtle or even obvious (obvious 
>> to all others only of course)?
>>
>> package main
>>
>> import (
>> "log"
>> "net/http"
>> )
>>
>> func main() {
>> // all of these work as expected
>> go http.ListenAndServe("localhost:8080", nil)
>> go log.Println("goroutine")
>> go func() {
>> log.Println(http.ListenAndServe("localhost:8081", nil))
>> }()
>>
>> // The following line blocks the main goroutine.
>> go log.Println(http.ListenAndServe("localhost:8082", nil))
>>
>> log.Println("after go log.Println(http.ListenAndServe())") // 
>> never prints
>> select {} // remove this, and the code still never finishes
>> }
>>
>> All three servers eventually run (try curl localhost:8080; curl 
>> localhost:8081; curl localhost:8082),
>>
>> In the playground , the code even 
>> deadlocks. 
>>
>> Any idea?
>>
>>

-- 
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/c22c5a37-5df5-45ae-810c-7616f2ff34a2n%40googlegroups.com.

[go-nuts] go log.Println(http.ListenAndServe(...)) blocks

[Christoph Berger]

Hi gophers, 

I hope someone can help finding out why a particular goroutine call can 
block the main goroutine.

In the following code, all "go" calls spawn off a goroutine and return as 
expected, except for the last one that blocks the main goroutine. 

Is this a bug, or am I missing something subtle or even obvious (obvious to 
all others only of course)?

package main

import (
"log"
"net/http"
)

func main() {
// all of these work as expected
go http.ListenAndServe("localhost:8080", nil)
go log.Println("goroutine")
go func() {
log.Println(http.ListenAndServe("localhost:8081", nil))
}()

// The following line blocks the main goroutine.
go log.Println(http.ListenAndServe("localhost:8082", nil))

log.Println("after go log.Println(http.ListenAndServe())") // never 
prints
select {} // remove this, and the code still never finishes
}

All three servers eventually run (try curl localhost:8080; curl 
localhost:8081; curl localhost:8082),

In the playground , the code even 
deadlocks. 

Any idea?

-- 
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/fd72b5b3-f01e-44d5-a1a0-f784fe7b884fn%40googlegroups.com.

[go-nuts] Re: scripting in Go

[Christoph Berger]

Thanks for adding a long-name variant! Indeed I feel the code is much more 
self-documenting this way. But in the end it is only a matter of getting 
used to an API. Power users of "sc" will certainly be able to read the 
original short-name variant without problems.

On Thursday, January 27, 2022 at 12:25:56 AM UTC+1 eko...@gmail.com wrote:

> I made a second variant in a separate repo/module: 
> https://pkg.go.dev/github.com/egonk/scr
>
> The function names are more descriptive, Printf wrappers were removed and 
> it is not meant to be used as a dot import anymore.
>
> On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote:
>
>> sc is a convenience package to support writing short automation scripts 
>> that simply panic on errors. It is similar to shell scripting with "set -e" 
>> option.
>>
>> https://pkg.go.dev/github.com/egonk/sc
>>
>> I wrote the package to stop copy pasting trivial helpers in throwaway and 
>> build automation scripts. Obviously panics instead of errors are not 
>> recommended for Go code, but I saw no big benefits by writing elaborate 
>> error messages in such scripts.
>>
>> M (generic Must) does not show on pkg.go.dev, probably because generics 
>> are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently 
>> not detected by go vet as printf funcs, is there a way to mark them in the 
>> package as printf?
>>
>

-- 
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/8b95e02b-72ee-4cb7-9708-a249fecccb2fn%40googlegroups.com.

[go-nuts] Re: scripting in Go

[Christoph Berger]

Thanks for sharing your package.

To me it seems that the functions are rather shallow wrappers around other 
single functions from the standard library (e.g., sc.P() maps 1:1 to 
fmt.Printf()). You certainly save a couple of keystrokes while *writing* a 
script this way, but on the other hand, *reading* the resulting code adds 
cognitive overhead, as you need to go one extra step from recognizing 
stdlib functions (fmt.Printf) to recognizing custom lib functions and their 
mapping to the underlying stdlib functions ("ok, there is a sc.P() in this 
script, this maps to fmt.Prinft()..."). 

This is super ok if you write throwaway scripts for your own purpose, but 
once you pass the scripts around, the receivers would have to learn a new 
pacakge API and read through an extra API layer to see what the script is 
doing. Remember that code is much more often read than written.

If the main purpose is to eliminate explicit error handling (which is 
*perfectly 
fine for simple scripts* IMHO), then I would at least prefer longer names, 
like sc.Printf(), which would make the purpose of this function obvious.

Just my $0.02. Otherwise, I generally like the idea of providing a 
simplified API for supporting quick&dirty throwaway scripting in Go. 
Remember what Kelsey Hightower said: "Bash is the reason people leave IT"! 
:-)
On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote:

> sc is a convenience package to support writing short automation scripts 
> that simply panic on errors. It is similar to shell scripting with "set -e" 
> option.
>
> https://pkg.go.dev/github.com/egonk/sc
>
> I wrote the package to stop copy pasting trivial helpers in throwaway and 
> build automation scripts. Obviously panics instead of errors are not 
> recommended for Go code, but I saw no big benefits by writing elaborate 
> error messages in such scripts.
>
> M (generic Must) does not show on pkg.go.dev, probably because generics 
> are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently 
> not detected by go vet as printf funcs, is there a way to mark them in the 
> package as printf?
>

-- 
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/b14e720a-0dbc-4075-8887-7c190bebdb6cn%40googlegroups.com.

[go-nuts] Re: [ANN] Scriggo - Go template engine and embeddable interpreter

[Christoph Berger]

Hi Marco,

That's super interesting, especially the Go interpreter part. 

Curious – how close is the interpreter to the latest Go version? 
And how fast are new Go versions adopted?

Thanks,
Christoph

On Wednesday, September 15, 2021 at 3:15:43 PM UTC+2 Marco Gazerro wrote:

> Announcing Scriggo, an open source Golang template engine that uses Go as 
> its scripting language. Scriggo also includes an embeddable interprter for 
> the Go language.
>
> https://github.com/open2b/scriggo
>
>

-- 
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/b6e5f0e9-cf6c-40c1-9a87-1b4a4fd9dbban%40googlegroups.com.

[go-nuts] Re: my package not include in go modules

[Christoph Berger]

A module can consist of multiple packages. The packages in your repository 
all belong to the module in the root directory of the repo (where your 
go.,mod file is). And there is nothing wrong with this. You can maintain 
them all together in the same module. 

However, perhaps you want to make one or more packages available for other 
projects. Then it makes sense to move them into their own module.

To use separate modules for your packages, you can do either of these two 
approaches:

Option 1 (preferred). Move your non-main packages into separate 
repositories. Run go mod init  at the root of each repo to 
create a module for each package. (Here we have one repo = one package = 
one module.)

Option 2. Keep all packages in your single repo. For each non-main package, 
cd into the package dir and run go mod init . Caveat: This 
way you get nested modules, which is probably not something you really 
want. See the multi-module repositories FAQ 
 
in the Go Wiki.for some reasons against multi-module repos. Plus a cite 
from Russ Cox: "For all but power users, you probably want to adopt the 
usual convention that one repo = one module."

– Christoph
On Saturday, July 25, 2020 at 7:03:44 AM UTC+2 alideve...@gmail.com wrote:

> I want to import libraries in module file but modules add all other 
> libraries except those packages which I had created, DB is one of them. How 
> to import? 
> Error , please help 
> me to resolve 
>
>

-- 
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/a3cdf112-cb4d-4d45-ade8-0b699f4dbe8dn%40googlegroups.com.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Christoph Berger]

> For clarity, it might make sense to amend the definition-looking section of 
> the spec with a blurb in the spirit of "defined types are those arising from 
> a type definition, or the predeclared types yadayadayada" (where yadayadayada 
> could be a list, could be the empty string if we resolve the error ambiguity 
> or could be "except error"). That way, if someone uses a "defined type" link 
> to see what it means (as Christoph did here for assignability) they'll get an 
> immediate answer about the implications.

This.

I agree it is all somewhere in the spec if I search long enough, but having the 
important parts in one place would definitely be an enormous time saver.


Thanks Axel for your input.
On 8. May 2020, 17:42 +0200, Axel Wagner , wrote:
> https://golang.org/ref/spec#Type_definitions
> > A type definition creates a new, distinct type with the same underlying 
> > type and operations as the given type, and binds an identifier to it. […] 
> > The new type is called a defined type. It is different from any other type, 
> > including the type it is created from.
>
> This seems to imply, when taking as the sole definition of the word "defined 
> type", that predeclared identifiers are in fact *not* defined types, as they 
> don't originate from a type definition. I agree with Christoph here - if you 
> follow any "defined type" link to this definition, which is formatted as a 
> definition (italics are a classical typographical hint to denote a term being 
> defined), that definition prevents any of the predeclared types from being 
> considered "defined types".
>
> However:
>
> https://golang.org/ref/spec#Boolean_types
> > […] The predeclared boolean type is bool; it is a defined type.
> https://golang.org/ref/spec#Numeric_types
> > […] To avoid portability issues all numeric types are defined types […]
> https://golang.org/ref/spec#String_types
> > […] The predeclared string type is string; it is a defined type. […]
> https://golang.org/ref/spec#Errors
> …h. I assume it doesn't make a difference here, as it's an interface 
> type, so other parts of the spec apply wherever it's important. I'll play 
> around for a bit :)
>
> So, while the actual definition *is* ambiguous, the spec as a whole is not - 
> it very clearly states that the predeclared types are defined types.
> Note, that the section "predeclared identifiers" itself is not important here 
> - being declared and being defined are different words and `errors` is 
> predeclared, but, apparently, not defined. Language lawyering this way is 
> annoying, but it's also what writing a spec is all about. "defined" and 
> "declared" are similar, but distinct terms.
>
> For clarity, it might make sense to amend the definition-looking section of 
> the spec with a blurb in the spirit of "defined types are those arising from 
> a type definition, or the predeclared types yadayadayada" (where yadayadayada 
> could be a list, could be the empty string if we resolve the error ambiguity 
> or could be "except error"). That way, if someone uses a "defined type" link 
> to see what it means (as Christoph did here for assignability) they'll get an 
> immediate answer about the implications.
>
> > On Fri, May 8, 2020 at 4:43 PM Jan Mercl <0xj...@gmail.com> wrote:
> > > On Fri, May 8, 2020 at 4:31 PM Christoph Berger
> > >  wrote:
> > >
> > > > Unfortunately, the connection between "predeclared" (or "implicitly 
> > > > declared" as the first paragraph says) and "defined" is not at all 
> > > > obvious. Especially as the definition of "defined type" refers to types 
> > > > explicitly declared via the "type" keyword.
> > >
> > > The definition of "defined type" is correct and simple, no special
> > > rules exists. The predeclared identifier `int` is declared that way,
> > > except it's done by the compiler without the need to do it in user
> > > code. See here: https://godoc.org/builtin#int
> > >
> > > Of course, the builtin package is only a formal definiton, it has
> > > special treatment by the compiler, so doing the same in user code
> > > would be invalid. Still `int` is defined and treated as `type int
> > > something` and it's thus a defined(named) type.
> > >
> > > In the first approximation, any type represented by a name is a
> > > defined type. Later came type aliases, so now it's a bit more
> > > complicated b/c one can

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Christoph Berger]

All agreed, Jan. I have not meant to indicate that the definition of "defined 
type" is incorrect or complicated. The problem lies in the fact that a type 
like int, that is commonly recognized as a built-in type, happens to be a 
"defined type". This, plus the fact that a pointer to int is not a defined 
type, and thus two seemingly similar assignments obey to different rules.

I started this thread as I need to explain to someone if they can assign 
cmdline flags to defined types. With the flag functions that return pointers it 
is possible, with the *Var variations (IntVar, StringVar) it is not. This is 
quite difficult to explain without having to admit that the type system is not 
that straightforward as it might seem for a language like Go.

I know, a static type system is never easy, and AFAIR, even Eiffel's type 
system is not entirely consistent, but still...
On 8. May 2020, 16:42 +0200, Jan Mercl <0xj...@gmail.com>, wrote:
> On Fri, May 8, 2020 at 4:31 PM Christoph Berger
>  wrote:
>
> > Unfortunately, the connection between "predeclared" (or "implicitly 
> > declared" as the first paragraph says) and "defined" is not at all obvious. 
> > Especially as the definition of "defined type" refers to types explicitly 
> > declared via the "type" keyword.
>
> The definition of "defined type" is correct and simple, no special
> rules exists. The predeclared identifier `int` is declared that way,
> except it's done by the compiler without the need to do it in user
> code. See here: https://godoc.org/builtin#int
>
> Of course, the builtin package is only a formal definiton, it has
> special treatment by the compiler, so doing the same in user code
> would be invalid. Still `int` is defined and treated as `type int
> something` and it's thus a defined(named) type.
>
> In the first approximation, any type represented by a name is a
> defined type. Later came type aliases, so now it's a bit more
> complicated b/c one can write also `type T = []U` where T is not a
> defined type b/c []U is not a defined type.

-- 
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/69eb2892-3e17-439a-a1ce-97c5baaf6dec%40Spark.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Christoph Berger]

Thank you Jan, this helped me a lot.

Unfortunately, the connection between "predeclared" (or "implicitly declared" 
as the first paragraph says) and "defined" is not at all obvious. Especially as 
the definition of "defined type" refers to types explicitly declared via the 
"type" keyword.

I conclude that the difference between assigning int to number (which fails) 
and *int to intp (which works) in the original example is subtle, well hidden 
in the spec, and probably quite difficult to explain to newcomers. (Especially 
the logic behind it.)
On 8. May 2020, 16:01 +0200, Jan Mercl <0xj...@gmail.com>, wrote:
> On Fri, May 8, 2020 at 3:29 PM Christoph Berger
>  wrote:
>
> > So I conclude that the assignment of *int to intp succeeds because *int is 
> > not a defined type and both *int and intp have the same underlying type 
> > *int.
> >
> > Looking through the ref spec I found a couple of places that mention some 
> > defined types (esp., all numeric types and string). Is there an exhaustive 
> > list available of all predefined types that technically count as defined 
> > types?
>
> Predeclared types are listed here:
> https://golang.org/ref/spec#Predeclared_identifiers in the section
> "Types:"
>
> Note that they do not "technically count". If 'name' is binded to a
> type in a declaration then type 'name' is a defined type. The rule is
> universal. The difference is that eg. `*int` is not a name
> (identifier), so it's a type literal defining a pointer to a
> named/defined type.

-- 
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/74fa0bfa-9611-48b3-a173-0ebdbacd1315%40Spark.

Re: [go-nuts] Should an assignment from int to a type based on int succeed?

[Christoph Berger]

Thanks for the quick reply Jan.

So I conclude that the assignment of *int to intp succeeds because *int is not 
a defined type and both *int and intp have the same underlying type *int.

Looking through the ref spec I found a couple of places that mention some 
defined types (esp., all numeric types and string). Is there an exhaustive list 
available of all predefined types that technically count as defined types?
On 8. May 2020, 14:57 +0200, Jan Mercl <0xj...@gmail.com>, wrote:
> On Fri, May 8, 2020 at 2:46 PM  wrote:
>
> > Or do I just fail to see the obvious...
>
> 'int' _is_ a defined type. It's predeclared in the universe scope.

-- 
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/5397d0bf-e015-43b5-8ea1-6af7478f6e65%40Spark.

[go-nuts] Re: Go policy does not fully support previous release

[Christoph Berger]

A question based on genuine interest: Which factors make it hard for you to 
upgrade to the latest Go release?


On Monday, September 30, 2019 at 9:49:39 PM UTC+2, Liam wrote:
>
> I was startled to learn that regressions found in the previous release 
> (currently 1.12.x) will not be fixed in that release. Regressions are only 
> fixed in the most recent release.
>
> If you wait until 1.12.5 to upgrade a deployment from 1.11.x, and then 
> discover a regression on the day 1.13 comes out, tough luck. Either upgrade 
> again to 1.13 or resort to a custom build.
>
> I filed a proposal to change this:
> https://github.com/golang/go/issues/34622
>
>

-- 
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/9964ea39-6978-4fb0-83bb-bd7cbd509ee7%40googlegroups.com.

Re: [go-nuts] Re: concurrency programing about go

[Christoph Berger]

Always call Add() before spawning the corresponding goroutine(s). And 
always call Add() in the same goroutine that also calls Wait(). This way 
you have no race condition between Add(), Done(), and Wait().


On Saturday, November 4, 2017 at 10:46:21 AM UTC+1, Henrik Johansson wrote:
>
> I find continuously adding and calling done on a waitgroup a bit odd. The 
> waiting goroutine can continue as soon as the count is zero so there is  a 
> race between adds and dones. 
>
> On Sat, 4 Nov 2017, 10:01 , <28911...@gmail.com > wrote:
>
>> Thank you very much.Sorry I still have some question:what's the function 
>> of wg? what does the sentense "wg.Add(2) " mean?? I found that if I change 
>> 2 into 1,the result is differnet.
>>
>> 在 2017年11月3日星期五 UTC+8上午4:45:47，snmed写道：
>>
>>> Hi 
>>>
>>> Here is the code:
>>>
>>> Version 1:
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "sync"
>>> )
>>>
>>> var a string
>>> var once sync.Once
>>>
>>> func setup() {
>>> a = "hello,world\n"
>>> }
>>> func doprint() {
>>> once.Do(setup)
>>> fmt.Print(a)
>>> }
>>> func twoprint() <-chan struct{} {
>>> var wg sync.WaitGroup
>>> wg.Add(2)
>>> ch := make(chan struct{})
>>>
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>>
>>> go func() {
>>> wg.Wait()
>>> close(ch)
>>> }()
>>>
>>> return ch
>>> }
>>>
>>> func main() {
>>> ch := twoprint()
>>> <-ch
>>> }
>>>
>>>
>>> Version 2:
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "sync"
>>> )
>>>
>>> var a string
>>> var once sync.Once
>>>
>>> func setup() {
>>> a = "hello,world\n"
>>> }
>>> func doprint() {
>>> once.Do(setup)
>>> fmt.Print(a)
>>> }
>>> func twoprint() {
>>> var wg sync.WaitGroup
>>> wg.Add(2)
>>>
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>> go func() {
>>> doprint()
>>> wg.Done()
>>> }()
>>>
>>> wg.Wait()
>>> }
>>>
>>> func main() {
>>> twoprint()
>>> }
>>>
>>>
>>> Cheers snmed
>>>
>>>
>>> Am Donnerstag, 2. November 2017 10:37:15 UTC+1 schrieb 
>>> 28911...@gmail.com:

 Sorry,I try my best to open the website but it can't work.Can you write 
 it ??Thank you so much.

 在 2017年10月30日星期一 UTC+8下午4:29:44，snmed写道：
>
> Hi
>
> There are several ways to solve it, here are two of them:
>
> https://play.golang.org/p/wJwkI7HQwv
> https://play.golang.org/p/nasUcgBeG4
>
> I prefer the first one, because so I can decide if i want to wait for 
> the end of twoprint or not.
>
> Cheers
>
> Am Montag, 30. Oktober 2017 06:43:45 UTC+1 schrieb 28911...@gmail.com:
>>
>> Yes, you're right.So how to solve it??
>>
>> 在 2017年10月30日星期一 UTC+8下午12:37:49，Dave Cheney写道：
>>>
>>> Hello. I’m guessing that your tried calling twoprint(), but you’ve 
>>> probably found that nothing is printed to the screen before your 
>>> program 
>>> exits. 
>>>
>>> Is that correct?
>>
>> -- 
>> 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 .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Rationale in docs on why you need to use the result of append()

[Christoph Berger]

This describes pretty clearly what happens behind the scenes. 

Still, someone could wonder why append then does not receive a pointer to 
the slice, to ensure that both the slice header and the slice data are 
treated in a consistent way. 

What is the generally accepted answer to this? For example,

* In/out parameters are bad coding style
* append shall have a function signature similar to other standard 
functions, for example, fmt.Sprintf (that also returns its result, rather 
than updating a pointer parameter)
* or some technical reason


On Monday, November 6, 2017 at 3:24:55 AM UTC+1, Dave Cheney wrote:
>
> I think #1 would be clearer if it were written as 
>
> 1) "We must return the slice afterwards because ... the our slice value 
> (the run-time data structure holding the pointer, length, and capacity) is 
> a copy of the callers.”

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

[go-nuts] Re: How to learn golang web development

[Christoph Berger]

"Learn to Create Web Applications using Go"  offers 
both a course and a book about the topic. I have the book and love it, and 
the course also looks impressive from what I can see on the landing page.

On Thursday, October 12, 2017 at 3:39:32 PM UTC+2, snakes wrote:
>
> How to learn golang web development,Can you recommend a better book 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: ListenAndServeTLS() godoc comment

[Christoph Berger]

According to RFC4346 (found via serverfault 
<https://serverfault.com/a/476620>), the root certificate can optionally be 
omitted from the PEM file. So sending the root CA along with the rest of 
the trust chain seems unnecessary but not wrong.


On Tuesday, September 19, 2017 at 12:25:46 PM UTC+2, Karsten Weiss wrote:
>
> Reading the certs file in a loop is fine. However, the godoc comment 
> should IMHO say, that the cert file should only consist of the server 
> certificate and the intermediate certificate(s) but NOT the root CA 
> certificate.
>
> On Tuesday, September 19, 2017 at 11:43:49 AM UTC+2, Christoph Berger 
> wrote:
>>
>> My fault, I misinterpreted the diagram on Wikipedia. You are right, the 
>> root CA would not have to be sent to the client then.
>>
>> When I visit the source of ListenAndServeTLS and drill down the function 
>> calls that receive the cert file as a parameter, I end up at function 
>> X509KeyPair (Sourcegraph.com link here 
>> <https://sourcegraph.com/github.com/golang/go/-/blob/src/crypto/tls/tls.go?q=ListenANdServeTLS#L193:6>)
>>  
>> that seems to read all blocks of type CERTIFICATE out of the cert file in a 
>> loop. This would then indeed include the root certificate, right? So it 
>> seems you have a valid point.
>>
>>

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

[go-nuts] Re: ListenAndServeTLS() godoc comment

[Christoph Berger]

My fault, I misinterpreted the diagram on Wikipedia. You are right, the 
root CA would not have to be sent to the client then.

When I visit the source of ListenAndServeTLS and drill down the function 
calls that receive the cert file as a parameter, I end up at function 
X509KeyPair (Sourcegraph.com link here 
<https://sourcegraph.com/github.com/golang/go/-/blob/src/crypto/tls/tls.go?q=ListenANdServeTLS#L193:6>)
 
that seems to read all blocks of type CERTIFICATE out of the cert file in a 
loop. This would then indeed include the root certificate, right? So it 
seems you have a valid point.


On Tuesday, September 19, 2017 at 9:56:15 AM UTC+2, Karsten Weiss wrote:
>
> The client can validate the entire certificate chain because it must have 
> the root CA(s) in its root certificate store already.
>
> Sending the root certificate only increases the TLS message size and adds 
> latency. The TLS client doesn't need the root CA certificate because it 
> must only trust the root CAs in its own root certificate store anyway.
>
> Here are some 3rd party pointers on the topic that I've collected:
>
> - https://community.qualys.com/thread/11026 ("If the client does not have 
> the root in their trust store, then it won't trust the web site, and there 
> is no way to work around that problem. Having the web server send the root 
> certificate will not help -- the root certificate has to come from a 
> trusted 3rd party (in most cases the browser vendor).")
>
> - https://certsimple.com/blog/https-certificate-chains ("The top level, 
> or 'root' certificates are normally trusted because they came with your OS 
> or browser. ... When your browser visits an HTTPS website, it checks the 
> signatures of that site's certificate, and then checks the parent 
> certificate. It keeps checking certificates until it hits the root 
> certificate, stored in whatever trust store you're using.")
>
> - 
> https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html
>  
> ("a common issues is that people unneccesarily[sic] send the root 
> certificate, which doesn't cause issues but may make things slower")
>
> BTW: The Baseline Requirements do not allow that a server certificate is 
> signed directly by a root certificate. (See the certsimple blog post for 
> the explanation.)
>
> On Tuesday, September 19, 2017 at 8:52:14 AM UTC+2, Christoph Berger wrote:
>>
>> I am no TLS expert, but your question makes me wonder why the server 
>> should *not* serve the root CA's certificate. After all, it contains the 
>> signature 
>> <https://en.wikipedia.org/wiki/Public_key_certificate#TLS.2FSSL_server_certificate>
>>  
>> that validates the server's certificate (either directly of via one or more 
>> intermediate CA's signatures). How can the client verify the server's 
>> certificate if the root CA's signature is not handed over to it?
>>
>>

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

[go-nuts] Re: ListenAndServerTLS() godoc comment

[Christoph Berger]

I am no TLS expert, but your question makes me wonder why the server should 
*not* serve the root CA's certificate. After all, it contains the signature 

 
that validates the server's certificate (either directly of via one or more 
intermediate CA's signatures). How can the client verify the server's 
certificate if the root CA's signature is not handed over to it?

On Monday, September 18, 2017 at 9:42:19 PM UTC+2, Karsten Weiss wrote:
>
> Hi,
>
> I have a question about ListenAndServeTLS()'s godoc comment:
>
> // ListenAndServeTLS acts identically to ListenAndServe, except that it 
> // expects HTTPS connections. Additionally, files containing a 
> certificate and 
> // matching private key for the server must be provided. If the 
> certificate 
> // is signed by a certificate authority, the certFile should be the 
> concatenation 
> // of the server's certificate, any intermediates, and the CA's 
> certificate.
>
> I'm surprised about the last part ("and the CA's certificate").
>
> A TLS web server usually does not serve the root CA certificate (only the
> server's certificate and all the intermediate certificates). The root CA 
> certs
> OTOH are stored in the client's root certificate store.
>
> However, the godoc comment seems to indicate that the root CA certificate
> is expected.  Am I misunderstanding the comment?
>
> I would have expected the following godoc comment instead:
>
> // ListenAndServeTLS acts identically to ListenAndServe, except that it 
> // expects HTTPS connections. Additionally, files containing a 
> certificate and 
> // matching private key for the server must be provided. If the 
> certificate 
> // is signed by a certificate authority, the certFile should be the 
> concatenation 
> // of the server's certificate, any intermediates, but NOT the root CA's 
> certificate.
>
> Comments?
>

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

Re: [go-nuts] Offline Go Documentation Tools

[Christoph Berger]

> > Is Visual Studio Code a .Net app that takes up lots of memory and CPU?
> Worse, it's an Electron app :)

I use VSC on an old 2012 Mac Mini, and I cannot confirm that it consumes 
lots of CPU or memory, even with about two dozen extension installed. It is 
fast and responsive (some say it is notably faster than Atom, the other 
Electron-based code editor) and has become my favorite editor for code and 
Markdown (and I have been a diehard Vim user for years, if not decades!). 
Too many open windows may become a problem, but so may too many open tabs 
in Chrome or Firefox. VSC saves the state of a workspace though, so I can 
always happily close a window completely and re-open it later, and VSC 
restores the workspace. 
And VSC has a great Go plugin.

Just give it a try, it is easy to install and easy to remove :)

On Wednesday, August 9, 2017 at 8:25:25 AM UTC+2, Tyler Compton wrote:
>
> > Is Visual Studio Code a .Net app that takes up lots of memory and CPU?
>
> Worse, it's an Electron app :)
> I don't personally use VSC, so I can't speak to its performance or 
> efficiency. However, LSP is currently supported at some level in Neovim 
> using a plugin, and first-class support is planned. It's possible that 
> there's a project to implement LSP in your editor of choice already.
>
> On Mon, Aug 7, 2017 at 7:33 PM me > wrote:
>
>>
>>
>> On Monday, July 24, 2017 at 2:52:48 PM UTC-6, Rob 'Commander' Pike wrote:
>>>
>>> The "go doc" (distinct from "godoc") command works fine offline. It fact 
>>> it never goes on line.
>>>
>>> -rob
>>>
>>>
>> That's a good tip, I might be even able to use that and pipe it into an 
>> editor Memo/Edit widget for instant help with an F1 shortcut. Some editors 
>> have "tools" that you can pipe the output of a process into a status memo 
>> based on the context (current selected item in editor or cursor). Just 
>> running it at a command line and reading it like a man page is an option, 
>> but, I'll likely want something a bit more than that, such as a pop up 
>> window when I hit F1 or a shortcut.
>>
>

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

Re: [go-nuts] "find" for Slices like "append"

[Christoph Berger]

May I ask why you turned to Go in the first place?

Your taunting remarks seem to indicate that you were forced moving to Go; 
but on the other hand, earlier you indicated that you need to sell Go (or 
rather, the lack of a feature in Go) to your team, so it seems you are the 
driving force behind moving to Go. 

In the latter case, if Go does not fulfill your expectations (and given you 
still have free choice), then have you thought about choosing a language 
with the features you need instead? I am sure no one here would seriously 
recommend Go as a "one-size-fits-all" language. Go does not have generics 
nor exceptions, so if you want these features badly, then Go isn't for you.


On Tuesday, August 8, 2017 at 9:15:05 AM UTC+2, marti...@programmfabrik.de 
wrote:
>
>
>> The Go philosophy is explicitly *not* to give you everything you want.  
>> It *is* to give you everything you need to build everything you want, 
>> like Lego.
>>
>
> Yeah right, when men still where real men and programmed their own device 
> drivers...
>
> Or take a car, give me parts & tools and I am ready to give you a ride in 
> say a year? 
>
>
>> Every language is different. Any developer worth their salt won't dismiss 
>> a tool out-of-hand for such a trivial reason.
>>
>
> No nobody would. But trivial things add up and then people run away or 
> never sign up.
>
> I have learnt to never not listen to your (potential) users.
>
> If a new project comes on board of the Go train, people already have to 
> wrap their heads around new (admittedly interesting) concepts, they have to 
> accept "err != nil" spaghetti, distinction between Array and Slices, make 
> and new, and so on.
>
> Personally I got really interested when I died around your standard 
> library which I really like and it seems to give us exactly what we need, 
> not too much, not too little.
>
>>
>> Also, consider the fact that in Python, the same loop is happening. Go 
>> just doesn't hide that from the developer, making it easier for us to 
>> reason about things like performance. You can write your own "find" 
>> function in seconds if you want one.
>>
>
> It just looks awkward:
>
> contains := false
> for _, n := range excluded_numbers {
>   if byte(m) == n {
> contains = true
>   }
> }
> if !contains {
>...
>
> Seriously? 2017?
>
> Martin
>
>  
>> -- 
>> ☕😎
>>
>

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

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

Good point. The same is true for the C-style for loop BTW. 
https://play.golang.org/p/58jwveiywB

Using an explicit boolean flag for signaling success avoids this trap.

> On 2. Aug 2017, at 10:30, tom.pa...@centralway.com wrote:
> 
> A side effect of this approach is that the index after the range loop will be 
> zero if slice contains zero or one elements:
>   https://play.golang.org/p/F7lLZ5wcuv
> 
> This means that code using the index after the range will need to re-test 
> whether the slice was empty to avoid a potential panic.
> 
> On Thursday, July 27, 2017 at 2:21:34 PM UTC+2, Christoph Berger wrote:
> That’s actually what I meant to indicate in the last paragraph (emphasis 
> added by me):
> 
> > The code in the Reddit post takes advantage of the fact that the last 
> > increment of the C-style loop can be observed outside the loop,
> 
> But thanks for providing a clarification. I see now it has not been clear to 
> everyone.
> 
>> On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:
>> 
>>>> someone shared [this question](
>>>> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/
>>>>  
>>>> <https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/>)
>>>>  
>>>> on reddit. I must say, that I'm surprised by the behavior myself. I would 
>>>> have expected
>>>> for i = range v
>>>> to be semantically equivalent to
>>>> for i = 0; i < len(v); i++
>>>> and don't really understand the reasoning behind choosing different 
>>>> semantics. Note, that the difference only exists, if i is declared outside 
>>>> of the loop, that is, this is solely about the behavior after exiting the 
>>>> loop-body.
>>>> 
>>>> I'd greatly appreciate some explanation :)
>>> An attempt to explain this by looking at the C-style loop only:
>>> 
>>> The classic C-style for loop
>>> 
>>> for i:=0; i>> 
>>> is equivalent to
>>> 
>>> for i:=0; i>>// do something with i
>>>i++ // This is always the very last statement in the loop body
>>> }
>>> 
>>> The loop body runs from 0 to len(v)-1 only, because the last increment of i 
>>> to len(v) stops the loop, and no further iteration occurs. The code in the 
>>> loop body never sees i being set to len(v). 
>>> 
>>> And that's the same behavior as with the range operator. 
>>> 
>>> The code in the Reddit post takes advantage of the fact that the last 
>>> increment of the C-style loop can be observed outside the loop, for 
>>> detecting if the loop stopped early. This is a neat side effect that is not 
>>> possible with the range operator.
>> 
>> I would point out that both Axel and you are off a tiny bit from what
>> actually happens ;-)
>> 
>> In a for loop which uses a short variable declaration, that variable's
>> scope is confined to the for *statement* itself, and is also visible in
>> the loop's body because its scope is defined to be nested in that of the
>> loop statement.  This means in a loop like
>> 
>>  for i := 0; i < len(s); i++ {
>>  }
>> 
>> the variable "i" is not accessible after the closing brace.
>> 
>> The actual "problem" stated in that Reddit post is different: it uses a
>> variable defined outside the "for" loop:
>> 
>>  var i int
>>  for i = 0; i < len(v); i++ {
>>  }
>> 
>> As you can see, the loop merely uses that variable; it existed before
>> the loop and continued to live on after it finished executing.
>> 
>> To recap what others have already written, since the for loop's post
>> statement is defined to be executed after each execution of the body
>> (unless it was exited by means of executing `break` or `return`), that
>> 
>>  i++
>> 
>> statement gets executed, the condition evaluates to false, and the loop
>> exits -- with the variable "i" having the value equal to len(v).
>> 
>> One could do
>> 
>>  var x int
>> 
>>  for i := 0; i < len(v); i, x = i+1, x*2 {
>>  }
>> 
>> and get even more interesting effect on the variable "x" after the loop
>> finishes executing ;-)
>> 
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>&g

Re: [go-nuts] Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

That’s actually what I meant to indicate in the last paragraph (emphasis added 
by me):

> The code in the Reddit post takes advantage of the fact that the last 
> increment of the C-style loop can be observed outside the loop,

But thanks for providing a clarification. I see now it has not been clear to 
everyone.

> On Wed, Jul 26, 2017 at 08:44:46AM -0700, Christoph Berger wrote:
> 
>>> someone shared [this question](
>>> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
>>>  
>>> on reddit. I must say, that I'm surprised by the behavior myself. I would 
>>> have expected
>>> for i = range v
>>> to be semantically equivalent to
>>> for i = 0; i < len(v); i++
>>> and don't really understand the reasoning behind choosing different 
>>> semantics. Note, that the difference only exists, if i is declared outside 
>>> of the loop, that is, this is solely about the behavior after exiting the 
>>> loop-body.
>>> 
>>> I'd greatly appreciate some explanation :)
>> An attempt to explain this by looking at the C-style loop only:
>> 
>> The classic C-style for loop
>> 
>> for i:=0; i> 
>> is equivalent to
>> 
>> for i:=0; i>// do something with i
>>i++ // This is always the very last statement in the loop body
>> }
>> 
>> The loop body runs from 0 to len(v)-1 only, because the last increment of i 
>> to len(v) stops the loop, and no further iteration occurs. The code in the 
>> loop body never sees i being set to len(v). 
>> 
>> And that's the same behavior as with the range operator. 
>> 
>> The code in the Reddit post takes advantage of the fact that the last 
>> increment of the C-style loop can be observed outside the loop, for 
>> detecting if the loop stopped early. This is a neat side effect that is not 
>> possible with the range operator.
> 
> I would point out that both Axel and you are off a tiny bit from what
> actually happens ;-)
> 
> In a for loop which uses a short variable declaration, that variable's
> scope is confined to the for *statement* itself, and is also visible in
> the loop's body because its scope is defined to be nested in that of the
> loop statement.  This means in a loop like
> 
>  for i := 0; i < len(s); i++ {
>  }
> 
> the variable "i" is not accessible after the closing brace.
> 
> The actual "problem" stated in that Reddit post is different: it uses a
> variable defined outside the "for" loop:
> 
>  var i int
>  for i = 0; i < len(v); i++ {
>  }
> 
> As you can see, the loop merely uses that variable; it existed before
> the loop and continued to live on after it finished executing.
> 
> To recap what others have already written, since the for loop's post
> statement is defined to be executed after each execution of the body
> (unless it was exited by means of executing `break` or `return`), that
> 
>  i++
> 
> statement gets executed, the condition evaluates to false, and the loop
> exits -- with the variable "i" having the value equal to len(v).
> 
> One could do
> 
>  var x int
> 
>  for i := 0; i < len(v); i, x = i+1, x*2 {
>  }
> 
> and get even more interesting effect on the variable "x" after the loop
> finishes executing ;-)
> 
> -- 
> 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/Xi6W3H5mlto/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Reasoning behind behavior of range, when index is maintained

[Christoph Berger]

Hi Axel,

An attempt to explain this by looking at the C-style loop only:

The classic C-style for loop

for i:=0; i
> Hey,
>
> someone shared [this question](
> https://www.reddit.com/r/golang/comments/6paqc0/bug_that_caught_me_with_range/)
>  
> on reddit. I must say, that I'm surprised by the behavior myself. I would 
> have expected
> for i = range v
> to be semantically equivalent to
> for i = 0; i < len(v); i++
> and don't really understand the reasoning behind choosing different 
> semantics. Note, that the difference only exists, if i is declared outside 
> of the loop, that is, this is solely about the behavior after exiting the 
> loop-body.
>
> I'd greatly appreciate some explanation :)
>

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

Re: [go-nuts] How to manage multiple versions of Go?

[Christoph Berger]

> Reproducible builds is common nowadays and that requires you use the same 
> version of the Go compiler, for instance.

Agreed. I did not want to imply that *my* experience with Go compatibility must 
apply to everyone else. 

> On the other hand, if you do containerize your world anyhow, that may be the 
> simplest solution.

I must admit that I silently assumed that Docker is already installed. Having 
to install Docker first might be prohibitive in some scenarios. OS-native 
options like those you mentioned can be a good alternative then.


> On 25. Jun 2017, at 22:07, Jesper Louis Andersen 
>  wrote:
> 
> On Sun, Jun 25, 2017 at 4:36 PM Christoph Berger 
> mailto:christoph.g.ber...@gmail.com>> wrote:
> Thanks to the Go 1 Compatibility Promise, it was never a problem for me to 
> always use the latest Go version (via Homebrew, BTW, which keeps my Go 
> installation up-to-date with next-to-zero effort). 
> 
> 
> That was my first hunch as well, but language compatibility doesn't 
> automatically guarantee implementation compatibility. I'll definitely agree 
> one should strive to make the code work well with the newest Go release 
> always, but there are reasons people doesn't upgrade right away. Reproducible 
> builds is common nowadays and that requires you use the same version of the 
> Go compiler, for instance.
> 
> What I tend to do is to use the newest release for building the software 
> (this ensures that the eventual upgrade path is clear). And then let a build 
> system handle the older versions if needed. That way, you can often program 
> yourself out of the problem by mangling PATHs rather than running a complete 
> docker installation.
> 
> On the other hand, if you do containerize your world anyhow, that may be the 
> simplest solution. I'm quite partial to either jails (FreeBSD) or Zones 
> (Solaris/Illumos) personally over docker though. 

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

Re: [go-nuts] How to manage multiple versions of Go?

[Christoph Berger]

> Could you go into a bit more detail on how you would setup a local docker 
> container for your Go development?

One example has been given by buddyspike already.

Two blog articles for getting started:

https://blog.docker.com/2016/09/docker-golang/ 
<https://blog.docker.com/2016/09/docker-golang/>

https://medium.com/statuscode/golang-docker-for-development-and-production-ce3ad4e69673
 
<https://medium.com/statuscode/golang-docker-for-development-and-production-ce3ad4e69673>


>Also how does the following experience relate to the compatibility promise?
> https://github.com/moovweb/gvm#background

I cannot comment on this experience as there aren’t any details included. 

I acknowledge that in reality there is no such thing as 100% compatibility. So 
far, compatibility issues have been no problem for me, but I can only speak for 
myself. 


> On 25. Jun 2017, at 20:16, st ov  wrote:
> 
> Could you go into a bit more detail on how you would setup a local docker 
> container for your Go development?
> 
> Also how does the following experience relate to the compatibility promise?
> https://github.com/moovweb/gvm#background
> 
> Thanks!
> 
> 
> 
> On Sunday, June 25, 2017 at 7:36:20 AM UTC-7, Christoph Berger wrote:
> Thanks to the Go 1 Compatibility Promise, it was never a problem for me to 
> always use the latest Go version (via Homebrew, BTW, which keeps my Go 
> installation up-to-date with next-to-zero effort). 
> 
> If I ever have the need to use an older version, I'd probably use Docker for 
> that. 
> 
> Advantages of using Go within a Docker container:
> 
> * No accidental mixing of Go versions
> * No multi-GOPATH hassle
> * Can be removed cleanly when not needed anymore.
> 
> On Saturday, June 24, 2017 at 10:12:38 PM UTC+2, st ov wrote:
> Do you use gvm? https://github.com/moovweb/gvm 
> <https://github.com/moovweb/gvm>
> Is there a simpler way?
> 
> How do you avoid conflicts with Homebrew? Should I not run 'brew install go'?
> 
> 
> 
> -- 
> 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/uAcPk39Tb0I/unsubscribe 
> <https://groups.google.com/d/topic/golang-nuts/uAcPk39Tb0I/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: How to manage multiple versions of Go?

[Christoph Berger]

Thanks to the Go 1 Compatibility Promise, it was never a problem for me to 
always use the latest Go version (via Homebrew, BTW, which keeps my Go 
installation up-to-date with next-to-zero effort). 

If I ever have the need to use an older version, I'd probably use Docker 
for that. 

Advantages of using Go within a Docker container:

* No accidental mixing of Go versions
* No multi-GOPATH hassle
* Can be removed cleanly when not needed anymore.

On Saturday, June 24, 2017 at 10:12:38 PM UTC+2, st ov wrote:
>
> Do you use gvm? https://github.com/moovweb/gvm
> Is there a simpler way?
>
> How do you avoid conflicts with Homebrew? Should I not run 'brew install 
> go'?
>
>
>

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

[go-nuts] Re: Is it ok to separate Open and Close logic?

[Christoph Berger]

Is there any reason that Cleanup(f) should be called within DoingStuff()? (A 
reason that maybe is not visible in your example but might become obvious in a 
more complex scenario?) 

Otherwise you could just call `defer Cleanup(file)` in DoStuff() with exactly 
the same result, and you are back at the same-function logic that you want to 
escape from.

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

Re: [go-nuts] Re: Should a program always exit in main()?

[Christoph Berger]

Well, I already thought that my suggestion seems somewhat too simple… :)

I agree, if a fatal error occurs within a goroutine but you don’t want to crash 
the whole process from within this goroutine (or even from within the library), 
then error channels seem the way to go.

> Am 08.02.2017 um 11:04 schrieb Francis Chuang :
> 
> I made a mistake with my example. c.Start() needs to be a separate go routine 
> because it is an infinite loop waiting for messages: go c.Start().
> 
> In that case, I am guessing an errors channel would be the best?
> 
> Cheers,
> Francis
> 
> -- 
> 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/zssLR41Kk3Q/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Should a program always exit in main()?

[Christoph Berger]

To me, the simplest way seems to be to just return an error to the caller 
outside the library:

func (c *Client) Start() *error* {

for {
select {

case m := <-c.message:

for _, handler := range c.handlers {
err := handler(m)
*if err != nil {*
*return err*
* }*

}
}
}
}


On Wednesday, February 8, 2017 at 12:12:13 AM UTC+1, Francis Chuang wrote:
>
> I am working on a client library that starts a Kafka consumer to listen 
> for messages from a kafka stream and run some user defined handlers.* I 
> want the design to be "crash-only" as much as possible*, so will be 
> avoiding cleanups during unexpected shutdowns.
>
> For example, here's a simple sketch:
>
> func myHandler(m client.Message) error{
> ...
> }
>
> c := client.New(...)
> c.AddHandler(myHandler)
> c.Start()
>
> c.Start() looks like this:
>
> func (c *Client) Start(){
>   
>for{
>  select{
>
>case m := <-c.message:
> 
>  for _, handler := range c.handlers{
>   err := handler(m)
>  }
> }
>}
> }
>
> If the handler encounters an error, I have the following options:
> - call log.Fatal() within the for _, handler := range loop. This seems to 
> be the simplest, but it doesn't seem right for a library to exit.
> - remove the return error from the handler, and call log.Fatal() within so 
> that the handler terminates the whole program.
> - create an error channel, have the for _, handler := range loop write 
> errors to that channel. In main(), have a for, select loop to read from the 
> error channel and call log.Fatal() there.
>
> Which of these options is the most idiomatic?
>
> Cheers,
> Francis
>

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

Re: [go-nuts] Re: Disadvantage of Go

[Christoph Berger]

> None of these alternatives really solve any real problem generics would solve.

True, and the article does not mean to imply this. But often it would seem that 
there is no alternative to using generics for solving a given problem although 
there is one if you look close enough. Of course this depends on the nature of 
the problem to solve, and I am far from saying that generics are superfluous. 

> It's not being blind to another solution, 

Sometimes it is.

> every other solution has drawbacks generics don't have.

Generics have drawbacks, too. It’s always about pros and cons, there is no 
ideal approach.

> But let's not pretend than there is an alternative to generics "people can't 
> see" within Go.

The alternatives are there, depending on the problem to solve. Agreed, there 
are domains  where the alternatives are cumbersome to implement, use, and/or 
maintain, but it is not true that there are no other options. 

> Let's not patronize people who see the obvious flaw in that logic.

If anything I wrote came across as patronizing, then I apologize. I only try to 
help people by pointing out other approaches. If someone is new to the 
language, they might not yet have heard of the techniques I listed in the 
article.

> people coming from Java, C# or Haskell will have harder time working around 
> the lack of generics in Go because they are used to that feature to solve 
> their problems. 

That’s the point. Asking why Go does not have feature X of language Y is 
pointless because Go is not language Y. 
Every language is the result of a series of design decisions, and so is Go. 

> To the latter I'd say that if Go feels tedious for a task then use something 
> else, really. 

Absolutely. I see we’re on the same page here.


To add some other aspects to the discussion, in a recent talk, William Kennedy 
shares some very interesting thoughts about Generics:

https://www.youtube.com/watch?v=7YcLIbG1ekM&feature=youtu.be&t=49m29s 
<https://www.youtube.com/watch?v=7YcLIbG1ekM&feature=youtu.be&t=49m29s>

(This link starts at minute 49:29 - ensure to watch at least past minute 54.)



> Am 14.01.2017 um 12:27 schrieb paraiso.m...@gmail.com:
> 
> >  Some time ago I collected a number of alternatives to using generics - 
> > see: https://appliedgo.net/generics <https://appliedgo.net/generics>
> 
> None of these alternatives really solve any real problem generics would 
> solve. Generics are types, just like first class functions. Lamenting on the 
> lack on generics is useless as well, Go will never have generics because of 
> forward compatibility. 
> 
> But let's not pretend than there is an alternative to generics "people can't 
> see" within Go. Go just wasn't built for code re-use in mind or writing 
> abstractions at all due to the lack of polymorphism in the language. So 
> people have to write specialized code when it comes to writing logic 
> involving containers, that's the only truth there is.
> 
> > If you have a particular problem and you think, "I do need generics to 
> > implement that!", then you might become blind for other solutions. 
> 
> It's not being blind to another solution, every other solution has drawbacks 
> generics don't have. Code generation involve writing pre-processors and 
> maintaining manifests, opting out of Go type system with interface{} 
> everywhere is obviously problematic. That's not solving what generics are 
> here for in languages such as Java C# or Haskell. Basically you are asking 
> developers to pay a price the compiler doesn't want to pay. Let's not 
> patronize people who see the obvious flaw in that logic.
> 
> Again while it is useless to complain, people are complaining for a good 
> reason, it can be difficult to understand what led to the absence of generics 
> at first place in Go design. People coming from C,Python,Javascript and Ruby 
> might not care, people coming from Java, C# or Haskell will have harder time 
> working around the lack of generics in Go because they are used to that 
> feature to solve their problems. 
> 
> To the latter I'd say that if Go feels tedious for a task then use something 
> else, really. Go wasn't designed to please people who like expressive static 
> type systems. There are many alternatives such as D, Ocaml, ... 
> 
> Le samedi 14 janvier 2017 10:35:33 UTC+1, Christoph Berger a écrit :
> Hi Yu,
> 
> Generics have their use cases, e.g. when designing general data containers or 
> in the context of numeric computation (matrix type of int, float, etc). In 
> other areas, however, their use may be overrated. 
> 
> If you have a particular problem and you think, "I do need generics to 
&

[go-nuts] Re: Disadvantage of Go

[Christoph Berger]

Hi Yu,

Generics have their use cases, e.g. when designing general data containers 
or in the context of numeric computation (matrix type of int, float, etc). 
In other areas, however, their use may be overrated. 

If you have a particular problem and you think, "I do need generics to 
implement that!", then you might become blind for other solutions. 

Some time ago I collected a number of alternatives to using generics - see: 
https://appliedgo.net/generics

Best,
Christoph


On Saturday, January 14, 2017 at 7:42:43 AM UTC+1, Yu Liu wrote:
>
> Agree.
>
> Only generics missing is disadvantage of Go.
>
> Yu
>
> On Friday, January 13, 2017 at 10:56:07 AM UTC-8, simon place wrote:
>
>> sorry but for me, excepting generics and maybe a float32 maths lib, these 
>> are all just your problem.
>>
>> particularly wrong is the idea of native conversion of bools to/from 
>> numbers, albeit widespread and long-standing, perpetuating these mistakes 
>> just means preventing any development of languages.
>>
>

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

[go-nuts] Deleting the /r/golang subreddit

[Christoph Berger]

Deleting /r/golang means destroying a very active community.
Deleting /r/golang means deleting years of helpful answers, fruitful 
discussions, and useful links. 
Deleting /r/golang means thousands of seach engine results becoming stale.
Deleting /r/golang means making Go less visible to the world.

Please don't.

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

Re: [go-nuts] Re: Namespacing hack using method on empty type

[Christoph Berger]

Hi Christian,

You’re right on this, but my question is about another aspect. The thread 
starter’s question was about using structs for namespaces (instead of 
packages). My question is, why would someone want to use empty structs for 
creating a name space if a package already does this. After all, packages are 
the natural means for creating a namespace.

Thx


> Am 05.08.2016 um 11:10 schrieb Christian Joergensen 
> :
> 
> Hi,
> 
> For starters, packages can't implement interfaces.
> 
> Cheers,
> 
> On Friday, August 5, 2016 at 6:19:31 AM UTC+2, Christoph Berger wrote:
> Are there any advantages over using real packages?
> 
> -- 
> 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/yCgjgpQsbHc/unsubscribe 
> <https://groups.google.com/d/topic/golang-nuts/yCgjgpQsbHc/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Namespacing hack using method on empty type

[Christoph Berger]

Are there any advantages over using real packages?

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

[go-nuts] Re: OS X Installer: Why modify $PATH instead of adding symbolic links to /usr/local/bin?

[Christoph Berger]

I cannot answer your question; I just wanted to mention that homebrew 
 creates symlinks in /usr/local/bin when installing Go. So 
if you are just looking for an installer that does not extend $PATH, you 
might want to give homebrew a try. 

On Tuesday, July 12, 2016 at 10:05:36 PM UTC+2, jsej...@gmail.com wrote:
>
> Don't read this as a complaint. I'm trying to get feedback from code 
> reviewers about the design decision regarding this behavior of the 
> installer.
>
> In my experience, most software for OS X that installs cli components 
> installs to /usr/local/ and then creates symbolic links to executables in 
> /usr/local/bin/, as not to modify my $PATH. However, the Go installer 
> differs in approach by creating a new entry in /etc/paths.d/ for 
> path_helper 
> 
>  
> to read and then modify my $PATH. Can someone please explain the thinking 
> behind this design decision? Is it more common on Linux to have a lot of 
> path additions instead of symbolic links to executables? Was this something 
> that was discussed and decided upon by the core team or just an arbitrary 
> decision?
>
> I'd love to get a better understanding of why this choice. I have never 
> seen another software take this approach.
>
>
> 
>
>

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

Re: [go-nuts] function with goroutine returned will kill its goroutine?

[Christoph Berger]

Good point, thanks. Yes, when the process exits, the goroutines end immediately 
without running their defer functions.


> Am 06.07.2016 um 16:47 schrieb Paul Borman :
> 
> You probably should say all goroutines are terminated when main exits (or 
> os.Exit is called or the program abnormally terminates), lest someone 
> complain that their defer functions were not run.
> 
> On Tue, Jul 5, 2016 at 12:29 PM, Christoph Berger 
> mailto:christoph.g.ber...@gmail.com>> wrote:
> In addition to that, all goroutines exit when the main function exits. In 
> your code, this happens when i == 5. This explains the output that you get. 
> Both goroutines are able to produce five numbers until the main loop finishes 
> and the main function exits.
> 
> On Monday, July 4, 2016 at 5:13:39 PM UTC+2, Jan Mercl wrote:
> 
> On Mon, Jul 4, 2016 at 5:08 PM Kenshin Wang > wrote:
> 
> go func(i int) {
> for {
> next <- i
> i++
> }
> }(start)
> 
> > could anyone can explain why the output is this?
> 
> A goroutine dies when it returns. A goroutine with an endless loop is 
> immortal (modulo unhandled panics).
> 
> -- 
> -j
> 
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] function with goroutine returned will kill its goroutine?

[Christoph Berger]

In addition to that, all goroutines exit when the main function exits. In 
your code, this happens when i == 5. This explains the output that you get. 
Both goroutines are able to produce five numbers until the main loop 
finishes and the main function exits.

On Monday, July 4, 2016 at 5:13:39 PM UTC+2, Jan Mercl wrote:
>
>
> On Mon, Jul 4, 2016 at 5:08 PM Kenshin Wang  > wrote:
>
> go func(i int) {
> for {
> next <- i
> i++
> }
> }(start)
>
> > could anyone can explain why the output is this?
>
> A goroutine dies when it returns. A goroutine with an endless loop is 
> immortal (modulo unhandled panics).
>
> -- 
>
> -j
>

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

[go-nuts] Re: Currying in Go

[Christoph Berger]

> this seems like an eyesore and maintenance concern. (...) it does cause 
me to hear code review sirens going off in the distance. 

Then why would you want to use currying in Go at all? What's the point of 
being able to write f(1)(2)(3) instead of f(1,2,3) *in a non-functional 
language?* Especially if the price you pay is code that is hard to read and 
difficult to maintain. 

As a Go proverb says, "Clear is better than 
clever".


On Friday, June 17, 2016 at 12:00:43 AM UTC+2, Zauberkraut wrote:
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. Thanks!
>

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