[go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

[T L]

On Thursday, April 5, 2018 at 6:32:46 PM UTC-4, matthe...@gmail.com wrote:
>
> I think if it is not popular until 2020, it will never be popular.
>
>
> I’m not sure popularity is a shared goal in the community; the original 
> goal is to solve problems at Google. 
>

> Matt
>

But it solves the common problem in the IT industry.
Before Go, there are only two popular choices to do backend progrmaming, 
Java (as a compiled langauge) and several dynamic languages.
Now Go presents as an alternative to Java, with many advantages to Java.
 

>
> On Thursday, April 5, 2018 at 12:26:19 PM UTC-5, bingj...@gmail.com wrote:
>>
>> Almost 10 years golang appears in the world. 10 years is not a short 
>> duration. I think if it is not popular until 2020, it will never be popular.
>>
>> Golang is designed for cloud and internet areas. Really?
>>
>> The creators of golang have a lot of experience in C and C++. And golang 
>> borrows features from C and C++. But C and C++ do not fit the requirements 
>> of cloud and internet areas.
>>
>> Let's look at two popular programming languages java and php. What is the 
>> most important features of these two languages? Simple, ugly but 
>> practical... I find one feather: they are both not just programming 
>> languages but also platforms. They are almost the same in Windows and 
>> Linux. That's why java and php are very popular in recent days.
>>
>> C and C++ are just pure programming languages, not platforms. On Unix and 
>> Windows, C and C++ are very different. A developer of windows C++ is not a 
>> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>>
>> If golang wants to be widely used by developer all over the world before 
>> 2020, it must learn some thing from java and php, must be a 
>> programming-language-is-a-platform.
>>
>> Until now, programs written in golang still does not have binary 
>> distribution format like jar, dll or so. People have to share libraries by 
>> source code. It is so foolish.
>>
>> Yes, Golang is very like C and C++, which are only pure programming 
>> language, But this times, we need "language as/is platform" technologies, 
>> just like php and java.
>>
>> I have watched golang for many years, but never turn to it. Why? I think 
>> it is still semi-finished product. Creators of golang are researchers, not 
>> engineers, they worked too slow.
>>
>

-- 
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] Flutter and golang

[Tong Sun]

Saw a recent discussion on Flutter and golang, which seems to me to be 
going the wrong way, because I didn't see the magic word "FIDL 
" being mentioned. So I'd like to 
share my finding about that, 

First of all, about the Flutter:

On February 27, 2018, in Mobile World Congress 2018, Google announced the 
first beta 
 
release of Flutter 
.
 



   - Flutter is Google's new mobile UI framework that helps developers 
   craft high-quality native interfaces for both iOS and Android. 
   - Flutter targets the sweet spot of mobile development: performance and 
   platform integrations of native mobile, with high-velocity development and 
   multi-platform reach of portable UI toolkits.
   

There are loads of articles on Flutter 

 
already, but let me just pick only two:

What’s Revolutionary about Flutter

https://hackernoon.com/whats-revolutionary-about-flutter-946915b09514

Quote:

traditional model layout could be simplified significantly:


   - 
   
   Instead of having a large set of layout rules that could be applied to 
   any widget, each widget would specify its own simple layout model.
   - 
   
   Because each widget has a much smaller set of layout rules to consider, 
   layout can be optimized heavily.
   - 
   
   To simplify layout even further, we turned almost everything into a 
   widget.
   
Second, 

Why we chose Flutter and how it’s changed our company for the better

https://medium.com/@matthew.smith_66715/why-we-chose-flutter-and-how-its-changed-our-company-for-the-better-271ddd25da60

Quote:

Our productivity on new feature development has roughly tripled. Here’s why:


   - 
   
   Not only do we have the obvious gains from having only one code base 
   between iOS and Android, we are able to share ~70% (at the moment of this 
   writing it’s 67%) of our web client code with the mobile clients. But it 
   doesn’t end there. 
   - 
   
   When we test a feature in any of the platforms, unless it’s a platform 
   specific UI change, we are effectively testing across all three platforms 
   at once. We did not expect this gain, but it’s real and it’s significant. 
   
   - 
   
   We also found that because we were able to merge what was a fragmented 
   team into one team with a common skill set, we spend less time being 
   blocked by each other and can more easily work together. And honestly, we 
   are happier. While it’s fun to build a new feature, it becomes a chore to 
   then have to recreate it two more times. Then have to write the platform 
   specific unit tests. Then QA the same thing again.
   

OK, enough about Flutter 
.
 


We all know that recently Google lost its legal battle on using Java, so my 
personal view is that Android would be on the chopping board soon. One hint 
is that Google has silently changed its *Android* play store to *Google* 
Play Store  recently, which means a 
lot to me. 

Anyway, what I'm trying to say is that Flutter 

 
is only a small part of Google's strategic planning to ditch Java, and also 
the two OSs for the mobile phone and pad, the Android & ChromeOS, because 
Flutter 

 
is the center piece of Google's next generation OS, Fuchsia, which will be 
a cross-device OS for Phone, tablet, desktop, laptop, wearables, and more. 

Taken from https://9to5google.com/2018/01/23/what-is-google-fuchsia-os/ 

Most of the Fuchsia's UI is written in Dart  (a 
language that is designed to feel familiar to JavaScript and Java 
developers), through the Flutter framework . Support 
for Go !. Systems 
developers will find comfort in the availability of Rust 
.
 
Google is also targeting Apple’s developer base by introducing Swift support 
.

Once again, the Flutter framework  will support Go 
!  

It has native interoperability support for most of these languages, through 
the FIDL protocol , your Dart UI 
code can directly interface with your Go backend or any other combination. 



Again, the above are all of my finding, and my 2c view on them. 
All in all, I strongly believe that Flutter Will Take Off in 2018 

[go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

[Dave Cheney]

Indeed. Please do not conflate popularity with ubiquity. Formula one is a very 
popular sport, but not everyone needs to do 180mph down the straight away for 
their daily commute. 

-- 
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] colorful go test output

[Alex Efros]

Hi!

When we run `go test` (without package param) it doesn't redirect
os.Stdout, so it's possible to detect is it a TTY and enable color output:
unix.IoctlGetTermios(int(os.Stdout.Fd()), ioctlReadTermios)

But when we run `go test .` (with package param) it does redirect
os.Stdout, so it's became impossible to detect is it a TTY.

Is there any other way to auto-detect is os.Stdout support colors in this
use case? Or should I just introduce env var like $GOTEST_COLOR=1 instead?

-- 
WBR, Alex.

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[matthewjuran]

>
> I think if it is not popular until 2020, it will never be popular.


I’m not sure popularity is a shared goal in the community; the original 
goal is to solve problems at Google.

Matt

On Thursday, April 5, 2018 at 12:26:19 PM UTC-5, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>
> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>
> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

-- 
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: Is there a memory leak on Rob Pike's demo codes?

['Bryan Mills' via golang-nuts]

To answer the original question about how to detect the leak: if you have a 
leak, the “goroutine” profile from runtime/pprof 
 will show an 
ever-increasing number of goroutines with the same stack trace.

Detecting such a leak in a unit or integration test, however, is fairly 
tricky: you can fairly easily detect that the goroutine count is 
increasing, but it can be tricky to figure out whether that is a leak or 
just a transient increase while the program spools up to a steady state.


On Thursday, April 5, 2018 at 4:53:21 PM UTC-4, T L wrote:
>
>
>
> On Thursday, April 5, 2018 at 3:32:53 AM UTC-4, Jan Mercl wrote:
>>
>> On Thu, Apr 5, 2018 at 9:10 AM T L  wrote:
>>
>> > yes. it is a resource leak.
>>
>> It's not necessarily a leak. It's a possible leak.
>>
>> And digging even deeper: it's implementation defined. Non-reachable 
>> channels can be collected and goroutines blocked on them killed without 
>> changing the semantics of the program.
>> -- 
>>
>> -j
>>
>
> There is an issue to do this, but it is denied. 
> https://github.com/golang/go/issues/19702
>  
>

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[Tyler Compton]

Go does not run in a VM like JVM and CLR languages do, but Go provides a
"language as a platform"-like feel by allowing for code that is by and
large platform-independent. It is true that executables have to be built
for each platform but that has benefits of its own. Java applications
require the JVM to be installed, while Go executables work immediately on
the platform without dependencies.

Additionally, I don't really see why having a VM (which I assume is what
you mean by a platform) makes for better language in the cloud space. For
the most part, machines running in the cloud use Linux. If you build your
executable for Linux, you're done. No extra environment configuration
required like one would have to do to run a VM language. Building the
executable is often easy because of Go's great cross-compilation support.
This ease of deployment is something people talk up Go for quite a bit.

If you try Go out, I suspect you won't miss the JVM or the CLR.

On Thu, Apr 5, 2018 at 1:47 PM T L  wrote:

>
>
> On Thursday, April 5, 2018 at 1:26:19 PM UTC-4, bingj...@gmail.com wrote:
>>
>> Almost 10 years golang appears in the world. 10 years is not a short
>> duration. I think if it is not popular until 2020, it will never be popular.
>>
>> Golang is designed for cloud and internet areas. Really?
>>
>> The creators of golang have a lot of experience in C and C++. And golang
>> borrows features from C and C++. But C and C++ do not fit the requirements
>> of cloud and internet areas.
>>
>> Let's look at two popular programming languages java and php. What is the
>> most important features of these two languages? Simple, ugly but
>> practical... I find one feather: they are both not just programming
>> languages but also platforms. They are almost the same in Windows and
>> Linux. That's why java and php are very popular in recent days.
>>
>> C and C++ are just pure programming languages, not platforms. On Unix and
>> Windows, C and C++ are very different. A developer of windows C++ is not a
>> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>>
>> If golang wants to be widely used by developer all over the world before
>> 2020, it must learn some thing from java and php, must be a
>> programming-language-is-a-platform.
>>
>> Until now, programs written in golang still does not have binary
>> distribution format like jar, dll or so. People have to share libraries by
>> source code. It is so foolish.
>>
>
> https://golang.org/cmd/go/#hdr-Build_modes
>
>
>> Yes, Golang is very like C and C++, which are only pure programming
>> language, But this times, we need "language as/is platform" technologies,
>> just like php and java.
>>
>> I have watched golang for many years, but never turn to it. Why? I think
>> it is still semi-finished product. Creators of golang are researchers, not
>> engineers, they worked too slow.
>>
> --
> 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] Re: Is there a memory leak on Rob Pike's demo codes?

[T L]

On Thursday, April 5, 2018 at 3:32:53 AM UTC-4, Jan Mercl wrote:
>
> On Thu, Apr 5, 2018 at 9:10 AM T L  
> wrote:
>
> > yes. it is a resource leak.
>
> It's not necessarily a leak. It's a possible leak.
>
> And digging even deeper: it's implementation defined. Non-reachable 
> channels can be collected and goroutines blocked on them killed without 
> changing the semantics of the program.
> -- 
>
> -j
>

There is an issue to do this, but it is denied. 
https://github.com/golang/go/issues/19702
 

-- 
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: Language is a platform, which golang still does not pay attention to !!!

[T L]

On Thursday, April 5, 2018 at 1:26:19 PM UTC-4, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>

https://golang.org/cmd/go/#hdr-Build_modes
 

> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>
> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

-- 
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: Language is a platform, which golang still does not pay attention to !!!

['Eric Johnson' via golang-nuts]

I have a different perspective

On Thursday, April 5, 2018 at 10:26:19 AM UTC-7, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>

As my company is a potential vendor of commercial Go libraries, I've been 
interested in this very question. I believe your assertion is incorrect. It 
is possible, but not pleasant, to share pre-built Go libraries. The 
challenge is that you have to include stub code to make it work, and make 
sure the timestamps on the stubbed-out code don't get updated. Of course, 
you also have to ship the binaries specific to the platform that the target 
developer is going to use, but that is possible. The advantage of shipping 
the stub code is that you can get all the benefits of existing IDE tooling 
that work off of the source to generate documentation, and understand the 
meaning of your code and how it is used.
 

> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>

What is meant by "language as/is platform"? Just about any library I need, 
I can find for Go. And they happen to work across multiple platforms, just 
like with Java. As with Java before it, Go delivers on database APIs, web 
APIs, and protocols. There's a robust ecosystem of third-party libraries to 
make coding in Go much better. Numerous IDEs and editors include excellent 
support for Go.

Tons of community, including Meetups around the world.

One piece that has been missing relates to versions on libraries. That has 
been addressed in various ways, and a proposal that will most likely join 
the toolchain is in the queue for Go 1.11 (vgo).
 

> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

What would meet the definition of finished? Java still isn't finished, all 
these years later, because they're still adding language features (not just 
libraries!). Is Java slow because of this?

Go has felt to me like it moves very rapidly, as incredible enhancements 
come very quickly to the ecosystem. The compiler is itself now written in 
Go, and most of the runtime, which means that it is more possible for Go 
developers to help tweak the future direction of the language than it is 
for say Java developers, for whom the JVM will mostly be a black-box 
written in C++ that they probably never understand.

Eric.

-- 
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] Language is a platform, which golang still does not pay attention to !!!

[bingjunyin]

Almost 10 years golang appears in the world. 10 years is not a short 
duration. I think if it is not popular until 2020, it will never be popular.

Golang is designed for cloud and internet areas. Really?

The creators of golang have a lot of experience in C and C++. And golang 
borrows features from C and C++. But C and C++ do not fit the requirements 
of cloud and internet areas.

Let's look at two popular programming languages java and php. What is the 
most important features of these two languages? Simple, ugly but 
practical... I find one feather: they are both not just programming 
languages but also platforms. They are almost the same in Windows and 
Linux. That's why java and php are very popular in recent days.

C and C++ are just pure programming languages, not platforms. On Unix and 
Windows, C and C++ are very different. A developer of windows C++ is not a 
developer of UNIX C++, and a Linux C developer is not a Windows C developer.

If golang wants to be widely used by developer all over the world before 
2020, it must learn some thing from java and php, must be a 
programming-language-is-a-platform.

Until now, programs written in golang still does not have binary 
distribution format like jar, dll or so. People have to share libraries by 
source code. It is so foolish.

Yes, Golang is very like C and C++, which are only pure programming 
language, But this times, we need "language as/is platform" technologies, 
just like php and java.

I have watched golang for many years, but never turn to it. Why? I think it 
is still semi-finished product. Creators of golang are researchers, not 
engineers, they worked too slow.

-- 
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] Hosting godoc internally for private git server

[Michael Levine]

How can I make godoc being run on local source code use the godoc 
templates/assets properly from a locally hosted version of godoc?

I tried the following:  $ godoc 
-templates="$GOPATH/src/github.com/golang/gddo/gddo-server/assets" -html 
path/to/local/library > ~/destination/path/library.html

I also found the following notes:

>From (https://github.com/golang/gddo/wiki/Development-Environment-Setup):  
"To run the gddo-server binary outside of a development environment with 
the source in $GOPATH/src/github.com/golang/gddo, you will need a copy of 
the assets directory. Use the gddo-server --assets command line flag to 
specify the location of the directory."

>From (https://github.com/golang/tools/blob/master/godoc/README.md):  "In 
production, CSS/JS/template assets need to be compiled into the godoc 
binary. It can be tedious to recompile assets every time, but you can pass 
a flag to load CSS/JS/templates from disk every time a page loads:$  
godoc -templates=$GOPATH/src/golang.org/x/tools/godoc/static -http=:6060"

Is there a flag I can use when I run godoc to make the proper 
assets/templates get used in the generated file?  



On Tuesday, October 25, 2016 at 7:05:18 PM UTC-4, Stephen Weinberg wrote:
>
> Yeah, I work on godoc.org and we essentially decided not to try to 
> support the internal usecase. The reason is that you can just use the 
> normal godoc tool.
>
> I recommend setting up a simple cron job to pull from github every so 
> often and run the godoc tool. gddo is very very heavy for this small of a 
> use case. It prides itself on efficiently managing the entire (open source) 
> Go corpus. I plan to work on a lot of production improvements (better 
> logging, error reporting, performance tracing) that are just not necessary 
> for a small install. Unless your company is the size of Google, you 
> probably just need to git pull every so often to follow dozens (or maybe 
> even hundreds) repos for your company.
>
> That being said, gddo does take contributions! If you want you can port it 
> to an internal server environment and contribute back. I wouldn't 
> necessarily recommend that though.
>
> -- Stephen
>
> On Tuesday, October 25, 2016 at 10:57:58 AM UTC-4, Kareem Gan wrote:
>>
>> Ah. But I need it to download the repositories from my organizations 
>> enterprise github server through. 
>> On Tue, Oct 25, 2016 at 09:55 Pietro Gagliardi  
>> wrote:
>>
>>> Is imitating golang.org not sufficient? It will still show you all the 
>>> packages in your $GOPATH in the Packages page:
>>>
>>> http://imgur.com/EGpqWsR
>>>
>>> On Oct 25, 2016, at 10:36 AM, Kareem Gan  wrote:
>>>
>>> So it's not possible? It would be really helpful if someone here has 
>>> done it already and share the knowledge how.
>>>
>>> On Thursday, October 20, 2016 at 12:35:10 PM UTC-5, Pietro Gagliardi 
>>> (andlabs) wrote:

 You can go get golang.org/x/tools/cmd/godoc and run the godoc tool 
 itself, which will imitate golang.org. This is different from godoc.org; 
 that is harder to host locally.

 On Oct 20, 2016, at 1:13 PM, Kareem Gan  wrote:

 Hello.

 Is it possible to host godoc internally because we have our own git 
 server and would like to host godoc internally so we can build 
 documentation for our golang repositories.
 -- 
 Best,

 Kareem Gan
 01010011 01000101

 -- 
 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...@googlegroups.com.
>>>
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> -- 
>> Best,
>>
>> Kareem Gan
>> 01010011 01000101
>>
>

-- 
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 can I pass the parameter to a Http handler function

[rugwirobaker]

This thread saved me many hours of my life.

-- 
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] proposal: advise using SetFinalizer to detect resource leaks

[Mateusz Czaplinski]

I replied on the issue; in short, if the proposal gets dismissed, I'll take
my chances at creating a third-party package with some super simple API,
and then try advertising it here, on reddit, and maybe to other packages.

On Thu, Apr 5, 2018 at 2:14 PM, Axel Wagner 
wrote:

> Of course this happens when you don't test your code ^^ Here is a version
> without compilation errors and with a quick demo: https://play.golang.org/
> p/ykO4igrC0b1
>
> On Thu, Apr 5, 2018 at 2:06 PM, Axel Wagner  > wrote:
>
>> On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski 
>> wrote:
>>
>>> Reading from it and handling the errors is left to user.
>>>
>>
>> Then why would this need to live in the stdlib? For example here is a
>> quick and dirty implementation that allows the same functionality, without
>> having to modify the stdlib:
>> https://play.golang.org/p/_TsQQUhs8Ik
>> This could be provided as a normal package and people can use it to
>> augment any io.Closer (and, really, by extension anything) with this
>> functionality.
>>
>>
>>> There are many possible ways to handle it, so it's hard to guess in the
>>> finalizer what user wants:
>>>   a) print them on stderr
>>>   b) push them to some logging infrastructure
>>>   c) just plain ignore them (default behavior)
>>> User may not want or expect to have stderr trashed by some messages from
>>> libraries. Passing the errors through a common channel can help opt-in to
>>> the feature.
>>>
>>> On Thu, Apr 5, 2018 at 1:55 PM, Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
 What would the runtime.Leaks channel do with the received errors? Why
 can't you just do the same thing from the finalizer itself?

 On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński  wrote:

> Based on a recent discussion on reddit, and a reply by BowsersaurusRex:
>
> "In C# I'll often use finalizers to track bugs in which an object
> was GC'd but Close() was never called."
>
> I submitted the following proposal:
>
> https://golang.org/issue/24696
>
> I'd love to see a solution which would not require adding to package
> runtime, but as of now I don't see how it could be possible — esp. if
> stdlib packages were to use it.
>
> I'm curious what are your thoughts on whether this would be a good
> idea? Do you see some problems with that? Do you think it could be done
> outside standard library?
>
> /Mateusz.
>
> --
> 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] proposal: advise using SetFinalizer to detect resource leaks

['Axel Wagner' via golang-nuts]

Of course this happens when you don't test your code ^^ Here is a version
without compilation errors and with a quick demo:
https://play.golang.org/p/ykO4igrC0b1

On Thu, Apr 5, 2018 at 2:06 PM, Axel Wagner 
wrote:

> On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski 
> wrote:
>
>> Reading from it and handling the errors is left to user.
>>
>
> Then why would this need to live in the stdlib? For example here is a
> quick and dirty implementation that allows the same functionality, without
> having to modify the stdlib:
> https://play.golang.org/p/_TsQQUhs8Ik
> This could be provided as a normal package and people can use it to
> augment any io.Closer (and, really, by extension anything) with this
> functionality.
>
>
>> There are many possible ways to handle it, so it's hard to guess in the
>> finalizer what user wants:
>>   a) print them on stderr
>>   b) push them to some logging infrastructure
>>   c) just plain ignore them (default behavior)
>> User may not want or expect to have stderr trashed by some messages from
>> libraries. Passing the errors through a common channel can help opt-in to
>> the feature.
>>
>> On Thu, Apr 5, 2018 at 1:55 PM, Axel Wagner <
>> axel.wagner...@googlemail.com> wrote:
>>
>>> What would the runtime.Leaks channel do with the received errors? Why
>>> can't you just do the same thing from the finalizer itself?
>>>
>>> On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński 
>>> wrote:
>>>
 Based on a recent discussion on reddit, and a reply by BowsersaurusRex:

 "In C# I'll often use finalizers to track bugs in which an object
 was GC'd but Close() was never called."

 I submitted the following proposal:

 https://golang.org/issue/24696

 I'd love to see a solution which would not require adding to package
 runtime, but as of now I don't see how it could be possible — esp. if
 stdlib packages were to use it.

 I'm curious what are your thoughts on whether this would be a good
 idea? Do you see some problems with that? Do you think it could be done
 outside standard library?

 /Mateusz.

 --
 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] proposal: advise using SetFinalizer to detect resource leaks

['Axel Wagner' via golang-nuts]

On Thu, Apr 5, 2018 at 1:58 PM, Mateusz Czaplinski 
wrote:

> Reading from it and handling the errors is left to user.
>

Then why would this need to live in the stdlib? For example here is a quick
and dirty implementation that allows the same functionality, without having
to modify the stdlib:
https://play.golang.org/p/_TsQQUhs8Ik
This could be provided as a normal package and people can use it to augment
any io.Closer (and, really, by extension anything) with this functionality.


> There are many possible ways to handle it, so it's hard to guess in the
> finalizer what user wants:
>   a) print them on stderr
>   b) push them to some logging infrastructure
>   c) just plain ignore them (default behavior)
> User may not want or expect to have stderr trashed by some messages from
> libraries. Passing the errors through a common channel can help opt-in to
> the feature.
>
> On Thu, Apr 5, 2018 at 1:55 PM, Axel Wagner  > wrote:
>
>> What would the runtime.Leaks channel do with the received errors? Why
>> can't you just do the same thing from the finalizer itself?
>>
>> On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński 
>> wrote:
>>
>>> Based on a recent discussion on reddit, and a reply by BowsersaurusRex:
>>>
>>> "In C# I'll often use finalizers to track bugs in which an object
>>> was GC'd but Close() was never called."
>>>
>>> I submitted the following proposal:
>>>
>>> https://golang.org/issue/24696
>>>
>>> I'd love to see a solution which would not require adding to package
>>> runtime, but as of now I don't see how it could be possible — esp. if
>>> stdlib packages were to use it.
>>>
>>> I'm curious what are your thoughts on whether this would be a good idea?
>>> Do you see some problems with that? Do you think it could be done outside
>>> standard library?
>>>
>>> /Mateusz.
>>>
>>> --
>>> 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] proposal: advise using SetFinalizer to detect resource leaks

[Mateusz Czaplinski]

Reading from it and handling the errors is left to user. There are many
possible ways to handle it, so it's hard to guess in the finalizer what
user wants:
  a) print them on stderr
  b) push them to some logging infrastructure
  c) just plain ignore them (default behavior)
User may not want or expect to have stderr trashed by some messages from
libraries. Passing the errors through a common channel can help opt-in to
the feature.

On Thu, Apr 5, 2018 at 1:55 PM, Axel Wagner 
wrote:

> What would the runtime.Leaks channel do with the received errors? Why
> can't you just do the same thing from the finalizer itself?
>
> On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński 
> wrote:
>
>> Based on a recent discussion on reddit, and a reply by BowsersaurusRex:
>>
>> "In C# I'll often use finalizers to track bugs in which an object was
>> GC'd but Close() was never called."
>>
>> I submitted the following proposal:
>>
>> https://golang.org/issue/24696
>>
>> I'd love to see a solution which would not require adding to package
>> runtime, but as of now I don't see how it could be possible — esp. if
>> stdlib packages were to use it.
>>
>> I'm curious what are your thoughts on whether this would be a good idea?
>> Do you see some problems with that? Do you think it could be done outside
>> standard library?
>>
>> /Mateusz.
>>
>> --
>> 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] proposal: advise using SetFinalizer to detect resource leaks

['Axel Wagner' via golang-nuts]

What would the runtime.Leaks channel do with the received errors? Why can't
you just do the same thing from the finalizer itself?

On Thu, Apr 5, 2018 at 1:43 PM, Mateusz Czapliński 
wrote:

> Based on a recent discussion on reddit, and a reply by BowsersaurusRex:
>
> "In C# I'll often use finalizers to track bugs in which an object was
> GC'd but Close() was never called."
>
> I submitted the following proposal:
>
> https://golang.org/issue/24696
>
> I'd love to see a solution which would not require adding to package
> runtime, but as of now I don't see how it could be possible — esp. if
> stdlib packages were to use it.
>
> I'm curious what are your thoughts on whether this would be a good idea?
> Do you see some problems with that? Do you think it could be done outside
> standard library?
>
> /Mateusz.
>
> --
> 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] Re: Is there a memory leak on Rob Pike's demo codes?

[Jan Mercl]

On Thu, Apr 5, 2018 at 9:10 AM T L  wrote:

> yes. it is a resource leak.

It's not necessarily a leak. It's a possible leak.

And digging even deeper: it's implementation defined. Non-reachable
channels can be collected and goroutines blocked on them killed without
changing the semantics of the program.
-- 

-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: Is there a memory leak on Rob Pike's demo codes?

[T L]

On Wednesday, April 4, 2018 at 11:32:10 AM UTC-4, wilby yang wrote:
>
> I am new to golang and I am not sure if it is a stupid question. I am 
> reading the slides of Rob Pike on go concurrency patterns in 2012. I 
> think there is a resource leak in the below function. As the function will 
> return after the first send pair happens on channel c, the other 
> goroutines trying to send on channel c will be blocked and prevents 
> resources GC. Anyone knows golang well can confirm this? If it is resource 
> leak, how can I detect it using what kind of golang tooling?
>

yes. it is a resource leak.
 

> down votefavorite 
> 
>
> func First(query string, replicas ...Search) Result {
>   c := make(chan Result)
>   searchReplica := func(i int) {
> c <- replicas[i](query)
>   }
>   for i := range replicas {
> go searchReplica(i)
>   }
>   return <-c}
>
>

-- 
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 1.8 or higher on Solaris sparc64.

[Aram Hăvărneanu]

The solaris/sparc64 Go port project has been discontinued until further notice.

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