Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[alex . besogonov]

That won't work if you want to create the name dynamically. It's also not 
very useful if you're in a debugger and want to navigate to a different 
goroutine.

I'm actually thinking about writing an RFC for a SetGoroutineName function 
to allow to customize the name. It will be strictly accessible only through 
the debugger or through stack traces, there will NOT be a GetGoroutineName 
counterpart.

On Thursday, November 22, 2018 at 9:30:58 PM UTC-8, Michael Jones wrote:
>
> It is possible and easy to create named functions and launch them. 
>
> a := func(stuff){morestuff}
>
> go a(args)
>
> On Thu, Nov 22, 2018 at 7:38 PM Russtopia > 
> wrote:
>
>> Perhaps this is actually supported in Go v1 and I'm just missing 
>> something simple, but it appears one can do
>>
>> func A() {
>>   go func() {
>>   ...
>>   }()
>> }
>>
>> but not
>>
>> func A() {
>>   go func B() {
>> ...
>>   }()
>> }
>>
>> or even
>>
>> func A() {
>>   func B() {
>> ..
>>   }
>>
>>   go B()
>> }
>>
>> Does the syntax just not allow naming a goroutine, or nested funcs that 
>> are *not* goroutines, at all?
>>
>> I think this would be a nice feature for two reasons:
>>
>> 1. It is, of course, possible to just move the goroutine out into an 
>> outside, named function, but then one must manually identify, declare and 
>> pass all the parameters the goroutine might otherwise automatically capture 
>> from its parent scope(s) when refactoring it. One loses the nice 
>> closure-ish syntax of goroutines;
>>
>> 2. It would allow tools such as graphviz to more easily generate diagrams 
>> that can name goroutines something meaningful other than "func$1" for a 
>> goroutine launched within "func".
>>
>> -Russ
>>
>> -- 
>> 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.
>>
> -- 
>
> *Michael T. jonesmichae...@gmail.com *
>

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

[go-nuts] Re: Simple Go http daemon under systemd

[Diego Medina]

Check this repository

https://github.com/fmpwizard/mrwilson

* It runs a very simple https service
* Gets certificates using Let's Encrypt
* Has ansible playbook to run the app under systemd

feel free to ask any questions.

Diego




On Thursday, November 22, 2018 at 10:14:52 PM UTC-5, Tong Sun wrote:
>
> Hi, 
>
> I want to write a simple Go http daemon that return a static string 
> regardless what the request is, 
> like this one: 
> https://github.com/suntong/dbab/blob/master/src/bin/dbab-svr#L20
>
> and it needs to be working under systemd. 
>
> *What is the best example that I can start with?* (They both, Go http 
> daemon and systemd, and new to me)
>
> I found 
>
> enricofoltran /main.go 
> 
>
> A simple golang web server with basic logging, tracing, health check, 
> graceful shutdown and zero dependencies
>
>
> but it seems not supporting https requests,
>
> I also found 
>
> tabalt /gracehttp 
> 
>
> a simple and graceful HTTP server for Golang
>
>
> which seems quite complete, it has nice single-handling and https support. 
> but there is no mentioning of how it can work under systemd, which could 
> be troublesome, 
> like the question I found at why systemd cannot start golang web app 
> 
>
> Any help appreciated. Thx. 
>
>

-- 
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] help with openpgp error: tag byte does not have MSB set

[Diego Medina]

Hi,

At work we get pgp encrypted files from different vendors, when our app 
tries to decrypt the file from one of them, I get:

openpgp: invalid data: tag byte does not have MSB set

But if I use the gpg command line, I'm able to decrypt it.


Part of the verbose output from gpg when it decrypts it is:

gpg --decrypt-files -vvv xyz.zip.pgp 
gpg: using character set `utf-8'
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: EldoS PGPBlackbox (.NET edition)
:pubkey enc packet: version 3, algo 1, keyid AFF537579B90F252
data: [4095 bits]

gpg: public key encrypted data: good DEK
:pubkey enc packet: version 3, algo 1, keyid 
data: [4095 bits]
gpg: public key is 
:encrypted data packet:
length: unknown
mdc_method: 2


:literal data packet:
mode b (62), created 1542720445, name="xyz.zip",
raw data: unknown length
gpg: original file name='xyz.zip'
gpg: decryption okay


==

Any help solving this, or even better understand it would be great.

Thanks

Diego








-- 
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: GoAWK: an AWK interpreter written in Go

[Michael Jones]

and always: https://www.cs.princeton.edu/~bwk/btl.mirror/awkc++.pdf

On Thu, Nov 22, 2018 at 8:24 PM Tong Sun  wrote:

>
>
> On Tuesday, August 28, 2018 at 9:06:22 AM UTC-4, Ben Hoyt wrote:
>>
>> Once you have some proper benchmarks, it might be fun to compare GoAWK's
>>> performance to that of my awk package .
>>>
>>
>> Nice -- will do!
>>
>
> Please post back when you've done that.
>
> I'm interested to know. Thx.
>
> --
> 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.
>


-- 

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

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

Re: [go-nuts] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Michael Jones]

It is possible and easy to create named functions and launch them.

a := func(stuff){morestuff}

go a(args)

On Thu, Nov 22, 2018 at 7:38 PM Russtopia  wrote:

> Perhaps this is actually supported in Go v1 and I'm just missing something
> simple, but it appears one can do
>
> func A() {
>   go func() {
>   ...
>   }()
> }
>
> but not
>
> func A() {
>   go func B() {
> ...
>   }()
> }
>
> or even
>
> func A() {
>   func B() {
> ..
>   }
>
>   go B()
> }
>
> Does the syntax just not allow naming a goroutine, or nested funcs that
> are *not* goroutines, at all?
>
> I think this would be a nice feature for two reasons:
>
> 1. It is, of course, possible to just move the goroutine out into an
> outside, named function, but then one must manually identify, declare and
> pass all the parameters the goroutine might otherwise automatically capture
> from its parent scope(s) when refactoring it. One loses the nice
> closure-ish syntax of goroutines;
>
> 2. It would allow tools such as graphviz to more easily generate diagrams
> that can name goroutines something meaningful other than "func$1" for a
> goroutine launched within "func".
>
> -Russ
>
> --
> 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.
>
-- 

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

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

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

[Tong Sun]

On Tuesday, August 28, 2018 at 9:06:22 AM UTC-4, Ben Hoyt wrote:
>
> Once you have some proper benchmarks, it might be fun to compare GoAWK's 
>> performance to that of my awk package .
>>
>
> Nice -- will do!
>
 
Please post back when you've done that. 

I'm interested to know. Thx. 

-- 
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: go language sensitive editor?

[Tong Sun]

Nice added features Serge. 

Any plan to PR them back, or you'd rather keep your fork to your self? Thx. 


On Wednesday, November 21, 2018 at 4:57:05 PM UTC-5, Serge Voilokov wrote:
>
> I am using micro editor: https://github.com/zyedidia/micro . It is 
> terminal-based, supports mouse, uses ctrl+zxcv and shift+arrows for text 
> manipulation, has a multi cursor feature, syntax highlighting.
> Written in golang. Easy to configure and change.
> I am using my fork (https://github.com/serge-v/micro) with added features 
> for golang development: go to decls, go imports, go install, go complete, 
> etc.
>
> On Tuesday, November 20, 2018 at 3:52:11 PM UTC-5, Pat Farrell wrote:
>>
>> I know, this is both a FAQ and an unanswerable question. I'm an old 
>> programmer who has used nearly every editor known to man. I am not a fan of 
>> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>>
>> What editors do folks use for go? I'd like something that can complete 
>> function names, understand imports, and give some assistance.
>>
>

-- 
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] Trivial(?) Go v2 proposal: Named goroutines and/or named nested funcs

[Russtopia]

Perhaps this is actually supported in Go v1 and I'm just missing something
simple, but it appears one can do

func A() {
  go func() {
  ...
  }()
}

but not

func A() {
  go func B() {
...
  }()
}

or even

func A() {
  func B() {
..
  }

  go B()
}

Does the syntax just not allow naming a goroutine, or nested funcs that are
*not* goroutines, at all?

I think this would be a nice feature for two reasons:

1. It is, of course, possible to just move the goroutine out into an
outside, named function, but then one must manually identify, declare and
pass all the parameters the goroutine might otherwise automatically capture
from its parent scope(s) when refactoring it. One loses the nice
closure-ish syntax of goroutines;

2. It would allow tools such as graphviz to more easily generate diagrams
that can name goroutines something meaningful other than "func$1" for a
goroutine launched within "func".

-Russ

-- 
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] does struct pointer *a == *b make sense?

[Jesse McNelis]

On Fri, Nov 23, 2018 at 2:06 PM Youqi yu  wrote:
>
> type T {
>  Name string
> }
> a := {Name:"test"}
> b :={Name:"test"}
> *a == *b
> Hi, all, I am beginner at golang, I have a question that when compare struct 
> equality, I was told to use reflect.DeepEqual or make my own function. but 
> the result of above code is true. Does it mean struct a equals struct b?

Yes, they are equal. But how the equality is decided may not always be
what you want.
eg.

type T {
   Name string
   Child *T
}
a := {Name:"test", Child: {Name: "blah", Child: nil}}
b :={Name:"test", Child: {Name: "blah", Child: nil}}
*a == *b // false
reflect.DeepEqual(a,b) //true

-- 
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] Simple Go http daemon under systemd

[Tong Sun]

Hi, 

I want to write a simple Go http daemon that return a static string 
regardless what the request is, 
like this 
one: https://github.com/suntong/dbab/blob/master/src/bin/dbab-svr#L20

and it needs to be working under systemd. 

*What is the best example that I can start with?* (They both, Go http 
daemon and systemd, and new to me)

I found 

enricofoltran /main.go 


A simple golang web server with basic logging, tracing, health check, 
graceful shutdown and zero dependencies


but it seems not supporting https requests,

I also found 

tabalt /gracehttp 


a simple and graceful HTTP server for Golang


which seems quite complete, it has nice single-handling and https support. 
but there is no mentioning of how it can work under systemd, which could be 
troublesome, 
like the question I found at why systemd cannot start golang web app 


Any help appreciated. Thx. 

-- 
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] does struct pointer *a == *b make sense?

[Uzondu Enudeme]

Yes. They are equal.

According to the go language spec:


   - Struct values are comparable if all their fields are comparable. Two
   struct values are equal if their corresponding non-blank
    fields are equal.

You can go through that part of the spec for greater understanding of the
equality operator.

https://golang.org/ref/spec#Comparison_operators


Ragards,

Uzondu


On Fri, Nov 23, 2018, 04:06 Youqi yu  type T {
>  Name string
> }
> a := {Name:"test"}
> b :={Name:"test"}
> *a == *b
> Hi, all, I am beginner at golang, I have a question that when compare
> struct equality, I was told to use reflect.DeepEqual or make my own
> function. but the result of above code is true. Does it mean struct a
> equals struct b?
> thx.
>
> --
> 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.
>

-- 
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] does struct pointer *a == *b make sense?

[Youqi yu]

type T {
 Name string
}
a := {Name:"test"}
b :={Name:"test"}
*a == *b
Hi, all, I am beginner at golang, I have a question that when compare 
struct equality, I was told to use reflect.DeepEqual or make my own 
function. but the result of above code is true. Does it mean struct a 
equals struct b?
thx.

-- 
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: go language sensitive editor?

[Rob Pike]

And 15 years later, so one hopes for an improvement.

The thing people ignore, or perhaps just don't know, about ed was that it
was a breath of fresh air compared to all the commercial editors available
at time. People judge it by the standards of today; by the standards of the
time it was created, it was mind-expanding.

I spoke about this some in my recent personal story of Unix history:
https://www.youtube.com/watch?time_continue=226=_2NI6t2r_Hs

-rob


On Fri, Nov 23, 2018 at 7:58 AM Dave MacFarlane  wrote:

> But sam is a pretty solid improvement over ed.
>
> On Tue, Nov 20, 2018 at 6:04 PM Rob Pike  wrote:
> >
> > Ed is the standard text editor.
> >
> > -rob
> >
> >
> > On Wed, Nov 21, 2018 at 8:15 AM  wrote:
> >>
> >>
> >> Another vote for VS Code. I'm a hobbyist and have tried lots of editors.
> >>
> >> On Tuesday, November 20, 2018 at 1:52:11 PM UTC-7, Pat Farrell wrote:
> >>>
> >>> I know, this is both a FAQ and an unanswerable question. I'm an old
> programmer who has used nearly every editor known to man. I am not a fan of
> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
> >>>
> >>> What editors do folks use for go? I'd like something that can complete
> function names, understand imports, and give some assistance.
> >>
> >> --
> >> 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.
> >
> > --
> > 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.
>
>
>
> --
> - Dave
>

-- 
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: go language sensitive editor?

[Dave MacFarlane]

But sam is a pretty solid improvement over ed.

On Tue, Nov 20, 2018 at 6:04 PM Rob Pike  wrote:
>
> Ed is the standard text editor.
>
> -rob
>
>
> On Wed, Nov 21, 2018 at 8:15 AM  wrote:
>>
>>
>> Another vote for VS Code. I'm a hobbyist and have tried lots of editors.
>>
>> On Tuesday, November 20, 2018 at 1:52:11 PM UTC-7, Pat Farrell wrote:
>>>
>>> I know, this is both a FAQ and an unanswerable question. I'm an old 
>>> programmer who has used nearly every editor known to man. I am not a fan of 
>>> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>>>
>>> What editors do folks use for go? I'd like something that can complete 
>>> function names, understand imports, and give some assistance.
>>
>> --
>> 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.
>
> --
> 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.



-- 
- Dave

-- 
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: go language sensitive editor?

[Rob Pike]

http://man.cat-v.org/unix-6th/1/ed

On Fri, Nov 23, 2018 at 12:48 AM Anirudh Vyas  wrote:

> Could never get this one - Ed is the standard editor, is there a
> historical context of this? Did people say this a lot back when there were
> vim emacs and Ed only as choices of editors?
> On Nov 22, 2018, 05:28 -0800, Volker Dobler ,
> wrote:
>
> As emacs has not been recommended yet: Emacs!
>
> V.
>
> On Tuesday, 20 November 2018 21:52:11 UTC+1, Pat Farrell wrote:
>>
>> I know, this is both a FAQ and an unanswerable question. I'm an old
>> programmer who has used nearly every editor known to man. I am not a fan of
>> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>>
>> What editors do folks use for go? I'd like something that can complete
>> function names, understand imports, and give some assistance.
>>
> --
> 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.
>
> --
> 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.
>

-- 
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] Distributed MapReduce in Go, is it possible?

[yahiahasan30]

Hi how are you can you help me I need distributed mapreduce  code for golan
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Pulling golang/go causes a merge conflict. Is it just me :(

[Jan Mercl]

On Thu, Nov 22, 2018 at 7:34 PM Muhammad Falak R Wani 
wrote:

See https://groups.google.com/d/msg/golang-dev/8JmYrD3DWY0/oNVcA29FBgAJ


-- 

-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: go modules and vendor: redundant features?

[miha . vrhovnik]

Vendoring MUST stay. Athens is another piece of software that has to be set 
up and keep update. Venoring solves this porblem and ols the one when 
dependencies go missing.

On Saturday, November 17, 2018 at 5:33:55 AM UTC+1, Henry wrote:
>
> Hi, 
>
> It seems to me that go modules and vendor attempt to solve the same 
> problem. I wonder whether we should just choose one and scrap the other, or 
> find a way to consolidate them under a single unified feature. I am a bit 
> concerned with the direction Go is going. People keep adding stuffs into Go 
> and later find themselves unable to remove existing features due to the 
> backward compatibility promise. Go 1.11 is a different beast than Go 1.0, 
> and is significantly more complex. 
>
> I think Go2 is an opportunity to learn from Go1, and to start from a clean 
> slate by scraping and consolidating features. Go2 needs to be simpler than 
> Go1.11
>
> Henry
>

-- 
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] Pulling golang/go causes a merge conflict. Is it just me :(

[Muhammad Falak R Wani]

I am pretty sure I did not touch anything on my local master.
Any fixes

-mfrw

-- 
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: Distributed MapReduce in Go, is it possible?

[yahiahasan30]

در شنبه 25 مهٔ 2013، ساعت 0:14:52 (UTC+4:30)، Ziad Hatahet نوشته:
>
> On Fri, May 24, 2013 at 9:55 AM, Sanjay > 
> wrote:
>
>>
>> As for Spark, as with LINQ, that kind of terse functional method-calling 
>> in Go is, AFAIK, impossible. But, again, look at Storm's API for doing 
>> realtime computation: 
>> https://github.com/nathanmarz/storm/blob/master/storm-core/src/jvm/storm/trident/tuple/TridentTuple.java.
>>  
>> You see the exact same kind of thing. If Storm can do it with a low-level 
>> API thats basically untyped, I don't see why Go couldn't.
>>
>
>
> Though in Scala you could do something along the lines of:
>
> val i = tuple.get[Int](0) // Returned value is of type Int
> val s = tuple.get[String](0) // Returned value is of type String
>
> As such, you have a clean, single method interface, instead of exposing 
> multiple getters (getXXX).
>
>
> --
> Ziad
>
>

-- 
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] recommend that error and panic auto coverting

[Liam]

A predefined handler which produces a panic appears in item (L) of
Requirements to Consider for Go 2 Error Handling 


...which is a comprehensive survey of error-related issues, most of which 
aren't mentioned in the draft design.

What's the use case for a function-call-specific recover?

PS: this thread is attached to an unrelated thread due to in-reply-to 
header; it should be forwarded to separate it...

On Thursday, November 22, 2018 at 3:24:16 AM UTC-8, Michel Levieux wrote:
>
> I will agree with your point. Even currently, when other ways exist, it 
> highly not recommended to use recover. The only time I've had to use it was 
> in systems that needed to be highly available and that could not break at 
> all, even on bugs or implementation failures. This is a particularly rare 
> case. Maybe there'd be a way to restrict such practices to specific cases?
>
> Yes the interface thing is also a question, haven't thought about that ahah
>
> Le jeu. 22 nov. 2018 à 12:14, Axel Wagner  > a écrit :
>
>> You're right, there is none.
>>
>> IMHO, making recovering from panics easier should be a none-goal. Panics 
>> should be reserved for irrecoverable violations of invariants (i.e. bugs) 
>> and not recovered, in the general case. The main reason panic/recover is 
>> useful today is that it allows to elide some boilerplate, but that won't 
>> matter as much when having check/handle.
>>
>> YMMV, of course.
>>
>> (there's also the secondary issue that panic takes an interface{}, not an 
>> error, so it's not entirely clear what it would mean to convert a panic 
>> into an error - but that's relatively minor)
>>
>> On Thu, Nov 22, 2018 at 12:08 PM Michel Levieux > > wrote:
>>
>>> Sure it is, I think it's part of the same problem, but (mainly for the 
>>> second example) it's more complementary than it is redundant. I haven't 
>>> seen a possibility for "quick recovering" in go2 draft design concerning 
>>> error handling. If there is one, could anyone point it out?
>>>
>>> Le jeu. 22 nov. 2018 à 11:36, Axel Wagner >> > a écrit :
>>>
 This seems very similar (almost identical, safe for the choice of words 
 maybe) to the Go 2 error handling draft design 
 
 .

 On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux >>> > wrote:

> I do like the idea, but the form looks strange IMO. I'd rather make 
> the "Must" convention a new keyword for the first example, and another 
> one 
> for the second (though I don't see a clear keyword for that).
>
> For a panic on error you'd write :
>
> data := must error_func()
>
> Maybe the "try" keyword would be a good choice for the second example 
> since it's been clearly stated that try ... catch blocks won't be 
> implemented in go, which would give something like :
>
> data, err := try panic_func()
>
> But somehow it sounds quite redundant with the possibility to recover 
> from panics? Don't know
>
> Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
> golan...@googlegroups.com > a écrit :
>
>> For an error function:
>>
>> data, err := error_func(…..)
>>
>> can be changed to panic style:
>>
>> data := panic error_func(……)
>>
>>
>>
>> And for a panic function:
>>
>> data := panic_func(……)
>>
>> can be changed to error style:
>>
>> data, err := error panic_func(…...)
>>
>>
>>

-- 
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] go language sensitive editor?

[Aram Hăvărneanu]

On Thu, Nov 22, 2018 at 8:54 AM Bakul Shah  wrote:
> What would be helpful is if 'go doc' had an -n option to show
> filename:linenumer next to the go definitions its shows so that I
> can right click on it and see the source file with cursor on the
> right line!

I subscribe to that idea.

-- 
Aram Hăvărneanu

-- 
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: go language sensitive editor?

[Amnon Baron Cohen]

https://www.gnu.org/fun/jokes/ed-msg.html

On Thursday, 22 November 2018 13:49:09 UTC, Anirudh Vyas wrote:
>
> Could never get this one - Ed is the standard editor, is there a 
> historical context of this? Did people say this a lot back when there were 
> vim emacs and Ed only as choices of editors? 
> On Nov 22, 2018, 05:28 -0800, Volker Dobler  >, wrote:
>
> As emacs has not been recommended yet: Emacs! 
>
> V.
>
> On Tuesday, 20 November 2018 21:52:11 UTC+1, Pat Farrell wrote: 
>>
>> I know, this is both a FAQ and an unanswerable question. I'm an old 
>> programmer who has used nearly every editor known to man. I am not a fan of 
>> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>>
>> What editors do folks use for go? I'd like something that can complete 
>> function names, understand imports, and give some assistance.
>>
> --
> 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] Re: go language sensitive editor?

[Anirudh Vyas]

Could never get this one - Ed is the standard editor, is there a historical 
context of this? Did people say this a lot back when there were vim emacs and 
Ed only as choices of editors?
On Nov 22, 2018, 05:28 -0800, Volker Dobler , wrote:
> As emacs has not been recommended yet: Emacs!
>
> V.
>
> On Tuesday, 20 November 2018 21:52:11 UTC+1, Pat Farrell wrote:
> > I know, this is both a FAQ and an unanswerable question. I'm an old 
> > programmer who has used nearly every editor known to man. I am not a fan of 
> > whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
> >
> > What editors do folks use for go? I'd like something that can complete 
> > function names, understand imports, and give some assistance.
> --
> 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.

-- 
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: go language sensitive editor?

[Volker Dobler]

As emacs has not been recommended yet: Emacs!

V.

On Tuesday, 20 November 2018 21:52:11 UTC+1, Pat Farrell wrote:
>
> I know, this is both a FAQ and an unanswerable question. I'm an old 
> programmer who has used nearly every editor known to man. I am not a fan of 
> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>
> What editors do folks use for go? I'd like something that can complete 
> function names, understand imports, and give some assistance.
>

-- 
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] net/http/httputil.ReverseProxy Expect: 100-continue broken?

[Peter Waller]

I suspect this has to do with the fact that you're doing a roundtrip for
its side effects, but not reading the response body or closing it. If I fix
that, everything seems to work as expected.

Try configuring the TLS client with t.TLSClientConfig =
{InsecureSkipVerify: true}

On Mon, 19 Nov 2018 at 20:30,  wrote:

> Hi folks!
>
> Hoping somebody can help me figure out what I'm doing wrong (or what Go's
> doing wrong in the small chance it's that).
>
> It _seems_ Go's reverse proxy doesn't support 100 Continue when the
> backend is HTTP/2 (but I'm guessing).
>
> I put up the sample at https://github.com/gholt/proxrepro -- just `go run
> main.go` and then look at the `trace` file that's output.
>
> You can see where curl sends its request headers with the Expect:
> 100-continue but the first thing it gets back is 200 OK and then
> "weirdness" ensues.
>
> -- Greg Holt
>
> --
> 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.
>

-- 
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] recommend that error and panic auto coverting

[Michel Levieux]

I will agree with your point. Even currently, when other ways exist, it
highly not recommended to use recover. The only time I've had to use it was
in systems that needed to be highly available and that could not break at
all, even on bugs or implementation failures. This is a particularly rare
case. Maybe there'd be a way to restrict such practices to specific cases?

Yes the interface thing is also a question, haven't thought about that ahah

Le jeu. 22 nov. 2018 à 12:14, Axel Wagner  a
écrit :

> You're right, there is none.
>
> IMHO, making recovering from panics easier should be a none-goal. Panics
> should be reserved for irrecoverable violations of invariants (i.e. bugs)
> and not recovered, in the general case. The main reason panic/recover is
> useful today is that it allows to elide some boilerplate, but that won't
> matter as much when having check/handle.
>
> YMMV, of course.
>
> (there's also the secondary issue that panic takes an interface{}, not an
> error, so it's not entirely clear what it would mean to convert a panic
> into an error - but that's relatively minor)
>
> On Thu, Nov 22, 2018 at 12:08 PM Michel Levieux 
> wrote:
>
>> Sure it is, I think it's part of the same problem, but (mainly for the
>> second example) it's more complementary than it is redundant. I haven't
>> seen a possibility for "quick recovering" in go2 draft design concerning
>> error handling. If there is one, could anyone point it out?
>>
>> Le jeu. 22 nov. 2018 à 11:36, Axel Wagner 
>> a écrit :
>>
>>> This seems very similar (almost identical, safe for the choice of words
>>> maybe) to the Go 2 error handling draft design
>>> 
>>> .
>>>
>>> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux <
>>> m.levi...@capitaldata.fr> wrote:
>>>
 I do like the idea, but the form looks strange IMO. I'd rather make the
 "Must" convention a new keyword for the first example, and another one for
 the second (though I don't see a clear keyword for that).

 For a panic on error you'd write :

 data := must error_func()

 Maybe the "try" keyword would be a good choice for the second example
 since it's been clearly stated that try ... catch blocks won't be
 implemented in go, which would give something like :

 data, err := try panic_func()

 But somehow it sounds quite redundant with the possibility to recover
 from panics? Don't know

 Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
 golang-nuts@googlegroups.com> a écrit :

> For an error function:
>
> data, err := error_func(…..)
>
> can be changed to panic style:
>
> data := panic error_func(……)
>
>
>
> And for a panic function:
>
> data := panic_func(……)
>
> can be changed to error style:
>
> data, err := error panic_func(…...)
>
> --
> 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.
>
 --
 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.

>>>

-- 
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] recommend that error and panic auto coverting

['Axel Wagner' via golang-nuts]

You're right, there is none.

IMHO, making recovering from panics easier should be a none-goal. Panics
should be reserved for irrecoverable violations of invariants (i.e. bugs)
and not recovered, in the general case. The main reason panic/recover is
useful today is that it allows to elide some boilerplate, but that won't
matter as much when having check/handle.

YMMV, of course.

(there's also the secondary issue that panic takes an interface{}, not an
error, so it's not entirely clear what it would mean to convert a panic
into an error - but that's relatively minor)

On Thu, Nov 22, 2018 at 12:08 PM Michel Levieux 
wrote:

> Sure it is, I think it's part of the same problem, but (mainly for the
> second example) it's more complementary than it is redundant. I haven't
> seen a possibility for "quick recovering" in go2 draft design concerning
> error handling. If there is one, could anyone point it out?
>
> Le jeu. 22 nov. 2018 à 11:36, Axel Wagner 
> a écrit :
>
>> This seems very similar (almost identical, safe for the choice of words
>> maybe) to the Go 2 error handling draft design
>> 
>> .
>>
>> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
>> wrote:
>>
>>> I do like the idea, but the form looks strange IMO. I'd rather make the
>>> "Must" convention a new keyword for the first example, and another one for
>>> the second (though I don't see a clear keyword for that).
>>>
>>> For a panic on error you'd write :
>>>
>>> data := must error_func()
>>>
>>> Maybe the "try" keyword would be a good choice for the second example
>>> since it's been clearly stated that try ... catch blocks won't be
>>> implemented in go, which would give something like :
>>>
>>> data, err := try panic_func()
>>>
>>> But somehow it sounds quite redundant with the possibility to recover
>>> from panics? Don't know
>>>
>>> Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
>>> golang-nuts@googlegroups.com> a écrit :
>>>
 For an error function:

 data, err := error_func(…..)

 can be changed to panic style:

 data := panic error_func(……)



 And for a panic function:

 data := panic_func(……)

 can be changed to error style:

 data, err := error panic_func(…...)

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

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

-- 
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] recommend that error and panic auto coverting

[Michel Levieux]

Sure it is, I think it's part of the same problem, but (mainly for the
second example) it's more complementary than it is redundant. I haven't
seen a possibility for "quick recovering" in go2 draft design concerning
error handling. If there is one, could anyone point it out?

Le jeu. 22 nov. 2018 à 11:36, Axel Wagner  a
écrit :

> This seems very similar (almost identical, safe for the choice of words
> maybe) to the Go 2 error handling draft design
> 
> .
>
> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
> wrote:
>
>> I do like the idea, but the form looks strange IMO. I'd rather make the
>> "Must" convention a new keyword for the first example, and another one for
>> the second (though I don't see a clear keyword for that).
>>
>> For a panic on error you'd write :
>>
>> data := must error_func()
>>
>> Maybe the "try" keyword would be a good choice for the second example
>> since it's been clearly stated that try ... catch blocks won't be
>> implemented in go, which would give something like :
>>
>> data, err := try panic_func()
>>
>> But somehow it sounds quite redundant with the possibility to recover
>> from panics? Don't know
>>
>> Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
>> golang-nuts@googlegroups.com> a écrit :
>>
>>> For an error function:
>>>
>>> data, err := error_func(…..)
>>>
>>> can be changed to panic style:
>>>
>>> data := panic error_func(……)
>>>
>>>
>>>
>>> And for a panic function:
>>>
>>> data := panic_func(……)
>>>
>>> can be changed to error style:
>>>
>>> data, err := error panic_func(…...)
>>>
>>> --
>>> 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.
>>>
>> --
>> 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.
>>
>

-- 
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] recommend that error and panic auto coverting

['Axel Wagner' via golang-nuts]

This seems very similar (almost identical, safe for the choice of words
maybe) to the Go 2 error handling draft design

.

On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
wrote:

> I do like the idea, but the form looks strange IMO. I'd rather make the
> "Must" convention a new keyword for the first example, and another one for
> the second (though I don't see a clear keyword for that).
>
> For a panic on error you'd write :
>
> data := must error_func()
>
> Maybe the "try" keyword would be a good choice for the second example
> since it's been clearly stated that try ... catch blocks won't be
> implemented in go, which would give something like :
>
> data, err := try panic_func()
>
> But somehow it sounds quite redundant with the possibility to recover from
> panics? Don't know
>
> Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
> golang-nuts@googlegroups.com> a écrit :
>
>> For an error function:
>>
>> data, err := error_func(…..)
>>
>> can be changed to panic style:
>>
>> data := panic error_func(……)
>>
>>
>>
>> And for a panic function:
>>
>> data := panic_func(……)
>>
>> can be changed to error style:
>>
>> data, err := error panic_func(…...)
>>
>> --
>> 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.
>>
> --
> 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.
>

-- 
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] recommend that error and panic auto coverting

[Michel Levieux]

I do like the idea, but the form looks strange IMO. I'd rather make the
"Must" convention a new keyword for the first example, and another one for
the second (though I don't see a clear keyword for that).

For a panic on error you'd write :

data := must error_func()

Maybe the "try" keyword would be a good choice for the second example since
it's been clearly stated that try ... catch blocks won't be implemented in
go, which would give something like :

data, err := try panic_func()

But somehow it sounds quite redundant with the possibility to recover from
panics? Don't know

Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
golang-nuts@googlegroups.com> a écrit :

> For an error function:
>
> data, err := error_func(…..)
>
> can be changed to panic style:
>
> data := panic error_func(……)
>
>
>
> And for a panic function:
>
> data := panic_func(……)
>
> can be changed to error style:
>
> data, err := error panic_func(…...)
>
> --
> 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.
>

-- 
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] recommend that error and panic auto coverting

['yinbingjun' via golang-nuts]

For an error function:

data, err := error_func(…..)

can be changed to panic style:

data := panic error_func(……)



And for a panic function:

data := panic_func(……)

can be changed to error style:

data, err := error panic_func(…...)

-- 
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] Using git-codereview with GitHub

[Shulhan]

On Wed, 21 Nov 2018 14:48:20 +
Paul Jolly  wrote:

> > There is hub [1].  If you have not heard it, its work by
> > repo-branch-commits,  
> 
> Thanks, but as I understand it, this tool is branch-based.
> 
> I want to make my workflow oriented around single commits (on a local
> branch).
> 

I think that can be solved with an instruction on how one should create
a PR, and mostly a PR is per single commit.  I rarely see, many commits
in PR except in internal/private repository.


-- 
{ "github":"github.com/shuLhan", "site":"kilabit.info" }

-- 
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: go modules and vendor: redundant features?

[Paul Jolly]

The main issue tracking vendoring-related discussion is
https://github.com/golang/go/issues/27227
On Thu, 22 Nov 2018 at 09:08,  wrote:
>
> Vendor must be kept for when dependencies are no longer available online.
>
> On Saturday, 17 November 2018 04:33:55 UTC, Henry wrote:
>>
>> Hi,
>>
>> It seems to me that go modules and vendor attempt to solve the same problem. 
>> I wonder whether we should just choose one and scrap the other, or find a 
>> way to consolidate them under a single unified feature. I am a bit concerned 
>> with the direction Go is going. People keep adding stuffs into Go and later 
>> find themselves unable to remove existing features due to the backward 
>> compatibility promise. Go 1.11 is a different beast than Go 1.0, and is 
>> significantly more complex.
>>
>> I think Go2 is an opportunity to learn from Go1, and to start from a clean 
>> slate by scraping and consolidating features. Go2 needs to be simpler than 
>> Go1.11
>>
>> Henry
>
> --
> 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.

-- 
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: go modules and vendor: redundant features?

[gary . willoughby]

Vendor must be kept for when dependencies are no longer available online.

On Saturday, 17 November 2018 04:33:55 UTC, Henry wrote:
>
> Hi, 
>
> It seems to me that go modules and vendor attempt to solve the same 
> problem. I wonder whether we should just choose one and scrap the other, or 
> find a way to consolidate them under a single unified feature. I am a bit 
> concerned with the direction Go is going. People keep adding stuffs into Go 
> and later find themselves unable to remove existing features due to the 
> backward compatibility promise. Go 1.11 is a different beast than Go 1.0, 
> and is significantly more complex. 
>
> I think Go2 is an opportunity to learn from Go1, and to start from a clean 
> slate by scraping and consolidating features. Go2 needs to be simpler than 
> Go1.11
>
> Henry
>

-- 
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: go language sensitive editor?

[hay]

LiteIDE here. https://github.com/visualfc/liteide

On Wednesday, November 21, 2018 at 12:52:11 AM UTC+4, Pat Farrell wrote:
>
> I know, this is both a FAQ and an unanswerable question. I'm an old 
> programmer who has used nearly every editor known to man. I am not a fan of 
> whole-universe IDEs, but can use them. I also speak vi/vim pretty fluently.
>
> What editors do folks use for go? I'd like something that can complete 
> function names, understand imports, and give some assistance.
>

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