[go-nuts] Re: go modules and vendor: redundant features?

[andrewchamberss]

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, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Mini library for structured concurrency.

[andrewchamberss]

@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 
infinite series on a channel, which would be safely closed once all 
references to the bundle are gone.

errgroup seem to have a 'heavier' api, focused on aggregating errors, 
It also seems strange to me that the 'group' function in errgroup does not 
accept a context which is idiomatic go. Being biased, I prefer my own
API, but actually, use whichever you prefer :) 

-- 
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.

[go-nuts] Mini library for structured concurrency.

[andrewchamberss]

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 manually wait for a bundle to exit.
- You can manually cancel a bundle.


-- 
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.

[go-nuts] Compile to go languages?

[andrewchamberss]

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 existing projects? Any thoughts about why its a good or bad idea, or 
why it doesn't seem to exist already?

-- 
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.

[go-nuts] Appreciating Go

[andrewchamberss]

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 tools I have seen.
- The best race condition detector tool around.
- An incredibly useful in practice interface system. (I once tunneled http 
and ssh connections over a serial port because net.Listener and net.Conn 
are easy interfaces)
- The fastest compiler to use, and to build from source.
- Probably the best cross compilation story of any language, with 
uniformity across platforms, including ones you haven't heard of.
- One of the easiest to distribute binaries across platforms (this is why 
hashicorp, cockroachdb, ngrok etc choose go, it makes on boarding customers 
so much easier.).
- A very sophisticated garbage collector with low pause times.
- One of the best runtime performance to ease of use ratios around.
- One of the easier to learn languages around.
- A compiler that produces byte for byte identical binaries.
- incredibly useful libraries maintained by google: (e.g. Heres a complete 
ssh client and server anyone can  use: 
https://godoc.org/golang.org/x/crypto/ssh)
- Lots of money invested in keeping it working well from many companies: 
cloud flare, google, uber, hashicorp  and more.
- *FINALLY* A fresh and bold take on package management that isn't a cargo 
cult :) - https://research.swtch.com/vgo  (I especially like how well this 
tackles verifiable builds).

Minor things that could be improved in order of importance:

- Ways to express immutability ... as a concurrent language it can still be 
easy to make mistakes and share a buffer or slice by accident.
- More advanced static analysis tools that can prove properties of your 
code (perhaps linked with the above).
- Generics.
- Some sort of slightly more sophisticated pattern matching .



Let me know if I missed anything, thanks again.

-- 
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.

[go-nuts] help with go dep

[andrewchamberss]

$ 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 github.com/golang/sys@master, as its 
subpackage github.com/golang/sys/unix does not contain usable Go code 
(*pkgtree.NonCanonicalImportRoot).. (Package is required by (root).)


Not sure what this means, is this a problem with the dep tool? or a problem 
with the syscall package?

-- 
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.

[go-nuts] Re: Go -> C++ transpiler idea: Miracle child or horrible abomination?

[andrewchamberss]

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 it will quickly be 
abandoned.



On Saturday, March 25, 2017 at 4:32:20 PM UTC+13, Brad wrote:
>
> Interested in any feedback about the idea of making a Go -> C++ 
> transpiler.  Here's the rationale:
>
> * Go as a language has lots of awesome things that make it highly 
> productive.  Lots of Gophers would love to use Go for more projects but 
> some common issues include:
> * Trying to convince your team or management to adopt Go over a "more 
> traditional" language can be a tough sell: Your PHB is likely to tell you 
> it's not worth the risk, because the next developer he hires may not like 
> Go and he'll be screwed, whereas he knows he can find someone who will 
> write C++ or Java.
> * And there is also the issue of the environments in which Go will run. 
>  On embedded platforms (e.g. Parallax Propeller, Arduino) you can write 
> C++, but you're not going to get a Go compiler for it.
> * There's also the fact in a scenario where Go co-exists with C or C++, Go 
> has to have the main function and has to build the executable. Unless you 
> build a shared library, you can't just start implementing parts of your 
> project in Go and gradually phase things over.
>
> It's also worth noting that some of these scenarios just will never 
> support all the features of the Go language, and so full support will not 
> happen.  You probably won't get goroutines on an Arduino, for example. But, 
> that doesn't mean it wouldn't be useful to be able to write Go code in 
> these cases that doesn't use that feature and is otherwise 100% correct Go.
>
> So, what if the following existed:
>
> * Tool that converts Go to C++:
> * Comments and formatting are preserved - the resulting C++ is readable. 
>  You can tell your boss "there's no loss here - if this doesn't work, we'll 
> throw away the Go code and keep working on the C++", even though you know 
> you will burn in hell for doing that ;)
> * Language constructs which have an obvious simple mapping are just 
> directly converted (byte -> uint8_t, structs are structs, etc.)
> * Things that can be done with C++ code but are just ugly (e.g. defer, 
> implemented with goto) would be done like that - the transpiler would just 
> emit that code.
> * Features that are syntactic sugar around runtime implementations are 
> emits as calls to a stripped down version of the runtime that just does the 
> bare minimum to support what's needed: e.g. maps and slices are implemented 
> with a C++ template - the template is the same one that is just dropped in 
> the output as "map.h" and the transpiler emits code that uses it.
> * Heap allocations are mapped to a GC lib implemented in C++ - same as 
> maps above, just more complicated.  Same with channels.
> * Reflection could be done by emitting a bunch of type info and making all 
> that work, but probably wouldn't get around to doing this in a first 
> version.
> * "go" gets mapped to pthread_create(), cognew() or whatever.
> * As much as possible this things are kept as some sort of simple template 
> of the corresponding C++ code to output, so you can easily adjust how 
> allocations or "go" or whatever are emitted for a particular environment.
> * The standard library would probably need to be forked, the things that 
> are heavily intertwined with the Go runtime ("runtime", "reflection", etc.) 
> would probably just not be available initially, and the ones that can be 
> patched and transpiled would be, and then some would probably just need a 
> separate implementation in C++ (e.g. "sync").  There would be an obvious 
> way to do this and it would be a normal thing in this scenario to say: 
> "let's drop in an implementation of fmt that supports only the barebones 
> formatting for use on embedded systems", etc.
> * Features/packages that are not supported would result in a transpiler 
> error.  I.e. some things "you just can't do" with this tool and that's okay.
>
> Assuming this actually worked, it might considerably lower the bar for 
> adopting Go, and allow it to be used to develop in environments where we're 
> not likely to see a port of the compiler any time soon.  (Or where it's 
> literally impossible because there are things in the language that the 
> platform just can't do.)
>
> I could potentially devote some time to building this out, but I wanted to 
> see if anyone had feedback on the concept.  I realize it's not a simple 
> project, but with the above setup it could be implemented incrementally.
>

-- 
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 

[go-nuts] x/crypto/ssh server question

[andrewchamberss]

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 some 
application level permissions based on this key later. Is this possible?  
Currently it seems the only information you can access is the User name. 

I'm trying to create an auth system similar to github's ssh auth.  I want 
to allow anyone to ssh as a user like g...@github.com then do a database 
lookup on the key that was used to auth later when it tries to access 
something it might not have permission for. With the current API it seems 
like its only possible to enable or disable permissions based on the 
username, and not the key used.

Thanks for any help

-- 
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.

[go-nuts] Re: Stalking people online for thought crimes! This is what the Go project has succumbed to!

[andrewchamberss]

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 
on the censorship panel I would almost certainly issue you a warning for 
those.

On Friday, November 4, 2016 at 6:03:53 PM UTC+13, prade...@gmail.com wrote:
>
> That's not up to you to judge if some comment is "harmless" or not. 
> Because you're not the person the comment has been directed at. Something 
> that might seem "harmless" to you might be perceived as insulting to 
> someone else. Aram's comment was unnecessary and insensitive to say the 
> least, it doesn't matter if he is an important contributor to Go or not. If 
> they are rules they apply to everybody equally or they don't, that's what 
> rules are for. Frankly Sarah shouldn't have apologized for anything, she 
> did exactly what she was supposed to do in this case. It doesn't matter how 
> sizable Aram's contribution is, it doesn't preclude him from showing a 
> little bit of respect. 
>
> Right now /r/golang is engaged in yet another bullying campaign against 
> another individual on this thread :
>
>
> https://www.reddit.com/r/golang/comments/5ayvws/github_stars_are_no_more_a_valid_metric_for/
>  
> 
>
> (archived here : http://archive.is/znqJg )
>
> Just because that person has written "a non idiomatic framework" .?
>
> Someone is being labelled at "a marketer with a crappy product" . Is it 
> what moderators here call "a respectful environment" ? the thread is still 
> up as we speak. This has happened before with Martini, then Iris , now 
> utron. That's how the go community wants to grow ? 
>
>
>
>
> Le jeudi 3 novembre 2016 01:38:43 UTC+1, Paul a écrit :
>>
>> I just discovered this thread. I used to be an avid reader of Golang-nuts 
>> mailing list, also of Golang-dev and I am in disbelief at what it has come 
>> to recently.  
>>
>> Aram Hăvărneanu is a very important contributor to the Go Language 
>> Project, I feel embarrased on behalf of the of the Go Language Project 
>> about how he has been treated. This is not OK, and this needs to be very 
>> clearly stated. 
>>
>> This overreaction of your "code of conduct" moderator is beyond 
>> rediculous, to Arams very harmless statement about someones english 
>> language skills. I mean come on ...  Arams sentence is so non-lethal and 
>> tame that it is mind boggling that he should find such alienating 
>> reproachment to me. Especially after all of his valuable contributions.   
>> That it happened because of something he said on Redit just makes it so 
>> much worse. 
>>
>> If you should loose (and it looks like you have) such an important 
>> contributor because of your nonsensical and rediculous  COC moderation 
>> system, then  this system of yours has just completely and utterly failed 
>> and it should be abandoned immediately till a more suitable solution can be 
>> found.  It will not do that someone who is obviously not engaged enough or 
>> mature enough to excersize proper human judgement and care in such a 
>> situation is left to cause such harm as this. And thats my opinion, now you 
>> can ban me from your list for saying that if you want to. 
>>
>> p.s 
>> Just to put things into perspective, I find Linus Torvalds exercise of 
>> freedom of speech utterly refreshing by comparison (and significantly more 
>> edgy), its such a breath of fresh air compared to what you are doing here. 
>> And Linus gets results as you all know, just remember his action against 
>> Nvidia and the waves it created. I am still chuckling about it even today. 
>> I know some very delicate personality's will disagree with me on this, but 
>> maybe they are in the wrong business to begin with. Software developement 
>> has never been for the faint hearted.
>>
>> Thursday, October 27, 2016 at 1:36:23 PM UTC+2, Aram Hăvărneanu wrote:
>>>
>>> I have received a very insulting and distressing e-mail from Sarah
>>> Adams, who claims to represent the The Go Code of Conduct Team, an
>>> illicit bully organization who claims authority about what Go
>>> contributors think and say outside the Go mailing lists. I do not
>>> recognize this group's legitimacy in these matters.
>>>
>>> The e-mail says:
>>>
>>> We received a report about your comment on this thread
>>>
>>> https://www.reddit.com/r/golang/comments/57w79c/why_you_really_should_stop_using_iris/d8wdynd
>>> :
>>> "Their English was so bad I couldn't understand what was
>>> going on".
>>>
>>> This comment goes against our community Code of Conduct,
>>> https://golang.org/conduct. The comment is not respectful,
>>> and would have been more productive just as, "I couldn't
>>> 

[go-nuts] Re: Go can't alloc custom objects from byte slice's memory address?

[andrewchamberss]

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 slice and split object from it manually.
>
> block = make([]byte, 30*1024)
> myObj := (*myObjType)(unsafe.Pointer([offset]))
>
> I write a simple allocator to do it, but I meet strange panic.
> so my question is, can't go alloc custom objects from byte slice's memory 
> address?
>

-- 
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.