Rather than using unsafe, maybe you could batch allocate with typed slices.
that are split up by type.
On Saturday, July 9, 2016 at 5:11:49 PM UTC+12, Arthur wrote:
>
> my program allocates many different kinds of small object, and that gives
> GC a lot pressure.
> so I wan't to make a big
I would also like to point out the extreme hypocrisy of saying Aram's
comment is "unnecessary and insensitive" then labeling someone's thread as
"bullying" (a pretty serious charge in todays climate). Both of which I
would consider worse insults than saying someone has bad English. If i was
I am trying to get access to get public key that was used to authenticate
an ssh connection (https://godoc.org/golang.org/x/crypto/ssh#ConnMetadata)
inside the PublicKeyCallback while handling a channel request. I want to be
able to accept the connection with any public key, but then control
Its a bad idea for many reasons.
- The actual implementation is harder than convincing someone to just use
the official Go compiler.
- Some features don't map cleanly to C++
- C++ programmers won't like it, and neither will go programmers.
- Nobody will fund the maintenance of this compiler and
$ dep version
dep:
version : devel
build date :
git hash:
go version : devel +7b9d15d566 Wed Oct 18 21:45:30 2017 +
go compiler : gc
platform: linux/amd64
$ dep init
No versions of github.com/golang/sys met constraints:
master: Could not introduce
Just a list of things I like about Go, thanks everyone for the hard work:
Good things go has:
- Go has an extremely useful std library.
- Go has the best backwards compatibility I have seen (I'm pretty sure code
from go version 1.0 still works today.).
- Go has the nicest code manipulation
Don't get me wrong, I love go, but also wonder if there are any languages
that compile to idiomatic go.
I noticed reasonml compiles to javascript, and wondered to myself if there
is any value in such languages using go as a base for
interop to take advantage of the libraries and runtime.
Any
@Sebastien
The biggest difference is my package makes guarantees that when a bundle is
garbage collected the context and thus child goroutines
are cancelled. This lets you be more creative having shared ownership of
groups of goroutines, e.g. a collection of goroutines producing a lazy
A mini library I came up with, let me know what you think:
https://github.com/andrewchambers/bundle
Introduces the concept of a bundle of goroutines.
- All goroutines part of a bundle share a context.
- The context is cancelled automatically when the bundle is garbage
collected.
- You can
I recall reading from Russ Cox that vendoring will be removed in the future
and be replaced by explicit caching with modules.
--
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,
10 matches
Mail list logo