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

[Eric Brown]

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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Dave Cheney]

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 https://groups.google.com/d/optout.

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

[Eric Brown]

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 
point because of this condition.  Is that expected, or could I be doing 
something different to prevent this outcome?  Not that it matters... but I 
hate just having random returns at the bottom of functions that don't do 
anything other than satisfy this issue.

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

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

[mhhcbon]

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.

Now if that really is what you want/need to do, 
technically speaking you can, 
have fun with it!

On Saturday, January 14, 2017 at 7:55:33 PM UTC+1, Anmol Sethi wrote:
>
> 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 with a content-encoding: gzip,
>> the browser would in fact decode the gzip stream and serve a tar file.
>>
>> I guess, it is unexpected, 
>> the content-encoding should probably be application/octet-stream 
>> to instruct the browser to download the file,
>> for correctness the content-type should be application/x-gzip
>>
>> Now lets say you are serving pre-compressed some.css.gz, 
>> you d better serve it as some.css,
>> when the request comes in,
>> check the accept-encoding header of the request,
>> - if it says gzip, set the response header content-encoding to gz,
>> read the gz file straight.
>> - if the accept header of the request says to not handle gzip,
>> serve an uncompressed version of this gz (maybe you read it straight form 
>> the file system too?).
>>
>> in both case, set the response content-type appropriately for the file 
>> type (in that case text/css, and certainly not application/x-gzip)
>>
>>
>> On Saturday, January 14, 2017 at 7:08:55 PM UTC+1, Anmol Sethi wrote:
>>>
>>> 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 or not every .gz file should be served with 
>>> content-encoding: 
>>> gzip? I know it's fine for html/css/js but I'm wondering if there are 
>>> some files, where i should be serving them with content-type: gzip? As 
>>> in, why not just always use content-encoding: gzip and strip off the 
>>> extension?
>>>
>> -- 
>> 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] should every .gz file be served with content-encoding gzip?

[Andy Balholm]

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 well let them conserve space if 
they want to.
3. Some programs don’t accept uncompressed .tar files; they require .tar.gz.

> On Jan 14, 2017, at 10:57 AM, Anmol Sethi  wrote:
> 
> 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:31 PM Andy Balholm  > wrote:
> 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 may be 
> expecting to find a tar.gz file in their downloads folder, so you should use 
> Content-Type: application/gzip (not just gzip).
> 
> But rather than trying to guess what the user wants, you can go by the 
> filename in the request. If the request specifies a filename ending in .gz, 
> use Content-Type: application/gzip; if your server is adding the .gz, use 
> Content-Encoding: gzip. (And check the Accept-Encoding header too.)
> 
> Andy

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

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

['Anmol Sethi' via golang-nuts]

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 with a content-encoding: gzip,
> the browser would in fact decode the gzip stream and serve a tar file.
>
> I guess, it is unexpected,
> the content-encoding should probably be application/octet-stream
> to instruct the browser to download the file,
> for correctness the content-type should be application/x-gzip
>
> Now lets say you are serving pre-compressed some.css.gz,
> you d better serve it as some.css,
> when the request comes in,
> check the accept-encoding header of the request,
> - if it says gzip, set the response header content-encoding to gz,
> read the gz file straight.
> - if the accept header of the request says to not handle gzip,
> serve an uncompressed version of this gz (maybe you read it straight form
> the file system too?).
>
> in both case, set the response content-type appropriately for the file
> type (in that case text/css, and certainly not application/x-gzip)
>
>
> On Saturday, January 14, 2017 at 7:08:55 PM UTC+1, Anmol Sethi wrote:
>
> 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 or not every .gz file should be served with content-encoding:
> gzip? I know it's fine for html/css/js but I'm wondering if there are
> some files, where i should be serving them with content-type: gzip? As
> in, why not just always use content-encoding: gzip and strip off the
> extension?
>
> --
> 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] should every .gz file be served with content-encoding gzip?

[Andy Balholm]

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 may be 
expecting to find a tar.gz file in their downloads folder, so you should use 
Content-Type: application/gzip (not just gzip).

But rather than trying to guess what the user wants, you can go by the filename 
in the request. If the request specifies a filename ending in .gz, use 
Content-Type: application/gzip; if your server is adding the .gz, use 
Content-Encoding: gzip. (And check the Accept-Encoding header too.)

Andy

-- 
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] should every .gz file be served with content-encoding gzip?

['Anmol Sethi' via golang-nuts]

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 or not every .gz file should be served with content-encoding: gzip?
I know it's fine for html/css/js but I'm wondering if there are some files,
where i should be serving them with content-type: gzip? As in, why not just
always use content-encoding: gzip and strip off the extension?

-- 
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] Reading an .ini file

[bucarr]

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 from my testing platform.  I like doing things in baby steps, 
please.

package main

import (
"fmt"

ini "github.com/vaughan0/go-ini"
)

func main() {
pathfilename := readINIfile()
fmt.Println(pathfilename)
}

func readINIfile() string {
_, err := ini.LoadFile("C:\\temp\\testfile.ini")
if err != nil {
fmt.Println(err)
}
   return ""
}

I can't get beyond the first err test.  The error returned is: "invalid INI 
syntax on line 1: ;blah".  It is choking on the ';blah'.  Also chokes on a 
blank line and on simply the ';' character.  The author's documentation 
says:

INI files are parsed by go-ini line-by-line. Each line may be one of the 
following:

   - A section definition: [section-name]
   - A property: key = value
   - A comment: #blahblah *or* ;blahblah
   - Blank. The line will be ignored.

I've stared at this for hours.  Any idea what I'm missing?

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

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

[Christoph Berger]

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

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

> It's not being blind to another solution, 

Sometimes it is.

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

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

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

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

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

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

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

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

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

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


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

https://www.youtube.com/watch?v=7YcLIbG1ekM=youtu.be=49m29s 


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



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

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

[mailteety]

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 Friday, January 13, 2017 at 6:42:25 PM UTC+1, mail...@gmail.com wrote:
>>
>>
>> Can you give example how this validation can be done via such interface ? 
>>
>> On Friday, 13 January 2017 18:27:51 UTC+1, mhh...@gmail.com wrote:
>>>
>>> you could also implment unmarshaler interface
>>>
>>> https://blog.gopheracademy.com/advent-2016/advanced-encoding-decoding/
>>>
>>>
>>>
>>> On Friday, January 13, 2017 at 6:18:01 PM UTC+1, mail...@gmail.com 
>>> wrote:


 Hello,

 Ignoring the error does not help 

 https://play.golang.org/p/a8AIcHWII6

 Thank you.


 On Friday, 13 January 2017 15:38:45 UTC+1, Ian Davis wrote:
>
> On Fri, 13 Jan 2017, at 10:12 AM, mail...@gmail.com wrote:
>
>
> Hello,
>
> Have been struggling with mitigating against nil pointer deference and 
> i would appreciate if anyone can help
>
> Code 1:   Works file 
> https://play.golang.org/p/lhOh9g5R9l
>
>
> Code 2: Error
> https://play.golang.org/p/pY4F9bK-D9
>
>
> In this case you must not ignore the error returned from 
> json.Unmarshal. If an error is returned then p will be nil.
>
>

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

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

[mailteety]

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
>
>
> You changed your code by making your JSON valid so this is now a different 
> problem to the one you originally asked. 
>
> You can take advantage of Go's ability to accept nil receivers to make 
> your code more robust:
>
> https://play.golang.org/p/dAhEqyi94U
>
>
>

-- 
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: Disadvantage of Go

[paraiso . marc]

>  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 well, Go will never have generics 
because of forward compatibility. 

But let's not pretend than there is an alternative to generics "people 
can't see" within Go. Go just wasn't built for code re-use in mind or 
writing abstractions at all due to the lack of polymorphism in the 
language. So people have to write specialized code when it comes to writing 
logic involving containers, that's the only truth there is.

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

It's not being blind to another solution, every other solution has 
drawbacks generics don't have. Code generation involve writing 
pre-processors and maintaining manifests, opting out of Go type system with 
interface{} everywhere is obviously problematic. That's not solving what 
generics are here for in languages such as Java C# or Haskell. Basically 
you are asking developers to pay a price the compiler doesn't want to pay. 
Let's not patronize people who see the obvious flaw in that logic.

Again while it is useless to complain, people are complaining for a good 
reason, it can be difficult to understand what led to the absence of 
generics at first place in Go design. People coming from 
C,Python,Javascript and Ruby might not care, people coming from Java, C# or 
Haskell will have harder time working around the lack of generics in Go 
because they are used to that feature to solve their problems. 

To the latter I'd say that if Go feels tedious for a task then use 
something else, really. Go wasn't designed to please people who like 
expressive static type systems. There are many alternatives such as D, 
Ocaml, ... 

Le samedi 14 janvier 2017 10:35:33 UTC+1, Christoph Berger a écrit :
>
> Hi Yu,
>
> Generics have their use cases, e.g. when designing general data containers 
> or in the context of numeric computation (matrix type of int, float, etc). 
> In other areas, however, their use may be overrated. 
>
> If you have a particular problem and you think, "I do need generics to 
> implement that!", then you might become blind for other solutions. 
>
> Some time ago I collected a number of alternatives to using generics - 
> see: https://appliedgo.net/generics
>
> Best,
> Christoph
>
>
> On Saturday, January 14, 2017 at 7:42:43 AM UTC+1, Yu Liu wrote:
>>
>> Agree.
>>
>> Only generics missing is disadvantage of Go.
>>
>> Yu
>>
>> On Friday, January 13, 2017 at 10:56:07 AM UTC-8, simon place wrote:
>>
>>> sorry but for me, excepting generics and maybe a float32 maths lib, 
>>> these are all just your problem.
>>>
>>> particularly wrong is the idea of native conversion of bools to/from 
>>> numbers, albeit widespread and long-standing, perpetuating these mistakes 
>>> just means preventing any development of languages.
>>>
>>

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