Re: [go-nuts] Is there a final document on generics?

Failure to provide a standard “collections” package would be a huge mistake. It is certainly a top 3 reason for the success of Java. > On Mar 16, 2021, at 6:52 AM, 'Axel Wagner' via golang-nuts > wrote: > >  > The very detailed design doc is linked in the proposal issue. That's the > design

Re: [go-nuts] No generic, part -2

Very well said. > On Mar 15, 2021, at 7:04 PM, Jeremy French wrote: > > I was really trying not to weigh in here, mostly because it's a decision > that has been decided, so there's not a lot of point in continuing the > discussion, and yesterday it seemed like the thread would die, yet... it

Re: [go-nuts] insane idea to eliminate CGO latency

I think it is more of using a specialized compiler on unmodified C code and expecting it to work. > On Mar 15, 2021, at 3:58 PM, Andy Balholm wrote: > >  > By the way, this existed at one point. Early versions of the Go toolchain > included C compilers (6c, 8c, etc.) designed to work togethe

Re: [go-nuts] insane idea to eliminate CGO latency

Totally agree and that was my point. If the desire is to speed up calls to C there are many options - done explicit (like marking calls non blocking), or implicit - once a routine makes a “unknown” C native call that routine is always bound to a dedicated thread - clearly you are trading perform

Re: [go-nuts] insane idea to eliminate CGO latency

scheduler is the bottleneck in calling C code. > On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor wrote: > > On Sun, Mar 14, 2021 at 1:46 PM Robert Engels wrote: >> >> That was my point, based on Java, there is the ability to make the GC >> coordination extreme

Re: [go-nuts] insane idea to eliminate CGO latency

tackle than this proposal. > On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor wrote: > > On Sun, Mar 14, 2021 at 12:00 PM Robert Engels wrote: >> >> Based on two decades of Java FFI - the overhead comes from type mapping not >> the housekeeping to control GC. The l

Re: [go-nuts] insane idea to eliminate CGO latency

Based on two decades of Java FFI - the overhead comes from type mapping not the housekeeping to control GC. The latter can be as simple as a volatile read and 2 writes per call and can usually be coalesced in tight loops. Since Go already has easy native C type mapping the FFi should be very eff

Re: [go-nuts] sort string slice like it contains key,val

That wasn’t specified in the assignment :) > On Mar 13, 2021, at 2:59 PM, Levieux Michel wrote: > >  > Your need is not only to sort your data elements then..? > Using the previously advised solution you can just range the slice *after* > you sort it, so you can just check for the next elemen

Re: [go-nuts] struct conversion, new fields, and incompatibility

I don’t think you can separate the two - it seems the OP purpose of using the struct conversion is to facilitate a different serialization format. This is a place where Gos convenience (struct tags) is running into explicitness. The struct conversion is nothing more than a magic copy. Make this

Re: [go-nuts] struct conversion, new fields, and incompatibility

-message > and try to do the same struct-conversion Colin mentions, you will run into > exactly the same problem. We are talking about language facilities here, not > third party code generators. > >> On Thu, Mar 11, 2021 at 11:48 PM Robert Engels wrote: >> If you use p

Re: [go-nuts] struct conversion, new fields, and incompatibility

If you use protobufs and the current guidelines you can always add new fields. > On Mar 11, 2021, at 12:43 PM, 'Axel Wagner' via golang-nuts > wrote: > >  > Hi, > > in some sense, every change to an exported symbol is a breaking change. So a > straight-forward "does this change have the pot

Re: [go-nuts] Contrary to popular opinion...

I wasn’t referring to the mixed tab/space issue. I mean you copy a few live that are at one indentation to another location with a different indentation - everything is mucked up usually. You don’t have these issues with brackets - the code is easily formatted correctly or a bracket added then f

Re: [go-nuts] Contrary to popular opinion...

I think the only time the indentation is a problem is when refactoring code - copying pasting code blocks seems to be a guessing game with my IDEs and often require manual fixes - the issue seems far less common (and more easily corrected) when using brackets. > On Feb 28, 2021, at 12:12 PM,

Re: [go-nuts] Contrary to popular opinion...

Popularity has nothing to do with good - thus Twitter and the Kardashians. . > On Feb 28, 2021, at 2:35 AM, 'Dan Kortschak' via golang-nuts > wrote: > > On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote: >> I meant, for example, in regexp notation, ` *` vs `\n *` between a >> function signat

Re: [go-nuts] Golang problem

Please provide your answer/code and we’ll look it over. > On Feb 27, 2021, at 5:47 AM, Vignesh Kumar wrote: > > Hello all, > > Thanks in advance, please help me to finish this assignment > > You are given a string S consisting of letters 'a' and 'b'. You want to split > it into three separat

Re: [go-nuts] Contrary to popular opinion...

ot;delivered code". But in a personal single > machine single developer environment, all the extra complexity and manual > overhead might not worth it. I'd guess that most students and hobbyists don't > even use SCMs. My point was that GOPATH mode is good for them. >

Re: [go-nuts] Incompatibility of reflection libraries (reflect versus go-reflect), on json-iterator (Go 1.15.8)

Maybe direct your inquiries to the developer if go-reflect? > On Feb 26, 2021, at 8:11 AM, Yan Titarenko > wrote: > >  > CC'ing to committers. > > Ian, > please provide some advise. > > Thanks in advance > >> On Wed, Feb 24, 2021 at 2:00 PM Yan Titarenko >> wrote: >> Hi. >> >> Since ther

Re: [go-nuts] Contrary to popular opinion...

That is 100% true but a important point is that using GOPATH requires manual dependency management via ‘vendoring’. This can be very labor intensive and error prone - leading to security issues in your delivered code. > On Feb 25, 2021, at 3:08 PM, Bob Alexander wrote: > >  > GOPATH mode doe

Re: [go-nuts] Orderly exit

rror handling should prevent/limit that. > On Feb 24, 2021, at 5:29 PM, Kevin Chadwick wrote: > > On February 24, 2021 11:16:46 PM UTC, robert engels > wrote: >> I’m sorry but that is not correct. If you have a “server process” that >> handles requests for 1000’s of clients -

Re: [go-nuts] Orderly exit

You can read the section ‘Apache Vulnerabilities’ and the difference in forking vs multi-threader Apache configuration and how that triggers a DoS. See https://www.feistyduck.com/library/apache-security/online/apachesc-CHP-5.html > On Feb 24, 2021, at 5:16 PM, robert engels wrote: >

Re: [go-nuts] Orderly exit

- especially with round-robin servicing - you can take down 1000’s of servers with 1:1 requests. > On Feb 24, 2021, at 4:04 PM, Kevin Chadwick wrote: > > On February 24, 2021 8:00:36 PM UTC, Robert Engels > wrote: >> Depending on other infrastructure that can easily lead to e

Re: [go-nuts] Orderly exit

Depending on other infrastructure that can easily lead to easy DoS attacks. > On Feb 24, 2021, at 12:15 PM, Kevin Chadwick wrote: > > On 2/24/21 9:53 AM, roger peppe wrote: >> On Tue, 23 Feb 2021 at 12:10, Kevin Chadwick > > wrote: >> >>I only instigate panic m

Re: [go-nuts] Error handling

I’ll only add to this, there is no reason to close in the exception handler - it is automatic by the try-with-resource. The only reason to check null is if you needed to “do something else” based on that state. I think a better pattern with the “something else” is to always use standard wrapper

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

I would refer you back to the other article I linked to on setting up your host name properly. When I test using the default DNS resolving I can resolve both ‘iMac’ and ‘iMac.local’ in 2-3 milliseconds without any entry in my /etc/hosts file. If I add the entry ‘iMac.local’ to my /etc/hosts fi

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Nice work. > On Feb 23, 2021, at 10:16 AM, Shulhan wrote: > >  >> On 23 Feb 2021, at 12.40, Peng Yu wrote: >> >> I don’t understand why ping does not have the same problem. Ping is not >> based on C library? >> > > Looking at the source code, the ping command on macOS use gethostbyname2()

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

20 PM UTC, Robert Engels > wrote: >> I am not 100% certain but the build statement at the top of the Unix >> dns client specified Darwin. I would read the Go issues I linked to in >> the code snippet. > > I believe it varies. Android has no universal textual interfac

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

arwin I believe that by > default we pass DNS lookups to the C > library." (I assume "we" means Go developers.) > > Are you correct or Ian is correct? > >> On Tue, Feb 23, 2021 at 8:14 AM Robert Engels wrote: >> >> As I pointed out, Go does not use

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

library should not be > relied on in this case. I just want to use /etc/hosts but not > resolve.conf. > >> On 2/22/21, robert engels wrote: >> It looks like the Go runtime implements its own DNS client on *unix >> platforms including OSX. >> >>>> On

Re: [go-nuts] Error handling

The complexity there is from generators + exceptions. I am not proposing generators for Go as it doesn’t need it. > On Feb 23, 2021, at 6:03 AM, Nigel Tao wrote: > >  > If you're proposing exceptions, be aware of how complicated the control flow > for correct handling can be. Look for what f

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

golang.org/issue/16739. func avoidDNS(name string) bool { if name == "" { return true } if name[len(name)-1] == '.' { name = name[:len(name)-1] } return stringsHasSuffixFold(name, ".onion") } so Go issue 16739 might help. > On Feb 22, 2021,

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

Still, if you follow that article I referred you to it may fix your issue - as the resolv.conf is auto-generated on OSX and includes hostname mappings. > On Feb 22, 2021, at 11:48 PM, robert engels wrote: > > It looks like the Go runtime implements its own DNS client on *unix

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

It looks like the Go runtime implements its own DNS client on *unix platforms including OSX. > On Feb 22, 2021, at 11:40 PM, Peng Yu wrote: > > I don’t understand why ping does not have the same problem. Ping is not based > on C library? > > On Mon, Feb 22, 2021 at 11:20 PM Ian Lance Taylor

Re: [go-nuts] Why can net.Dial be very slow on a hostname defined in /etc/hosts?

This https://apple.stackexchange.com/questions/175320/why-is-my-hostname-resolution-taking-so-long may help you. > On Feb 22, 2021, at 11:20 PM, Ian Lance Taylor wrote: > > On Mon, Feb 22, 2021 at

Re: [go-nuts] Error handling

> On Feb 21, 2021, at 8:51 PM, Ian Davis wrote: > > On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets >>

Re: [go-nuts] Error handling

> On Feb 22, 2021, at 8:33 AM, Wojciech S. Czarnecki wrote: > > Dnia 2021-02-21, o godz. 11:23:24 > robert engels napisał(a): > >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? > > May you please explain the bene

Re: [go-nuts] Error handling

21, 2021, at 8:52 PM, Ian Davis wrote: > > On Sun, 21 Feb 2021, at 5:23 PM, robert engels wrote: >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes to crickets >> - I have to believe that i

Re: [go-nuts] Error handling

See below: > On Feb 21, 2021, at 3:17 PM, Ian Lance Taylor wrote: > > On Sun, Feb 21, 2021 at 9:23 AM robert engels wrote: >> >> Can someone please explain the benefit of ‘error return’ over ‘checked >> exceptions’ ? I have made the point a few times and it goes

Re: [go-nuts] Error handling

Can someone please explain the benefit of ‘error return’ over ‘checked exceptions’ ? I have made the point a few times and it goes to crickets - I have to believe that is because there is none, or it is difficult to communicate. The ‘handle where they occur claim’ is weak, as you can handle exc

Re: [go-nuts] Error handling

? Probably pretty awful, given just > about any line of code would be capable of throwing an exception. But > exceptions typically aren't counted, so that functions are thought to be far > less complex than they really are in the presence of exceptions. > > Invisible (magic)

Re: [go-nuts] Error handling

robust and reliable systems. > On Feb 20, 2021, at 2:30 PM, Ian Lance Taylor wrote: > > On Sat, Feb 20, 2021 at 12:11 PM Robert Engels wrote: >> >> Can you clarify what you mean mean by “the code does exactly what it shows >> on the page”? How do you know by looking at

Re: [go-nuts] Error handling

Can you clarify what you mean mean by “the code does exactly what it shows on the page”? How do you know by looking at the code, or even compiling the code, that all possible errors returned by a function are handled? That to me is biggest difficult in reading (or using) others Go code. Exceptio

Re: [go-nuts] A goroutine question

For parallelizing code like this, you will probably see better performance by having each routine process a full row rather than a cell. You amortize the overhead better. Still the matrix is probably too small to make a difference. > On Feb 19, 2021, at 8:56 AM, 'Peter Weinberger ' via golang

Re: [go-nuts] Error handling

There's no crossfire :) I think most of the issues I have can probably be addressed with some standardized packages without converting panic/recover into full-blown exceptions and making them the default. The key is “standardized”, which is why I’m sad to see lack of progress towards a new para

Re: [go-nuts] Error handling

Yes but without robust error information (stack trace, typed error) it is very hard to write that top-level handler - at least not a robust one. Plus you are relying on the proper use of defer etc up the chain. This is much simpler with exceptions - to me anyway. > On Feb 18, 2021, at 10:39 AM

Re: [go-nuts] Error handling

To clarify, the Java like/runtime reference I made does not strictly refer to startup costs - I am also referring to runtime costs as in additional threads for GC, housekeeping, overall binary size, etc. I don’t think ‘single shot, short lived processes’ are the typical Go paradigm - they are us

Re: [go-nuts] Error handling

But - the issue is that most of the time - for complex systems - the errors cannot be handled where they are encountered - even in Go, most of the error handling becomes boilerplate returning the error detected and expecting some higher level to handle it. With exceptions this is enforced, or a

Re: [go-nuts] Error handling

And I will tell you that after working with error returns and exceptions, exceptions are superior - but much depends on the complexity of the system. For small system level tools that are pieced together via pipes, C error handling is fine - because the process serves as the exception handling p

Re: [go-nuts] Error handling

I think ’strong census’ is not accurate - thus the discussions around improving error handling in Go2. Many have commented here and elsewhere that the number one reason they don’t use Go is due to lack of exception handling. > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki wrote: > > Dni

Re: [go-nuts] Re: Unable to find small memory leak

Are you using CGo or libraries that use CGo? If so, you probably have an off-heap, i.e malloc() leak > On Feb 11, 2021, at 11:11 AM, Tom Mitchell wrote: > >  > >> On Thu, Feb 11, 2021 at 3:40 AM Uli Kunitz wrote: >> You are writing: The device crashes with out of memory. What does crash? T

Re: [go-nuts] x/image/font: Font serialization

If you don’t write the font “exactly” you might run into copyright/TOS problems. In most cases though, you are better off using standard fonts and using the correct name in the pdf - and let the viewer find/replace the font - you will not have a problem in that case. > On Feb 5, 2021, at 5:08

Re: [go-nuts] x/image/font: Font serialization

> >> On Thursday, February 4th, 2021 at 8:28 PM, Robert Engels >> wrote: >> >> If you have the data to pass to Parse then you have the data to embed the >> font in the pdf. >> >>>> On Feb 4, 2021, at 12:02 PM, Sebastien Binet s...@sb

Re: [go-nuts] R.I.P. Michael Jones

A sad day. A great tribute. Thanks. > On Feb 4, 2021, at 5:13 PM, Jan Mercl <0xj...@gmail.com> wrote: > >  > https://www.geospatialworld.net/blogs/goodbye-michael-jones-the-man-who-gave-the-power-of-maps-in-our-hands/ > -- > You received this message because you are subscribed to the Google Gr

Re: [go-nuts] x/image/font: Font serialization

If you have the data to pass to Parse then you have the data to embed the font in the pdf. > On Feb 4, 2021, at 12:02 PM, Sebastien Binet wrote: > > hi there, > > Right now, I am pretty happy with the state of the > x/image/font{,/sfnt,/opentype}} packages. I can load TTF/OTF files, draw > s

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

s in Go, better to be explicit and report errors rather than be clever. > On Feb 2, 2021, at 12:34 PM, 'Axel Wagner' via golang-nuts > wrote: > > On Tue, Feb 2, 2021 at 6:43 PM Robert Engels <mailto:reng...@ix.netcom.com>> wrote: > What “padding” are you re

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

e used >>> outside of a-zA-Z0-9. The most common ones use +/ and -_, so it's easy to >>> tell which is used and just accept either (and padding can be viewed as >>> optional during decoding anyway). >>> >>>> On Tue, Feb 2, 2021 at 2:37 PM Robert

Re: [go-nuts] Possible to make base64 pick the decode encoding automatically?

Base64 is always ASCII. The encoded data may be in an arbitrary format. You need to pass additional metadata or try and detect its encoding. > On Feb 2, 2021, at 6:50 AM, roger peppe wrote: > >  > In case you find it helpful, here's a clone of the base64 command that I > wrote in Go. I did i

Re: [go-nuts] How to improve the parallelism of go routine？

Unless it is an in memory database, I would expect the IO costs to dwarf the cpu costs, but I guess a lot depends on how you define ‘analytical processing’. In my experience, “out of the box” performance of Go routines in IO processing is outstanding. For the cpu bound case, I think with thread

Re: [go-nuts] How to improve the parallelism of go routine？

You wrote “I found that cache misses from routines switching is also a headache”. They would not be switching if they are cpu bound and there are less of than number of cpus. Remember too that you need some % of the cpus to execute the runtime GC code and other housekeeping. > On Feb 1, 2021

Re: [go-nuts] How to improve the parallelism of go routine？

If you look at the “disrupter pattern” you’ll see what I mean. If the tasks are cpu bound - by having more threads/routines than cpus you cause inefficiencies (scheduling overhead, cache locality / invalidation, lock contention). > On Feb 1, 2021, at 9:02 PM, 颜文泽 wrote: > >  > I don't unders

Re: [go-nuts] How to improve the parallelism of go routine？

Having more cpu bound routines than you have physical cpus is not a good idea. > On Feb 1, 2021, at 8:21 PM, 颜文泽 wrote: > > I'll try 1.14, when writing cpu-intensive programs (I'm mainly a database), > I found that cache misses from routines switching is also a headache and I > don't know ho

Re: [go-nuts] normal mode and starve mode of sync.Mutex and runtime mutex?

Not sure the runtime needs it - as all lock usages are known - so the users in the runtime can ’negotiate’ fairness through other means for a particular mutex. > On Jan 31, 2021, at 8:56 PM, xie cui wrote: > > mutex in sync package and runtime is different, > mutex in runtime package is here,

Re: [go-nuts] Re: []byte and string convert?

And if you use byte[] everywhere rather than string be prepared for lots of panics and hard to detect bugs. :) > On Jan 29, 2021, at 8:35 AM, Amnon wrote: > > Generally yes. > As strings are immutable, and []byte is not, > if you convert from string -> []byte, you need a new copy which can be

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 8 updates in 4 topics

Channels are built with locks which without biased locking can lead to delays as routines are scheduled / blocked under -especially under contention. github.com/robaho/go-concurrency-test might illuminate some other options to try. > On Jan 18, 2021, at 8:13 PM, Pete Wilson wrote: > > No n

Re: [go-nuts] Advice, please

> occam, so channel-y stuff is lapsed second nature - channels just work - and > all this building barrier stuff is terribly unnatural. So my instincts are > (were?) good, but platform performance doesn’t seem to want to play along] > >> On Jan 17, 2021, at 9:21 AM, Robert En

Re: [go-nuts] Advice, please

If there is very little work to be done - then you have N “threads” do M partitioned work. If M is 10x N you’ve decimated the synchronization cost. > On Jan 17, 2021, at 9:11 AM, Pete Wilson wrote: > > The problem is that N or so channel communications twice per simulated clock > seems to ta

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

Wait()” > > If that were the case, none of them would ever see a non-zero count after any > one of them had seen it, and so no race condition could exist > > You suggest that that is not the case. > > (I don’t intend to be obtuse, even if I seem so) > > — P > >

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

ks very much. > Simpler than a double waitgroup, same overall effect. > > I may have a weird use case, but maybe this might be worth adding to the > examples. > > — P > >>> On Jan 16, 2021, at 6:14 PM, Robert Engels wrote: >>> >>> WaitGroups ar

Re: [go-nuts] Digest for golang-nuts@googlegroups.com - 20 updates in 7 topics

WaitGroups are deterministic in that sense. Whether they are all released at once (there is no such thing as “at once” in practice) you have a race. You can restructure this to avoid the race. You should Add() to to the stage 1 and 2 wait groups after the Wait() returns and before you Wait() on

Re: [go-nuts] Re: Advice, please

I forgot. But it’s to important to mention that different synchronization methods perform differently under contention so what works well for 2 might be really poor with 64. > On Jan 13, 2021, at 10:04 PM, Kurtis Rader wrote: > >  >> On Wed, Jan 13, 2021 at 7:58 PM Rober

Re: [go-nuts] Re: Advice, please

Why limit yourself to two? Use N routines and have each process every N in the list. > On Jan 13, 2021, at 7:25 PM, Nikolay Dubina > wrote: > >  > Any primitive in `sync` package will do. I would go for two `RWMutex` each > for each goroutine, or two unbuffered channels for each gorouitne.

Re: [go-nuts] Advice, please

This https://github.com/robaho/go-concurrency-test might help. It has some relative performance metrics of some sync primitives. In general though Go uses “fibers” which don’t match up well with busy loops - and the scheduling overhead can be minimal. > On Jan 13, 2021, at 6:57 PM, Peter Wilso

Re: [go-nuts] Generics security discussion.

1 2:06 PM, Robert Engels wrote: >> A panic is not a security issue. Memory corruption/stack overflow is. In Go >> the latter is accomplished through CGo and unsafe pointers/operations. >> > > It isn't as clear cut as that. Panics can be security issues and memory

Re: [go-nuts] Generics security discussion.

A panic is not a security issue. Memory corruption/stack overflow is. In Go the latter is accomplished through CGo and unsafe pointers/operations. Continuous panics can be considered a security issue as a DoS attack but IMO at least there are many ways to generate continuous errors that are sim

Re: [go-nuts] Clarification related to HTTP request context cancellations and goroutines

021, at 9:17 PM, Amit Saha wrote: > >  > >> On 8 Jan 2021, at 1:59 pm, Robert Engels wrote: >> >> You need to pass the context to the expensive work a periodically check if >> it has been cancelled. > > Thanks. I was thinking how to implement th

Re: [go-nuts] Thread safe tree library?

I would review the source code of the Java concurrent package. It has links to the relevant academic research. > On Jan 8, 2021, at 1:29 PM, Nathan Fisher wrote: > >  > I was thinking of potential issues if you rebalance the tree as an example. > > I’m not certain what issues could arise as

Re: [go-nuts] Clarification related to HTTP request context cancellations and goroutines

You need to pass the context to the expensive work a periodically check if it has been cancelled. > On Jan 7, 2021, at 8:55 PM, Amit Saha wrote: > > Hi all, I want to confirm whether my understanding related to handling > HTTP client disconnections is correct or not. > > Consider this: > >

Re: [go-nuts] Thread safe tree library?

You can look at github.com/robaho/keydb and it’s LSM trees as an alternative method of concurrency. You can also take the low level tree.go and wrap it in a RW mutex. > On Jan 6, 2021, at 9:28 AM, ksbh...@gmail.com wrote: > >  > https://pkg.go.dev/lang.yottadb.com/go/yottadb gives you B*tree

Re: [go-nuts] Thread safe tree library?

I think you have to go a bit more and use a RW mutex to ensure memory consistency (for the simple solution). > On Jan 5, 2021, at 8:52 PM, joseph.p...@gmail.com > wrote: > > Well, I think I only need to lock on writes, and it'll be easier if I just > lock the entire tree on writes. Reads wi

Re: [go-nuts] [generics] moving the last type parameter to a type outside the square brackets

Reading sync.Map[string]linked.List string I have no idea what that represents? What if you had a map of maps - which is a very common data structure - possibly with completely different key and value types? Really any nested data structures with multiple types would be impossible to read IMO.

Re: [go-nuts] Generics - please provide real life problems

I do believe (hope) David was kidding. Anonymous product types (and similar constructs) are the root of all evil. > On Jan 3, 2021, at 11:32 AM, roger peppe wrote: > > FWIW I'm certain that the lack of tuples in Go was a very deliberate decision > - one of Go's more significant ancestors, Limb

Re: [go-nuts] Generics - please provide real life problems

to implement “putIfAbsent” with the standard map, and the standard map does have some methods - like len() - so maybe it’s possible. If the map implementation did not implement a method it would be a runtime panic(). > On Jan 1, 2021, at 2:40 PM, robert engels wrote: > > I was thinkin

Re: [go-nuts] Re: goproxy.io was deployed in independent region in Europe and America

Btw, the original graphs came through fine for me. > On Jan 1, 2021, at 9:29 PM, not...@gmail.com wrote: > > @Amnon, I'm sorry I have no idea why the graphs are missing, > see: https://twitter.com/goproxy_io/status/1344848785726296065 > > > -- > You received this message because you are su

Re: [go-nuts] Java version of keydb

Jan 1, 2021, at 5:20 PM, robert engels wrote: > > Hi all, > > I had a opportunity to change the Java version to use memory mapped files, > using GraalVM: > > insert time 1000 records = 15443ms, usec per op 1.5443 > close time 4954ms > scan time 1934ms, usec per

Re: [go-nuts] Generics, please go away!

t; cause I have better games to play. > > > сб, 2 янв. 2021 г. в 00:50, robert engels <mailto:reng...@ix.netcom.com>>: > Those concerns are unrelated. There are plenty of frameworks in Go as well. > You can create frameworks without using inheritance. &g

Re: [go-nuts] Java version of keydb

version as well. I offer these metrics to illustrate that usually the IO algorithm is going to affect performance more than micro differences in JVM/Go/Native binaries with modern development platforms. > On Dec 26, 2020, at 5:23 PM, robert engels wrote: > > Ask and ye shall receive… >

Re: [go-nuts] Generics Error - How to fix?

Sorry, the code works as expected - as I thinking of something else. > On Jan 1, 2021, at 3:49 PM, robert engels wrote: > > But this/your code is not really using generics - it is using interfaces. The > only type check is that the instances implement fmt.Stringer - this is very

Re: [go-nuts] Generics, please go away!

ples for > students. First question Go newcomers ask on forums which framework I should > use for my application. > > > > пт, 1 янв. 2021 г. в 23:27, robert engels <mailto:reng...@ix.netcom.com>>: > You can write Java (or any other OOP with inheritance) using co

Re: [go-nuts] Generics Error - How to fix?

But this/your code is not really using generics - it is using interfaces. The only type check is that the instances implement fmt.Stringer - this is very different than the previous version. > On Jan 1, 2021, at 2:51 PM, da...@suarezhouse.net > wrote: > > Wow, you are awesome! I think this s

Re: [go-nuts] Generics - please provide real life problems

purely technical one - how to write these implementations and have them integrated into the build. > On Jan 1, 2021, at 2:18 PM, Ian Lance Taylor wrote: > > On Fri, Jan 1, 2021 at 10:25 AM robert engels wrote: >> >> To Ian’s point, what if I could declare a map that h

Re: [go-nuts] Generics, please go away!

You can write Java (or any other OOP with inheritance) using composition rather than inheritance. Much of the Java stdlib uses both. It can be argued that most usages of anonymous inner classes are composition rather than inheritance. > On Jan 1, 2021, at 1:59 PM, Space A. wrote: > > > Wait, I

Re: [go-nuts] Generics Error - How to fix?

I think the first version is far more understandable. You are declaring the Table and the types for each column - passing the type rather than instances of the type. But here is the corrected code https://go2goplay.golang.org/p/VMFOcI91i4X > On Jan 1, 2021, at 1:56 PM, da...@suarezhouse.net >

Re: [go-nuts] Generics, please go away!

I hate to chime in here, but Go by the industry accepted definition - at least based on my 30+ years experience - is that Go is clearly an OOP language. It has “instances” coupled with “behavior”. That is, given a struct instance I can call a method “on it” declared by its definition. Other OOP

Re: [go-nuts] Generics - please provide real life problems

uts > wrote: > > On Fri, Jan 1, 2021 at 8:15 AM Robert Engels <mailto:reng...@ix.netcom.com>> wrote: > Of course. But you don’t design a language (or any other product) for the 5% > - you design it for the 95 (80?} percent - if you want you have > customers/users

Re: [go-nuts] Generics - please provide real life problems

gt;> On Thu, Dec 31, 2020 at 6:51 PM robert engels wrote: > >> Go has been in existence for 10+ years and has fairly wide adoption in some >> areas - so it is not hard to make the case that generics are “not an >> important thing” > > This has been brought up in That

Re: [go-nuts] Generics - please provide real life problems

AM, 'Axel Wagner' via golang-nuts > wrote: > > On Thu, Dec 31, 2020 at 5:46 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I’ll state for the record again, I was originally very dismayed that Go did > not offer generics - after developing with it for a

Re: [go-nuts] Generics - please provide real life problems

95% was a recalled-guess. I previously linked to an academic paper that studied uses of generics in Java, and I believe that was the number - regardless it was a very, very high percentage. Interestingly, I had a previous client that was a case-study in generics gone wrong. No kidding, they had

Re: [go-nuts] Generics - please provide real life problems

Agreed. I had proposed a different approach, where the built-in map and slice could have alternative implementations chosen during make(). 95% of generics usage is collections. I think this would have retained the simplicity of Go a bit better than generics - but at the end of day - generics ar

Re: [go-nuts] Generics - please provide real life problems

I don't know how Go users can be ‘anti interface’ - literally 95% of the stdlib is based on interfaces. If you use the stdlib, you use interfaces. > On Dec 30, 2020, at 9:44 AM, Jesper Louis Andersen > wrote: > > On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com >

Re: [go-nuts] Go and AI Recommendations

I think you might be better off learning AI/ML using Python - to understand the concepts - most tutorials use Python/Colab as well since it is so easy. Once you understand the concepts you can use Go libraries  to implement the

Re: [go-nuts] [generics] Print[T Stringer](s []T) vs Print(s []Stringer)

That is not true. The generic version can have significant performance implications for low-level/tight-loop functions as it will avoid the indirection required for interface method dispatching (at the expensive of code explosion for common calls with lots of types). > On Dec 27, 2020, at 11:31

<    1   2   3   4   5   6   7   8   9   10   >