Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Michael Jones]

When he writes "you expect a good, optimizing compiler to..." he is
implicitly stating that he wants more  than good optimizing compilation, he
wants (understandably, but let's be explicit) iterated compile-time
evaluation -- he wants fun() to be an integer value of 60.

It is true that the gc Go compiler lacks this. I like it as a feature, it
is like invoking "reduce()" in a symbolic algebra system. I hinted at it a
while back by asking if Go should notice when a function returns a pure
value and do substitutions -- clearly "x := math.Sqrt(4)" suggests "x :=
2.0" or "const x = 2.0" depending on context. But this is a non-trivial
step from compilation in the direction of metaprogramming via
Turing-complete macro processors. It will make the compiler bigger and
slower, and intellectually larger.

It is an open issue decision wise, and a great deal of work implementation
wise.

On Thu, Jun 4, 2020 at 1:20 PM Andy Balholm  wrote:

> I think by “at compile time” he means at JIT time (when converting
> bytecode to machine language).
>
> Andy
>
>
>
> On Jun 4, 2020, at 1:02 PM, Robert Engels  wrote:
>
> The author either doesn’t know Java or had significant editing errors -
> Java determines uses the runtime processor type to optimize - it is not
> done at compiler time. It has different implementations based on processor
> - like Go - and it does JIT optimizations based on processor as well.
>
> More importantly, these micro benchmarks with fractions of a percent are
> meaningless. All powerful systems are distributed to scale, not micro
> optimized.
>
>
>
> On Jun 4, 2020, at 2:34 PM, Igor Yemelianov  wrote:
>
> 
> Link
>  to
> the article.
>
> The question is - is it possible that the issues described in the article
> can be solved in for example next major version?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7aef8f47-8834-4cd3-9ba0-67e51728a110o%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAD4A4F7-0C56-430F-AF54-86993C704655%40gmail.com
> 
> .
>


-- 

*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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQyKs8WQHx01pDOLoOM0PkPtua%2Bbcg%3DnxnEx%3DjidbnWVjA%40mail.gmail.com.

[go-nuts] Re: SSL socket listener

[Manlio Perillo]

See https://golang.org/pkg/crypto/tls/#Conn about how to make a secure 
network connection.  There is an example for the Dial function.
For the normal network API see https://golang.org/pkg/net/

Manlio

Il giorno mercoledì 3 giugno 2020 alle 09:20:12 UTC+2 Wesley Peng ha 
scritto:

> Hello, 
>
> How do I program with SSL to make a server listen on specific port which 
> accepts SSL transfer only?
>
> Is there any guide for this since I have no experience on SSL socket 
> programming.
>
> Thanks.
>
> Wesley Peng
> wesleyp...@aol.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3b5abce7-a7e5-4e64-b95f-d734bdfe4e45n%40googlegroups.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Andy Balholm]

I think by “at compile time” he means at JIT time (when converting bytecode to 
machine language).

Andy



> On Jun 4, 2020, at 1:02 PM, Robert Engels  wrote:
> 
> The author either doesn’t know Java or had significant editing errors - Java 
> determines uses the runtime processor type to optimize - it is not done at 
> compiler time. It has different implementations based on processor - like Go 
> - and it does JIT optimizations based on processor as well. 
> 
> More importantly, these micro benchmarks with fractions of a percent are 
> meaningless. All powerful systems are distributed to scale, not micro 
> optimized. 
> 
> 
> 
>> On Jun 4, 2020, at 2:34 PM, Igor Yemelianov  wrote:
>> 
>> 
>> Link 
>>  to 
>> the article.
>> 
>> The question is - is it possible that the issues described in the article 
>> can be solved in for example next major version?
>> 
>> Thanks.
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7aef8f47-8834-4cd3-9ba0-67e51728a110o%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAD4A4F7-0C56-430F-AF54-86993C704655%40gmail.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Robert Engels]

The author either doesn’t know Java or had significant editing errors - Java 
determines uses the runtime processor type to optimize - it is not done at 
compiler time. It has different implementations based on processor - like Go - 
and it does JIT optimizations based on processor as well. 

More importantly, these micro benchmarks with fractions of a percent are 
meaningless. All powerful systems are distributed to scale, not micro 
optimized. 



> On Jun 4, 2020, at 2:34 PM, Igor Yemelianov  wrote:
> 
> 
> Link to the article.
> 
> The question is - is it possible that the issues described in the article can 
> be solved in for example next major version?
> 
> Thanks.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7aef8f47-8834-4cd3-9ba0-67e51728a110o%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/01446EC6-44C7-4920-971F-4537BD404414%40ix.netcom.com.

Re: [go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Ian Lance Taylor]

On Thu, Jun 4, 2020 at 12:34 PM Igor Yemelianov  wrote:
>
> The question is - is it possible that the issues described in the article can 
> be solved in for example next major version?

Yes, it is possible.

As Go is an open source project, you or anyone can make that much more
likely to happen by doing the work and contributing the changes.

Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUAEZi2N1xG2L5b0oTjsXWpt1mwR17KUeoBekrUCpphhA%40mail.gmail.com.

Re: [go-nuts] x, err = some_func(); if err != nil { } seems awkward

[Ian Lance Taylor]

On Thu, Jun 4, 2020 at 8:43 AM  wrote:
>
> ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # 
> arbitrarily chosen

Besides what other people have said, it may be of interest to glance
through https://github.com/golang/go/issues?q=is%3Aissue+label%3Aerror-handling
.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWvoqfU6qFkGyaqsmCHU5hCXRkNKFpxd4DzGOUr4kZrhA%40mail.gmail.com.

[go-nuts] What Go devs think about issues described by Daniel Lemire in article "The Go compiler needs to be smarter"?

[Igor Yemelianov]

Link 
 to 
the article.

The question is - is it possible that the issues described in the article 
can be solved in for example next major version?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7aef8f47-8834-4cd3-9ba0-67e51728a110o%40googlegroups.com.

[go-nuts] Re: x, err = some_func(); if err != nil { } seems awkward

[Saied Seghatoleslami]

There is also the idea that an error is not necessarily an error in the 
sense that it is wrong but it is something that prevents the operation.  It 
could be that the far end is out of service or the network connection is 
down or the port is closed or the file permissions are set to what is not 
expected (once we missed a big revenue recognition opportunity at the end 
of the quarter because the file permissions were set to something we did 
not expect and we ran out of time during the maintenance window and had to 
back out the upgrade and wait for the next quarter).  In real life, they 
are real situations that must be handled.  Dave Cheney in his blog 
discusses this extensively.  In a way, thinking through the collection of 
events that prevent the happy path from proceeding must be thought through 
first.  

So, it pays to think of what could go wrong and handle it before anything 
else.

On Thursday, June 4, 2020 at 11:44:07 AM UTC-4, lgo...@gmail.com wrote:
>
> ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # 
> arbitrarily chosen
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b961c216-2fdd-45b3-837c-7933e8b89317o%40googlegroups.com.

Re: [go-nuts] x, err = some_func(); if err != nil { } seems awkward

[Michael Jones]

Before you get an avalanche of emails about "that is an old question,
discussed in design documentation, mailing lists, and extension discussions
over a decade", let me ask you to consider a concept that your comment
implies.

For that to work, it means that a function call either succeeds or fails.
If it succeeds, then that's that. If it fails, then something special
happens. Your "#" means "do this only if the function call failed." In that
case itmust be true that functions have a notion of success and failure,
that the cause of failure is invisibly returned and available as an extra
"and here's why it failed" return value, and, new language concepts are
required to access the value of the invisible return inside that "#{ ... }"
block.

There is good precedent for the S (success) and F (failure) outcomes of
function calls--SNOBOL has that.

For everything else though, it has generally considered more awkward than
the present situation. If you want to contribute along these lines, think
about how to make the access to the invisible error return value feel
natural. (maybe think about it before reading the hundreds of pages of
discussion that await you.

Michael

On Thu, Jun 4, 2020 at 8:43 AM  wrote:

> ?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol #
> arbitrarily chosen
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ea305494-c6ec-46f9-962d-9add01edc8bd%40googlegroups.com
> 
> .
>


-- 

*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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQygvQtsfKCmaYgDnwbv5tSqcp7Zuqdh0wHtJ0WqkeMYbg%40mail.gmail.com.

[go-nuts] Re: Assignment of pointer values in a struct...

[eric . brown]

When you need to differentiate between nil and and empty string (because 
whatever you're assigning to, a "" may be valid).  For lack of time (and 
going into detail myself), here's a write-up on a reason why:  
https://dhdersch.github.io/golang/2016/01/23/golang-when-to-use-string-pointers.html

Also, just mainly used *string as an example here.  Although I played with 
pprof and made sure the GC played with this properly, I just wanted to make 
sure I didn't overlook anything (causing memory leaks, etc.) and make sure 
it's 'acceptable practice' before I went that route.  To me, implementing 
lots of pointers in models for our APIs, it's easier for me to do this than 
declaring everything above in a variable when assigning.

On Thursday, June 4, 2020 at 9:11:12 AM UTC-5, Jake Montgomery wrote:
>
> Trig,
>
>  I'm very curious why you want to use a pointer to a string? Since strings 
> are immutable, and already are like "pointers" internally, I have rarely, 
> if ever, used *string in go. What is it that you achieve by doing this?
>
> - Jake
>
> On Wednesday, June 3, 2020 at 10:33:31 PM UTC-4, Trig wrote:
>>
>> I posted this question the other day and don't see it (may have posted 
>> from another gmail account and it's still pending approval)... so here I am 
>> again.
>>
>> Let's say I have something like below:
>> type (
>>Person struct {
>>   FirstName *string
>>}
>> )
>>
>> Usually, I see something like the following when assigning:
>> fn := "John"
>> _ = Person{
>>   FirstName: ,
>> }
>>
>> Would something like the following be alright and acceptable practice:
>> _ = Person{
>>   FirstName: pString("John")
>> }
>>
>>
>> func pString(content string) *string {
>>return 
>> }
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ba77aff5-3a7a-43d0-b3bf-480c19efd576%40googlegroups.com.

[go-nuts] trouble parsing XML with embedded structs

[Lars R. Damerow]

Hello all,

I need to parse XML messages from a source I don't control. Each one has an 
envelope node that shows its source, and the first node in that envelope 
encodes the message type. I'm trying to compose structs to make it easier to do 
the parsing, and I put a stripped-down example for just one message type on the 
playground here:

https://play.golang.org/p/tszPHRM-mMO

What's puzzling me here is that, after unmarshaling, `v.Envelope.XMLName.Local` 
is empty. I'd expect it to contain "proto-alpha" from the example XML in the 
source; it does pick up the version attribute that's set on the envelope node, 
just not the `xml.Name` value.

Can anyone share some clues about what I'm doing wrong here?

Thanks very much,
-lars

-- 
lars r. damerow

https://keybase.io/ldamerow
F29F 160D B23C 3237 1BA3 FCD5 4E13 C775 36B3 ABCA

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c0585459-06af-4a37-9074-95e9d82df552%40www.fastmail.com.

[go-nuts] x, err = some_func(); if err != nil { } seems awkward

[lgodio2]

?? Why not a cleaner syntax e.g.  x = some_func ()  #{ }   .. symbol # 
arbitrarily chosen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ea305494-c6ec-46f9-962d-9add01edc8bd%40googlegroups.com.

Re: [go-nuts] Assignment of pointer values in a struct...

[Jan Mercl]

On Thu, Jun 4, 2020 at 5:13 PM Trig  wrote:
>
> And I did it again... posted from another gmail account by accident, and my 
> post is forever in 'approval status', lol.  Basically what Robert here said.
>
> On Thursday, June 4, 2020 at 9:53:56 AM UTC-5, Robert Engels wrote:
>>
>> You need pointers to strings if you need a nil value to be represented which 
>> is often the case in databases.

That's a very expensive way to represent a simple boolean value.

type String struct {
S string
Valid bool
}

is a value of the same size as a slice is, so passing it around has
the same cost with no additional allocations.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VNUAoMk5Fpy2FUgdAiT6e%3DNOYy-RA4T%3DOXkAXN4q9ufg%40mail.gmail.com.

Re: [go-nuts] Assignment of pointer values in a struct...

[Trig]

And I did it again... posted from another gmail account by accident, and my 
post is forever in 'approval status', lol.  Basically what Robert here said.

On Thursday, June 4, 2020 at 9:53:56 AM UTC-5, Robert Engels wrote:
>
> You need pointers to strings if you need a nil value to be represented 
> which is often the case in databases. 
>
> > On Jun 4, 2020, at 9:30 AM, Saksham Saxena  > wrote: 
> > 
> > Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at 
> many places where it takes a string as an argument and returns a pointer to 
> it which is required internally. Not really sure why use a pointer to 
> strings in Go because they're immutable, but I guess to reach their own. 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/17f2c250-ea5f-41fc-ac1b-0890a69f593b%40googlegroups.com.
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b52446c0-8750-4f58-818c-ab985962ca25%40googlegroups.com.

Re: [go-nuts] Assignment of pointer values in a struct...

[Robert Engels]

You need pointers to strings if you need a nil value to be represented which is 
often the case in databases. 

> On Jun 4, 2020, at 9:30 AM, Saksham Saxena  wrote:
> 
> Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at many 
> places where it takes a string as an argument and returns a pointer to it 
> which is required internally. Not really sure why use a pointer to strings in 
> Go because they're immutable, but I guess to reach their own. 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/17f2c250-ea5f-41fc-ac1b-0890a69f593b%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D0E3E25A-A399-4CB4-809E-EC2216C782AE%40ix.netcom.com.

[go-nuts] Assignment of pointer values in a struct...

[Saksham Saxena]

Yep perfectly fine. MongoDB Driver for Go also uses such a wrapper at many 
places where it takes a string as an argument and returns a pointer to it which 
is required internally. Not really sure why use a pointer to strings in Go 
because they're immutable, but I guess to reach their own. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/17f2c250-ea5f-41fc-ac1b-0890a69f593b%40googlegroups.com.

[go-nuts] Re: Assignment of pointer values in a struct...

[Jake Montgomery]

Trig,

 I'm very curious why you want to use a pointer to a string? Since strings 
are immutable, and already are like "pointers" internally, I have rarely, 
if ever, used *string in go. What is it that you achieve by doing this?

- Jake

On Wednesday, June 3, 2020 at 10:33:31 PM UTC-4, Trig wrote:
>
> I posted this question the other day and don't see it (may have posted 
> from another gmail account and it's still pending approval)... so here I am 
> again.
>
> Let's say I have something like below:
> type (
>Person struct {
>   FirstName *string
>}
> )
>
> Usually, I see something like the following when assigning:
> fn := "John"
> _ = Person{
>   FirstName: ,
> }
>
> Would something like the following be alright and acceptable practice:
> _ = Person{
>   FirstName: pString("John")
> }
>
>
> func pString(content string) *string {
>return 
> }
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/37e1379c-9f03-4107-b7a2-375060d10cdb%40googlegroups.com.

Re: [go-nuts] SSL socket listener

[Brian Candler]

https://golang.org/pkg/crypto/tls/#example_LoadX509KeyPair
sets up a basic listener.  Once you have this, it's just like a normal 
socket accept. See
https://golang.org/pkg/net/#example_Listener
for how to accept connections and handle them in their own goroutines.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/08a3e63c-603f-4223-91b2-c2b84fe5cef7%40googlegroups.com.

Re: [go-nuts] SSL socket listener

['Wesley Peng' via golang-nuts]

Thanks. how about the sample of general socket listener with SSL rather 
than net/http implementation?


Regards

Dimas Prawira wrote:

Here is an example running server with TLS

package  main

import  (
 "net/http"
 "log"
)

func  HelloServer(w  http.ResponseWriter,req  *http.Request) {
 w.Header().Set("Content-Type","text/plain")
 w.Write([]byte("This is an example server.\n"))
}

func  main() {
 http.HandleFunc("/hello",HelloServer)
 err  :=  http.ListenAndServeTLS(":443","server.crt","server.key",nil)
 if  err  !=  nil  {
 log.Fatal("ListenAndServe: ",err)
 }
}



--
Wesley Peng
wesleyp...@aol.com

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ffdb0882-3e1a-173d-6c3c-91f63d88bbfe%40aol.com.