[go-nuts] Re: A question troubled me for a long time (about slice and map)

(Just as an aside: please don't post screenshot images. Plaintext is easier to read and can be copy-pasted. You can also use https://go.dev/play/ to paste code snippets) I think you have understood the issue well. From the source code at https://golang.org/src/runtime/slice.go : type slice s

[go-nuts] Re: A Question about `unsafe.Slice`

I found the comments of `findObject` in the runtime source: ```go // findObject returns the base address for the heap object **containing** // the address p, the object's span, and the index of the object in s. // If p does not point into a heap object, it returns base == 0. // // If p points is a

[go-nuts] Re: A Question about `unsafe.Slice`

It suddenly occurred to me that it was very like `re-slice` —— as long as part of the underlying array is referenced, the whole underlying array is never gc-ed. I guess there is a method in gc which could locate the whole underlying array as long as one address inside the array's address interva

[go-nuts] Re: A question about Type Sets

Great to see you playing with generics. I'll leave it up to the experts to reply about whether the compilation problems are bugs. But I have a suggestion: don't try to define Vec in an interface with a type set. Just use T[] -- looks like it might simplify things. Scott On Tuesday, August 2

[go-nuts] Re: A question about go bug template

GOROOT is in fact set separately for ~/sdk/go1.12.17 (by the wrapper in GOBIN/go1.12.17), but in the end the go command used should be the same. Thanks. Il giorno sabato 24 aprile 2021 alle 13:22:03 UTC+2 seank...@gmail.com ha scritto: > 1 for consistency in the report template (helps triagers

[go-nuts] Re: A question about go bug template

1 for consistency in the report template (helps triagers) 2 GOROOT may actually be set separately On Saturday, April 24, 2021 at 9:34:17 AM UTC+2 manlio@gmail.com wrote: > In the go bug template, go version is printed twice, the first time in > the "go version" section and the second time i

Re: [go-nuts] Re: A question !

Thank you guys for your help, But do to lake of learning resources for golang , i decided flto go for node.js in my startup project , thank you all On Tue, 7 Jan 2020, 5:25 pm Amnon Baron Cohen, wrote: > > > On Tuesday, 7 January 2020 09:44:28 UTC, Motaz Hejaze wrote: >> >> >> May i ask what is

Re: [go-nuts] Re: A question !

On Tuesday, 7 January 2020 09:44:28 UTC, Motaz Hejaze wrote: > > > May i ask what is the best deployment for more performance ?? > >> >> Do whatever is easiest. If you have come from the Python/Django world then you will be blown away by Go's speed, whatever deployment you use. I would also use

Re: [go-nuts] Re: A question !

On Jan 7, 2020, at 04:44, Motaz Hejaze wrote: > >  > Thank you all guys for your help.. > > May i ask what is the best deployment for more performance ?? I’m not quite sure what you mean. Do you mean what environment results in the highest-performing Go programs? I’d imagine the s390x archite

Re: [go-nuts] Re: A question !

Thank you all guys for your help.. May i ask what is the best deployment for more performance ?? On Mon, 6 Jan 2020, 10:56 am , wrote: > 2 - What is the fastest resource to learn Golang ( efficiently ) >> > > For me the best thing was Effective Go > https://golang.org/doc/effective_go.html > He

[go-nuts] Re: A question !

> > 2 - What is the fastest resource to learn Golang ( efficiently ) > For me the best thing was Effective Go https://golang.org/doc/effective_go.html Helps to understand "the go way"of coding and the main characteristics of the language -- You received this message because you are subscribe

[go-nuts] Re: A question !

Another advantage is that a single compiled binary is easy to deploy - without needing to set up a virtualenv, install dependent libraries, having to deal with different versions of python etc. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: A question !

Welcome Motaz! This might be slightly OT from your question, but one big benefit of Go over Python for production code is that go is statically typed, and strongly typed. This may feel like a shackle at first, but it eliminates a whole universe of bugs, the kind that can strike without warning

[go-nuts] Re: A question !

> 1 - Is there really a big performance ( speed ) difference between using Python OR Golang in backend web development ? Python suffers from poor performance, so moving to Go should give you a speedup of well over an order of magnitude. (See https://www.techempower.com/benchmarks/ for example

Re: [go-nuts] Re: A question !

Once you have little hands-on, https://medium.com/golangspec is a great place to read. On Sun, Jan 5, 2020 at 9:29 AM Michael Ellis wrote: > I came to Go from 10+ years of Python (and 20 years of C before that). Go > By Example was the online resource I found > most

[go-nuts] Re: A question !

I came to Go from 10+ years of Python (and 20 years of C before that). Go By Example was the online resource I found most useful in first few weeks of learning the language. I also highly recommend getting a copy of The Go Programming Language

[go-nuts] Re: A question !

On Sunday, January 5, 2020 at 7:28:24 AM UTC+13, Motaz Hejaze wrote: > > > 1 - Is there really a big performance ( speed ) difference between using > Python OR Golang in backend web development ? > There are a number of reasons why Go *could* out-perform Python when comparing django to a Go w

[go-nuts] Re: A question about performance when traverse the array with row-wise and column-wise

Are your test results different when rowSize = colSize> 1000 say ?? On Sunday, September 29, 2019 at 10:18:15 AM UTC-4, zct wrote: > > The test code is below: > package main > > import ( > "testing" > ) > > const rowSize = 100 > const colSize = 100 > > var array [rowSize][colSize]int >

Re: [go-nuts] Re: A question about A sync.Once implementation.

Hi, You are right, I did some modification to your code and make it able to reproduce everytime: https://play.golang.org/p/y6vxC_DNjp9 Thanks! 在 2019年5月8日星期三 UTC+8下午7:15:26，rog写道： > > It seems clear to me that C ("can run but has not implemented the > singleton pattern, function f may r

Re: [go-nuts] Re: A question about A sync.Once implementation.

It seems clear to me that C ("can run but has not implemented the singleton pattern, function f may run multi times") is not the correct answer, because I'm pretty sure that f cannot run more than once. However, it's still not a correct Once implementation, because as has already been pointed out,

Re: [go-nuts] Re: A question about A sync.Once implementation.

On Tue, May 7, 2019 at 9:42 PM White Pure wrote: > Hi, > Thanks for your reply. > The second bug is a known issue, so let’s ignore that. In that case, I > think function f still can only be executed once. > But why does the load and store of o.done need to be done using atomic > opera

[go-nuts] Re: A question about A sync.Once implementation.

Hi, Thanks for your reply. The second bug is a known issue, so let’s ignore that. In that case, I think function f still can only be executed once. But why does the load and store of o.done need to be done using atomic operations? I suppose there’s mutex assuring the happens-before.

[go-nuts] Re: A question about A sync.Once implementation.

Hi, Thanks for your reply. The second bug is a known issue, so let’s ignore that. In that case, I think function f still can only be executed once. But why does the load and store of o.done need to be done using atomic operations? I suppose there’s mutex assuring the happens-before.

[go-nuts] Re: A question about A sync.Once implementation.

Hello, The code contains two bugs. 1) The load and store of o.done needs to be done using atomic stores. 2) The statement to set o.done = 1 needs to be after the call to f. Otherwise, another goroutine can hit the check at the top of Done and return before the code in f has completed. On

[go-nuts] Re: A question about reading of TCP sockets.

1516, haha, are you writing a RTMP handshake? The io.Reader is not promise always get the size data, you can use io.CopyN or ReadBuffer. For io.Writer of netFD, it always write all the data. On Saturday, May 20, 2017 at 11:01:44 PM UTC+8, fusi.enr...@gmail.com wrote: > > Hello All > > first I apo

[go-nuts] Re: A question about the atomic operations in golang

Unless you're using a 64bit atomic on a 32 bit platform, there is nothing to worry about. -- 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..

Re: [go-nuts] Re: A question about the atomic operations in golang

The only guarantees made in regards to alignment are the ones outlined here: https://golang.org/ref/spec#Size_and_alignment_guarantees >From what I can tell, there is no such guarantee. But why do you care, specifically? Using the sync/atomic package will handle this correctly in every case. This r

[go-nuts] Re: A question about the atomic operations in golang

Thanks for your caution. Then is there a way to know that a certain variable is aligned properly? Will the compiler make the global variable `var p *int` in my sample code aligned properly? 在 2017年1月9日星期一 UTC+8上午3:17:37，Dave Cheney写道： > > What you are talking about is called a torn write, which

Re: [go-nuts] Re: A question about the atomic operations in golang

The answer (like with virtually all questions like this on golang-nuts) is: Possibly, but you can not rely on it. Assuming that it is might break your program now or at a non-specific future date or on a non-specific current or future processor. If you need atomic operations, please use the sync/a

[go-nuts] Re: A question about the atomic operations in golang

Yes, I think you are right about the case in my sample code. The code doesn't show exactly what I'm concerned about. I just wanna know whether a write to a global pointer in 64-bit machine an atomic operation or not. 在 2017年1月9日星期一 UTC+8上午6:22:12，Caleb Doxsey写道： > > Shouldn't this particular cas

[go-nuts] Re: A question about the atomic operations in golang

Shouldn't this particular case be ok? From the memory doc: https://golang.org/ref/mem The go statement that starts a new goroutine happens before the goroutine's > execution begins. So the write has to happen before the goroutine starts. At least that's what the example indicates: > For ex

Re: [go-nuts] Re: A question, simple for go team

On Sat, Oct 22, 2016 at 6:40 PM, T L wrote: > > On Saturday, October 22, 2016 at 11:59:55 PM UTC+8, Ian Lance Taylor wrote: >> >> On Sat, Oct 22, 2016 at 2:01 AM, T L wrote: >> > >> > On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: >> >> >> >> >> >> The string struct used internally

Re: [go-nuts] Re: A question, simple for go team

On Saturday, October 22, 2016 at 11:59:55 PM UTC+8, Ian Lance Taylor wrote: > > On Sat, Oct 22, 2016 at 2:01 AM, T L > > wrote: > > > > On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: > >> > >> > >> The string struct used internally is > >> > >> type stringStruct struct { >

Re: [go-nuts] Re: A question, simple for go team

DIscounting even garbage collector: is there any memory allocator anywhere that provides a facility to only return bytes at the start of an allocation to the manager? realloc() only lets you return bytes at the end, and most other allocators I've seen are based on that one's API... > On Oct 22,

Re: [go-nuts] Re: A question, simple for go team

On Sat, Oct 22, 2016 at 2:01 AM, T L wrote: > > On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: >> >> >> The string struct used internally is >> >> type stringStruct struct { >> str unsafe.Pointer >> len int >> } >> >> When following f function is called and s is cleared, >>

Re: [go-nuts] Re: A question, simple for go team

On Sat, Oct 22, 2016 at 11:02 AM T L wrote: > I mean how do go runtime knows "abcdefg" instead of "cde" should be released. It's a simple case of some programming ;-) (More here: https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) -- -j -- You received this message because

[go-nuts] Re: A question, simple for go team

On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: > > > The string struct used internally is > > type stringStruct struct { > str unsafe.Pointer > len int > } > > When following f function is called and s is cleared, > how do go runtime knows the starting memory address of th