Re: [go-nuts] How do you mitigate against nil pointer dereference

It was easier than i expected https://play.golang.org/p/olooozwapD On Friday, 13 January 2017 19:00:14 UTC+1, Ian Davis wrote: > > > > > On Fri, 13 Jan 2017, at 05:17 PM, mail...@gmail.com wrote: > > > Hello, > > Ignoring the error does not help > > https://play.golang.org/p/a8AIcHWII6 > >

Re: [go-nuts] How do you mitigate against nil pointer dereference

It was easier than i expected https://play.golang.org/p/olooozwapD On Friday, 13 January 2017 19:13:16 UTC+1, mhh...@gmail.com wrote: > > yeah, right, it s possible and works, but its way more complex, lets > forget about this :) > > This works https://play.golang.org/p/hP8Zq-LfQA > > On

[go-nuts] Re: Disadvantage of Go

> Some time ago I collected a number of alternatives to using generics - see: https://appliedgo.net/generics None of these alternatives really solve any real problem generics would solve. Generics are types, just like first class functions. Lamenting on the lack on generics is useless as

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

> None of these alternatives really solve any real problem generics would solve. True, and the article does not mean to imply this. But often it would seem that there is no alternative to using generics for solving a given problem although there is one if you look close enough. Of course this

Re: [go-nuts] Re: should every .gz file be served with content-encoding gzip?

if you do so, it will be longer to download, it also put more pressure on the server as it needs to decompress the content as it serves it. Other side effects occurs such as the longer it is to serve a request the busier the server will be thus the more likely you are to hit the server capacity.

[go-nuts] Reading an .ini file

Rankest beginner here. Trying to learn Go by converting an old Visual Basic application to Go (yeah, right) on Windows 10 (got all the database stuff working with both postgre and sqlite!) The application needs to read an .ini file to get path/filename. It bombs on the first line. This is

[go-nuts] func return with if... else...

Using go, when I create a function with a return... and that function uses an if... else... condition w/ the return being passed under each, the compiler still throws an error 'missing return at end of function'? I can put a return at the end of the function, but it will never get to that

Re: [go-nuts] should every .gz file be served with content-encoding gzip?

1. It is unexpected. When I click a link that ends with .tar.gz, I expect to get a .tar.gz file. 2. It is a waste of disk space. Sure, as soon as they download the tarball, they will extract it. But they still need the space for both the tarball and the contents at the same time. So we might as

[go-nuts] should every .gz file be served with content-encoding gzip?

Say in my http fileserver, I have /static/foo.tar.gz. Should my fileserver be serving it as /static/foo.tarwith content-encoding: gzip always or should it be served as /static/foo.tar.gz with content-type: gzip? Change foo.tar.gz with any file that ends in .gz. My question boils down to whether

Re: [go-nuts] should every .gz file be served with content-encoding gzip?

It all depends on what the user wants to have when they are done downloading. In the case of HTML, CSS, and JS, they want an uncompressed file that is ready for their browser to use. So you should use Content-Encoding: gzip and Content-Type: text/html or whatever. In the case of a .tar.gz, they

Re: [go-nuts] Re: should every .gz file be served with content-encoding gzip?

While it is unexpected, what is wrong with just serving a tar file and redirecting a foo.gz request to a foo request? Why should a user want to have a .gz file after downloading? On Sat, Jan 14, 2017 at 1:38 PM wrote: > Say you have this foo.tar.gz, > served as /foo.tar.gz

[go-nuts] Re: func return with if... else...

Thank you... On Saturday, January 14, 2017 at 4:44:33 PM UTC-6, Dave Cheney wrote: > > The former. -- 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

[go-nuts] Re: func return with if... else...

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