If that's true - and it might well not be - it's a surprise to me. When
launching the language we explicitly made sure NOT to trademark it.
-rob
On Fri, May 24, 2019 at 10:50 AM Gerald Henriksen
wrote:
> On Fri, 24 May 2019 07:40:52 +1000, you wrote:
>
> >The last sentence of the article is no
Since this is a mailing list, not sure if my comment could be deleted.
If not, please disreguard my reply, it was a case of unchecked presumptions
meets foot-in-mouth-disease ;/
Thanks,
-K
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To uns
Hi Steve,
I agree with al Jan said, but wanted to clarify one of the comments a bit,
in case it's not imediately obvious.
All throughout the bit of code I looked at I see things like:
err = incrval.SetValStr(tptoken, errstr, &incr)
if nil != err {
panic(fmt.Sprintf("YDB: Unexpected e
On Fri, May 24, 2019 at 3:05 AM wrote:
>
> Unfortunately, after fitting the code with KeepAlive() calls (some probably
> superfluous), the issues and their frequency have not notably changed. It did
> allow me to remove the hack I had put in LockST() described in my original
> note though. I've
On Thursday, May 23, 2019 at 9:18:25 AM UTC-4, lgo...@gmail.com wrote:
>
> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
>
Before I became a GO nut, I did 20 years of commercial Java. I became a big
fan of Google's Guava library.
Guava was open source, but was driven by
Unfortunately, after fitting the code with KeepAlive() calls (some probably
superfluous), the issues and their frequency have not notably changed. It
did allow me to remove the hack I had put in LockST() described in my
original note though. I've even gone as far as commenting out the
finalizer
On Fri, 24 May 2019 07:40:52 +1000, you wrote:
>The last sentence of the article is not correct. The name Go is not
>trademarked by Google, at least as a programming language trademark. There
>are other things Google makes called Go (an interesting signal on its own)
>and they might be trademarked
On Fri, 24 May 2019 07:40:52 +1000, you wrote:
>The last sentence of the article is not correct. The name Go is not
>trademarked by Google, at least as a programming language trademark. There
>are other things Google makes called Go (an interesting signal on its own)
>and they might be trademarked
Ian: I find many of your comments related to how the Go team functions very
interesting,
I for one would find it helpful if 2 or 3 times a year the Go Team would
communicate to the Go community at large, information related to where and
in what direction(s) it is taking Go, and what directions
On Thu, May 23, 2019, at 22:28, Anthony Martin wrote:
> How do you square this opinion with the fact that the Go team went out
> of their way to enable the use of third-party module proxies,
> something that is good for the community but would be of little
> practical use to Google?
I'm certainly
Sam Whited once said:
> This is especially a problem when these proposals further tie Go to
> Google web services run by the Go team (though I'm veering off into a
> separate problem here). To me this feels like it's almost a type of
> vertical integration and it's an absolutely disgusting thing t
The last sentence of the article is not correct. The name Go is not
trademarked by Google, at least as a programming language trademark. There
are other things Google makes called Go (an interesting signal on its own)
and they might be trademarked, but Go the language is not a trademark.
-rob
--
On 23-05-2019, Sam Whited wrote:
> Thank you for writing your reply Ian. Since it's a rather long post I
> don't want to go through it point by point, but suffice it to say that I
> agree with most of what you've written. However, I also agree that Go is
> Google's language, and that in its current
This makes a bit of sense from the Google point of view.
The central nut of a language under development is something that needs to
be well managed.
I have seen this with Modula-2 in the past as well as C++.
Niklaus Wirth declined blessing a standard library for Modula-2 perhaps
killing it as a ma
I apologize for the rambling nature of this post; I somehow sent this
while working on a revision, I should really figure out what keyboard
shortcut I keep accidentally hitting to do that, especially when I
haven't toned down the language yet. Oh well, please pardon the lack
of polish.
—Sam
On Th
Thank you for writing your reply Ian. Since it's a rather long post I
don't want to go through it point by point, but suffice it to say that I
agree with most of what you've written. However, I also agree that Go is
Google's language, and that in its current form this is a problem. I'm going to
ta
I just want to thank Ian for taking the time to write this. I've already
got the idea that it worked that way, but my own deduction process, but
it's good to have a confirmation from inside.
When I started contributing to Go, whatever that means... talks, code,
samples, etc... my first reaction ab
Good point i'll update with a timeout to flush in case traffic is slow
On Thu, May 23, 2019 at 1:38 AM roger peppe wrote:
> On Thu, 23 May 2019 at 01:34, Anthony Metzidis
> wrote:
>
>> Fun thought exercise -- here's another approach.
>>
>>
>> https://play.golang.org/p/Xu7iWhY4PUQ
>>
>
> ISTM th
This was my attempt at a channel with priorities:
https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
Based on the assumption that priorities only make sense if items are
queued. If they are pulled out from a channel as fast as they are added to
it, then there is no need
On Thu, May 23, 2019 at 9:18 AM wrote:
>
> https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
Thanks for the link. There is clearly a real sense in which Go is
Google's language. But I think I would like to emphasize some points
that don't necessarily contradict the blog p
There will be a difference - once someone optimizes the 256 possible
decadic representations of a byte as an array of hardcoded strings in the
fmt package ;-)
On Thu, May 23, 2019, 18:25 гусь wrote:
> a = 'a'
> fmt.Println(a)
>
> fmt.Println(byte(a))
>
> --
> You received this message because yo
I'm a hobbyist and make no money on the Go projects I write. This article
seems a bit over-the-top, particularly Fred Fnord's comment. Doesn't Linus
Torvalds have a stranglehold on the Linux kernel? Yet Linux flourishes.
Rather than complaining about Google (via Go) why don't these folks simply
a = 'a'
fmt.Println(a)
fmt.Println(byte(a))
--
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.
To view this discussion on
https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage
--
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.
Thank you very much Ian. Being new to the language, I was unaware of
KeepAlive() but had been wondering how you kept the GC's aggressive
tendencies under control.
I know what I'll be doing today..
Steve
--
You received this message because you are subscribed to the Google Groups
"golang-nut
I don’t believe your example is correct. In order for a current wrapper to call
Flush on Close on the bufio.Writer the Close would need to be defined on the
Wrapper struct so there would be no name collision.
I think it is best to see the proposal before commenting. I plan on addressing
any co
Another idea might be to avoid making the costly Done check every time.
Something like this perhaps (untested)?
// NewDoneChecker returns a DoneChecker value
// that amortizes the cost of calling ctx.Done by only
// calling ctx.Done every interval times that
// DoneChecker.Done is
I have to say that I must prefer APIs that do not take arbitrary advantage
of dynamically discovered methods. It makes things less clear, and adding a
wrapper to flush and then close the underlying writer is not hard. In fact
the idiom for doing so is probably the reason why it's not feasible to ad
A bit less "funky" idea - I currently use it in my
https://github.com/cosmos72/gomacro
to interrupt the interpreter if the user hits Ctrl+C.
Caveat: I don't know how difficult is to adapt it to GoAWK.
The idea is conceptually simple: loop unrolling. The details are slightly
tricky:
unroll the i
Oops, forgot to include the playground link at the end there:
https://play.golang.org/p/mYSRsGb4mRA
On Thu, 23 May 2019 at 09:38, roger peppe wrote:
> On Thu, 23 May 2019 at 01:34, Anthony Metzidis
> wrote:
>
>> Fun thought exercise -- here's another approach.
>>
>>
>> https://play.golang.org/p
On Thu, 23 May 2019 at 01:34, Anthony Metzidis
wrote:
> Fun thought exercise -- here's another approach.
>
>
> https://play.golang.org/p/Xu7iWhY4PUQ
>
ISTM that that approach doesn't work because you're buffering 10 values
before you send any.
So if you have a situation when you've got very litt
31 matches
Mail list logo
