I think we all agree that Python has some major issues.. :)
But the point of Jon's argument which struck me as very compelling is that Go
would really need full operator overloading to serve as a serious competitor
given the standards to which people have become accustomed. I didn't see in
This looks like something I might have done. However, my preference would
be to write a wrapper MustGetParameter receives string field, calls
store.GetParameter(field), returns parameter or panics.
You may then use
defer func() { globalErr = recover()}
tenantID, err1 :=
I meant "see if G is on an M"
On Wednesday, October 7, 2020 at 5:55:45 PM UTC-7 Uday Kiran Jonnala wrote:
> Just wondering if we can add additional condition below
>
> https://golang.org/src/runtime/lock_futex.go
>
> func lock2(l *mutex) {
> gp := getg() 52
> ...
> // Try for lock,
Just wondering if we can add additional condition below
https://golang.org/src/runtime/lock_futex.go
func lock2(l *mutex) {
gp := getg() 52
...
// Try for lock, rescheduling.
for i := 0; i < passive_spin; i++ {
We may need to improve this by stubbing the ownership
So we respectfully disagree here, so the best thing I can do is add some
quality arguments. I think this is an important discussion that might
cement Go as a broad DSL in the sense that it does a lot of things
exceptionally well, but this issue will remain a blind spot.
I fully understand the
Jon's points probably sink this proposal. Go is a very different language, and
making it less self-consistent to solve some fraction of syntactic readability
is almost certainly not going to get over the very high threshold for changing
the language.
If you're going to switch over to Go,
On Wed, Oct 7, 2020 at 9:12 PM Howard C. Shaw III
wrote:
> You said:
>
>> I was trying around with arrays and generics because slices are more
>> complex to reason about than arrays. For example, I introduced bugs into my
>> code by not being fully aware of slices overwriting original data when
You said:
> I was trying around with arrays and generics because slices are more
> complex to reason about than arrays. For example, I introduced bugs into my
> code by not being fully aware of slices overwriting original data when you
> append to them and the capacity is not set correctly.
Hi, I'm looking for thoughts from some experienced go programmers on a
technique to reduce error handling verbosity.
The basic idea is to be optimistic over a few instructions, and then
combine many errors in to one. This gist and explains the idea (note the
absence of if err != nil {} )
Yeah the inclination is towards 512 curve only so need to optimise it.
Will check out the C library. Thanks
On Wed, 7 Oct 2020, 22:22 Marcin Romaszewicz, wrote:
> secp256r1 has been hand optimized for performance, the others haven't.
>
> If performance there matters to you, it's actually
secp256r1 has been hand optimized for performance, the others haven't.
If performance there matters to you, it's actually faster to call out to C
libraries to verify 384 and 512 bit curves.
On Wed, Oct 7, 2020 at 9:27 AM Shobhit Srivastava
wrote:
> Hi All
>
> I have tried to do the performance
Hi All
I have tried to do the performance analysis for different curve in golang
and got below output:
for secp256r1 I got 28000 Signature verified per second
for secp384r1 I got 1600 Signature verified per second
for secp521r1 I got 700 Signature verified per second
Is there something I
Is it possible to capture the outgoing port for a given HTTP request?
I'm using a knockoff of ab that I wrote in go to send repeated requests to
a given web service. Sometimes we get an error and I want to look at a
packet trace of it. The problem is it's really hard to find one failed
request
On Tue, Oct 6, 2020 at 7:45 PM Ian Lance Taylor wrote:
> On Tue, Oct 6, 2020 at 6:32 AM Markus Heukelom
> wrote:
> >
> > It appears to me the current proposal does not allow you to write a
> function that sorts an array of any size:
> >
> > func SortArray[T comparable](array [??]T, less func(a,
On Wednesday, 7 October 2020 09:31:55 UTC+1, Ryan Keppel wrote:
>
> I meant this code:
> https://golang.org/src/cmd/compile/internal/syntax/scanner.go#L187 .
>
That code says:
- dot followed by a decimal is a number
- dot followed by dot followed by dot is a _DotDotDot (ellipsis)
- otherwise,
On Wednesday, 7 October 2020 08:05:39 UTC+1, Amnon wrote:
>
> Go generally ensures that zero values are useful.
>
> So a zero slice allows us to append to it, without having to do any
> special initialization.
>
>
Not exactly. Appending to a slice always creates a *new* slice value:
s2 :=
On Wed, Oct 7, 2020 at 10:29 AM Ryan Keppel wrote:
> Yes, I mean that code section. I did a quick test and two floats tokenizes
> just fine (2..5 tokenizes to "2." and ".5")--it doesn't invoke the
> described code. I don't think Go in practice would allow two dot tokens in
> a row. Go's parser
I meant this
code: https://golang.org/src/cmd/compile/internal/syntax/scanner.go#L187 .
On Wednesday, October 7, 2020 at 1:29:24 AM UTC-7 Ryan Keppel wrote:
> Yes, I mean that code section. I did a quick test and two floats tokenizes
> just fine (2..5 tokenizes to "2." and ".5")--it doesn't
Yes, I mean that code section. I did a quick test and two floats tokenizes
just fine (2..5 tokenizes to "2." and ".5")--it doesn't invoke the
described code. I don't think Go in practice would allow two dot tokens in
a row. Go's parser is very loose ("1 + 10 = 20" isn't a syntax error) and I
On Wed, Oct 7, 2020 at 9:23 AM Ryan Keppel wrote:
> In the current Golang
The name is Go. There's no Golang programming language.
> implementation of scanning, there's some extra code to handle ".." in the
> source (as two dot tokens).
Do you mean this?
In the current Golang implementation of scanning, there's some extra code
to handle ".." in the source (as two dot tokens). Would this ever happen in
practice? Two floats together?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
Hi,
this has been discussed many times, e.g.
https://groups.google.com/g/golang-nuts/c/5_8E9OblIho/m/b9O038mzBQAJ
In short: The semantics of maps require them to be pointer-shaped.
Currently, all zero values are a sequence of zero bytes (making it very
cheap to initialize to them). That means the
Go generally ensures that zero values are useful.
So a zero slice allows us to append to it, without having to do any special
initialization.
This approach also extends to the standard library.
sync.Mutexs are unlocked and usable in the zero state.
Even zero sync.Maps ready for use.
So why
23 matches
Mail list logo
