https://www.techempower.com/benchmarks/#section=data-r15=ph=json
>
>
--
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.
> Is it practical to auto rearrange struct fields to reduce paddings in Go?
Auto rearrange? Probably not. Manual rearrange? Maybe, if the struct isn't
part of a public API. If the struct is part of a private API removing the
padding could be counterproductive or harmful to performance if the
.
--
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.
On Wed, 6 Feb 2019 12:30:51 -0800
Tharaneedharan Vilwanathan wrote:
> Somehow I was dreaming I can use Go for frontend too, instead of JS. Is my
> thinking right?
It is wrong, in my opinion. Just use a right tool for a task.
If you do want go-like experience for browser frontend I'd suggest
What you are seeing here is an edge case caused by the fact that the first
NewRequest wraps your strings.Reader into a ioutil.NopCloser. When
NewRequest is called the second time, the type switch no longer matches a
type for which the length is known, so ContentLength is left to 0, which
No need to learn JS if you learn Typescript. Straight JS is pretty dead except
for older codebases or trivial applications.
> On Feb 6, 2019, at 5:54 PM, Manlio Perillo wrote:
>
> On Wednesday, February 6, 2019 at 9:07:16 PM UTC+1, Tharaneedharan
> Vilwanathan wrote:
>
> I have one more
The reason it checks for known implementations is because it “knows the
implementation”, so it can be sure it has the correct semantics.
This is the problem with Go “duck typing”.
The real solution would be to declare a new interface called BodyContent, that
had methods of io.Reader, and a
On Wednesday, February 6, 2019 at 9:07:16 PM UTC+1, Tharaneedharan
Vilwanathan wrote:
>
>
> I have one more question. Has anyone used WASM in Go for something more
> than small examples I managed to see and got them working?
>
> It was challenging to get it working and then I wasn't sure how it
To answer the OP, wasm support is in 1.12 and is still experimental. There
have been some changes to the wasm support but nothing major. (See the
syscall/js section of https://tip.golang.org/doc/go1.12 for details.)
On Wednesday, February 6, 2019 at 2:27:53 PM UTC-8, Tharaneedharan
Vilwanathan
'⌘' is of type rune (aka int32), "⌘" and `⌘` are of type string, both
takes more than 3 bytes.
--
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
Hello,
I'd be grateful if someone could please explain why you would use
r := '⌘'
Instead of
s := "⌘" / s:= `⌘`
All use three bytes ...?
Thank you,
Jamie.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
On Wed, Feb 6, 2019 at 2:50 PM robert engels wrote:
>
> I am not sure what that has to do with the discussion. My point was that for
> it to be applicable here, it needs to be defined as part of io.Reader, since
> that is what Body is declared as. It is not, so using in the manner outlined
>
I am also not sure about gopherjs performance if using lots of idiomatic Go
(i.e. go routines). It is very difficult to get good performance when the
underlying platform expects async callbacks, and Go is “blocking”. There is
going to be a lot of stack-unwinding… I am sure somebody has run
I am not sure what that has to do with the discussion. My point was that for it
to be applicable here, it needs to be defined as part of io.Reader, since that
is what Body is declared as. It is not, so using in the manner outlined is not
correct IMO.
> On Feb 6, 2019, at 3:37 PM, Dan Kortschak
The generalised semantics of Len are that it returns the number of
available elements in the collection, being a cognate of the len built-
in. This means that as you consume elements from a buffer, the Len
value reduces. This is directly equivalent to
for len(buf) != 0 {
println(buf[0])
Quoting Tharaneedharan Vilwanathan (2019-02-06 15:30:51)
>Somehow I was dreaming I can use Go for frontend too, instead of JS. Is
>my thinking right?
If that's your interest use gopherjs instead:
https://github.com/gopherjs/gopherjs
It's been around a long time and is pretty
I have used gopherjs for some small projects; it's pretty nice and lets you
'think in Go' yet still access the DOM pretty easily.
I am no JS expert, so using it let me sidestep some of the ugliness there.
It definitely made doing async stuff nicer, using goroutines instead of
lots of
Somehow I was dreaming I can use Go for frontend too, instead of JS. Is my
thinking right?
Regards
dharani
On Wed, Feb 6, 2019 at 12:26 PM Robert Engels wrote:
> Just mo wasm is horrible on any platform. Unless you maybe have a
> large game engine that you are attempting to integrate.
>
>
Just mo wasm is horrible on any platform. Unless you maybe have a large
game engine that you are attempting to integrate.
You have to ask yourself, what are you trying to do? If it is just to avoid the
garbage that is JS, then use an environment that transpiles to JS. You’ll have
better
I have one more question. Has anyone used WASM in Go for something more
than small examples I managed to see and got them working?
It was challenging to get it working and then I wasn't sure how it is used
and how to use it for any bigger projects.
Please share your thoughts.
Regards
dharani
while webassembly was considered experimental in go 1.11 is it
planned in go 1.12 release later this month? If so will it's inclusion be
considered non-experimental ?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
For me, my C code is very micro-efficient so it generally runs faster than
Go, but it takes me up to 4 to 5 times longer to write things in C than it
does to write things in Go. If the resulting Go code is not fast enough, I
have three solutions:
1. Run the profiler to find the bottleneck,
The issue with doing it that way is that you are going to encode to json,
decode to object, filter fields, then encode back to json - not very efficient.
You are better to write your own middleware that takes the object response, and
encodes the selected fields, then writes to the
Hi,
I'm learning Go and start a Restful TO-DO app project for practicing. In
the process, I would like to add the Field Selector. I had searching on
google last few hours for a way to intercept the response and strip out the
unnecessary parts. I tried out some of them which either doesn't work
There is no Len() defined for io.Reader. That is the crux of the issue. You are
defining it because you need it. It needs to be defined and documented by the
api specification, otherwise it is an incorrect assumption and usage - aka
brittle code.
> On Feb 6, 2019, at 9:05 AM, Burak Serdar
On Wed, Feb 6, 2019 at 7:56 AM Robert Engels wrote:
>
> But is it really? If you read the description for Len() on bytes.Buffer it is
> the length of unread portion. But that doesn’t mean the buffer isn’t just a
> portion of the entire body - it can be a chunk which is continually reloaded.
But is it really? If you read the description for Len() on bytes.Buffer it is
the length of unread portion. But that doesn’t mean the buffer isn’t just a
portion of the entire body - it can be a chunk which is continually reloaded.
This is the danger in using private APIs publically based upon
On Wed, Feb 6, 2019 at 5:15 AM Robert Engels wrote:
>
> I see now, but if that can be the case, shouldn’t the Body be documented that
> the Reader may be a ReaderWithLen, and the consumer is free to type
> check/cast? If not, you are using internal details that you should not be.
Yes, the
I see now, but if that can be the case, shouldn’t the Body be documented that
the Reader may be a ReaderWithLen, and the consumer is free to type check/cast?
If not, you are using internal details that you should not be.
This is a problem with Go in general. Because the returned object
Make sense, thanks for explanation
Il giorno mercoledì 6 febbraio 2019 07:28:54 UTC+1, Burak Serdar ha scritto:
>
> On Tue, Feb 5, 2019 at 8:13 PM robert engels > wrote:
> >
> > That’s what I was trying to point out. Your design is not correct. The
> Body is a Reader, not a Buffer - the
30 matches
Mail list logo
