[go-nuts] Re: Aren't package declarations (and per file imports) redundant?

Hi Sunder, You can see the reasoning behind the package identifier in the language spec. Hope this helps! Damien On Saturday, March 18, 2017 at 7:49:57 AM UTC-4, Sunder Rajan Swaminathan wrote: > > Before anyone flames, I love Go! There. Ok, now to

[go-nuts] Re: Different latency inside and outside

Are you seeing the average response time / latency of the cache from outside? If so, you should see lots of really quick responeses, and a few ones as slow as inside that average to what you're seeing. --dave On Saturday, March 18, 2017 at 3:52:21 PM UTC-4, Alexander Petrovsky wrote: > >

[go-nuts] Different latency inside and outside

Hello! Colleagues, I need your help! And so, I have the application, that accept through http (fasthttp) dynamic json, unmarshal it to the map[string]interface{} using ffjson, after that some fields reads into struct, then using this struct I make some calculations, and then struct fields

[go-nuts] atomic bugs

At the end of sync/atomic package docs, it says On x86-32, the 64-bit functions use instructions unavailable before the Pentium MMX. On non-Linux ARM, the 64-bit functions use instructions unavailable before the ARMv6k core. So when running Go programs which call the 64-bit atomic

Re: [go-nuts] Does it make sense to make expensive syscalls from different goroutines?

суббота, 18 марта 2017 г., 14:37:11 UTC+3 пользователь Konstantin Khomoutov написал: > > On Sat, 18 Mar 2017 03:50:39 -0700 (PDT) > Vitaly Isaev wrote: > > [...] > > Assume that application does some heavy lifting with multiple file > > descriptors (e.g., opening -

Re: [go-nuts] Re: Go - language of the future!

wait. We should speak the same kind of comparisons. if we do a comparison to languages like haskell, idris, coq i m not sure we are targeting the hearth of the industry. They do not represent solarge% of code written code everyday that GO is made to replace. My understanding is that go would

Re: [go-nuts] Aren't package declarations (and per file imports) redundant?

Hi, the compiler (not just the linker) needs to know, what identifiers refer to and package imports are file-local, so they necessarily need to be included in all files. Similarly for the package declaration, AFAIK it's used in the object files to disambiguate symbols. What you can do, to reduce

Re: [go-nuts] Aren't package declarations (and per file imports) redundant?

On Sat, Mar 18, 2017, 12:49 wrote: > > > The toolchain already seems to understand the directory layout then why > bother littering the sources with package declaration? > The package declaration is not related to the directory layout. -- -j -- You received this message

[go-nuts] Aren't package declarations (and per file imports) redundant?

Before anyone flames, I love Go! There. Ok, now to the issue at hand -- The toolchain already seems to understand the directory layout then why bother littering the sources with package declaration? Also is there a point to specifying imports at a file level? I mean doesn't the linker bring

Re: [go-nuts] Does it make sense to make expensive syscalls from different goroutines?

On Sat, 18 Mar 2017 03:50:39 -0700 (PDT) Vitaly Isaev wrote: [...] > Assume that application does some heavy lifting with multiple file > descriptors (e.g., opening - writing data - syncing - closing), what > actually happens to Go runtime? Does it block all the

[go-nuts] Does it make sense to make expensive syscalls from different goroutines?

I would appreciate it if someone could clarify how does Go runtime operates under this circumstances: Assume that application does some heavy lifting with multiple file descriptors (e.g., opening - writing data - syncing - closing), what actually happens to Go runtime? Does it block all the

Re: [go-nuts] golint if/else stmt and early returns

Indeed, thanks! On Friday, March 17, 2017 at 5:04:30 AM UTC+1, Nigel Tao wrote: > > This is tangential, but if we're talking about style, you might be > able to simplify this line > ret = PropertiesList(ret).Append(PropertiesList(temp)) > to be > ret = PropertiesList(ret).Append(temp) > if

[go-nuts] Re: Guetzli perceptual JPEG encoder for Go

Thanks Chai! Do you think this is something we could translate to pure go, no requiring cgo? I understand this would be a fair amount of work. I did a similar job recently (translated some PVRTC stuff from c++ to go by copy-paste, then fix everything), it went pretty well. I may try the same

[go-nuts] Re: Setting up GOPATH

On Saturday, 18 March 2017 13:49:13 UTC+10:30, samgusa...@gmail.com wrote: > > Hello, > For some reason, no matter what i do, i just can't seem to get the go path > to work. > My tree(not entirely sure what it is): > -documents > - golang >- src >

[go-nuts] Re: Code review/Advice - reading and editing a CSV

Thanks Peter, Cecil and Charles! I have attached the code as it stands, sorry for not getting back to you sooner. It's still messy but it works, that is, it outputs a column of economic block values in IJK order to be input into an open pit optimiser. The code is for an open source pit