Re: [go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

handling in go... but that’s another topic. :) Sent from my iPhone > On Sep 4, 2018, at 10:45 AM, Michael Jones wrote: > > Block scope is a superpower since Algol. > >> On Tue, Sep 4, 2018 at 7:29 AM Robert Engels wrote: >> The real gotcha is this though, >> >

Re: [go-nuts] Re: What am I missing here? FYI, I'm completely new to golang xD

The real gotcha is this though, var x int if blah { x,err := somefunc() } Probably does not do what you think as the value from somefunc() will not be available outside of the if statement... This is a poor design choice by golang IMO but it is what it is... > On Sep 4, 2018, at 9:22 AM,

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

I might be able to do it if there was a “porting guide” that describes what needs to be - at least in general terms - rather than just looking at the existing code and making a guess > On Sep 7, 2018, at 10:01 AM, Robert Johnstone wrote: > > Hello, > > I would be very happy to support macOS,

Re: [go-nuts] Re: Generics as builtin typeclasses

I think the 90% rule applies… if we can have a simple solution that covers 90%, rather than a complex one to cover 100%, go with the simple. There are always trade-offs in development - having simple, easy to understand tools always wins out IMO - because greater adoption and usage is key. >

Re: [go-nuts] Re: Generics as builtin typeclasses

For the math operator, since Go already doesn’t do automatic numeric conversions, all of the operators are almost trivially implemented as methods, e.g. operator + is pseudo generic interface - not really required type PlusOperator interface { Plus(A) A } and given type MyStruct

Re: [go-nuts] Operator Overloading Implies Generics?

I think the lack of method overload is a poor choice. A simple review of the stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you have complex structs as parameters, then the naming because really long… and the fact that you don’t have file level hiding, means even for

Re: [go-nuts] Operator Overloading Implies Generics?

as able to auto disambiguate in just these cases. > > > > On Sun, Sep 9, 2018 at 6:43 AM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I think the lack of method overload is a poor choice. A simple review of the > stdlib shows a lot of XFromInt XFromUn

Re: [go-nuts] Re: Generics as builtin typeclasses

Which is why I believe this can happen with existing interfaces and compiler magic. (along with my other proposal regarding carrying the concrete type in slices). You can do operator overloading and type conversion with interfaces. (although not a big fan of operator overloading…) Method

Re: [go-nuts] Operator Overloading Implies Generics?

, but even with Java it is not ambiguous, as the JLS states it will use the most specific method possible, so the single parameter one when only a single parameter is passed. > On Sep 9, 2018, at 10:37 AM, Sam Whited wrote: > > > > On September 9, 2018 1:43:09 PM UTC, robert e

Re: [go-nuts] Re: Generics as builtin typeclasses

018, at 1:52 PM, Jonathan Amsterdam wrote: > > > > On Saturday, September 8, 2018 at 11:58:46 PM UTC-4, Robert Engels wrote: > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as >

[go-nuts] Go concurrency performance

Hi, I posted this to golang-dev, and the consensus seems to be this is a better forum to address the issue? Anyway, you can review the project https://github.com/robaho/go-concurrency-test The readme.md details the experiment. It does some analysis of the Go concurrency primitives, in the

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

“wouldn’t be that hard" > On Sep 10, 2018, at 1:24 PM, robert engels wrote: > > I wonder about the design, and how it will work. Since it uses the native > components behind the scene, you will get great fidelity but the layout can > be very difficult to accomplish. >

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

, you should have most of the difficult work done. The next > steps will be to port over the controls one-by-one, but the infrastructure > will be in place, so that work con be done a small piece at a time. > > Let me know if that helps, or if you have any other questions. > > R

Re: [go-nuts] "Craftsman's" Go Generics proposal

zarnecki wrote: > > On Mon, 10 Sep 2018 15:31:41 -0500 > robert engels wrote: > >> You would probably have simpler code just define an interface Value(), and >> a ComplexValue() and two methods… > ...and implement it on any single type I wanna sum? No, thanks. I

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > wrote: > > [golang-nuts to CC, golang-dev to BCC] > > On Mon, Sep 10, 2018 at 5:33 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > In the entire codebase of Docker I could find only o

Re: [go-nuts] Constraints for generics

that your, or proposals like it, will never be accepted. There’s just not enough added value for the primary use cases. > On Sep 30, 2018, at 1:09 PM, Wojciech S. Czarnecki wrote: > > On Sun, 30 Sep 2018 10:18:25 -0500 > robert engels wrote: > >> Yes, it is a very similar

Re: [go-nuts] Error Handling Best Practice (error wrapping)

Yes, lobby to have Go2 include exceptions and then you don’t need to worry about any of this... :) > On Oct 8, 2018, at 5:38 AM, Chris Hopkins wrote: > > Hi, > Could I please check what current error handling best practice is? > I've gotten quite smitten with github.com/pkg/errors. I really

Re: [go-nuts] Error Handling Best Practice (error wrapping)

I read the proposal and the only knock against including a stack trace by default is one google problem cited that was clearly bad error handling to begin with. Why is there always some need to reinvent the wheel. Leave Go error handling as in and add a throws and catch that new code can use,

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

As long as the passwords are not stored in plain text in memory - meaning they are only temporarily decoded in order to be provided (and then the memory wiped) - there is no difference than the underlying security of the file encryption on disk, no ? > On Oct 15, 2018, at 4:13 PM, Christopher

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

as I know - even ‘keychain access’ in osx (used in millions of systems) would be subject to similar hack to if root was available and memory could be scanned. > On Oct 15, 2018, at 4:58 PM, Christopher Nielsen wrote: > > On Mon, Oct 15, 2018 at 2:17 PM robert engels <mailto:reng...@i

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

it does what it promises, then it would likely make the > application more secure. > > On Monday, October 15, 2018 at 9:18:18 PM UTC, robert engels wrote: > As long as the passwords are not stored in plain text in memory - meaning > they are only temporarily decoded in order to b

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

, and then you are back to the same problem of compromising passwords when root access has been compromised). > On Oct 15, 2018, at 6:25 PM, robert engels wrote: > > Maybe, but still, if they have root access to your machine, they can just as > easily alter the accessing binary to send

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

t 4:33 PM robert engels wrote: >> >> To clarify, this is for a hardware device that protects a local resource - a >> network based protocol that challenges the device for access is a different >> story, and yes, when properly implemented is secure (unless someone steal

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

a trade-off. > On Oct 15, 2018, at 6:04 PM, Christopher Nielsen wrote: > > On Mon, Oct 15, 2018 at 3:10 PM robert engels wrote: >> >> Exactly - and systems do not typically have this - yet are considered >> secure. If the plain text is ever avail

Re: [go-nuts] Re: Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

Oct 15, 2018, at 7:12 PM, Christopher Nielsen wrote: > > On Mon, Oct 15, 2018 at 4:33 PM robert engels wrote: >> >> To clarify, this is for a hardware device that protects a local resource - a >> network based protocol that challenges the device for access is a differe

Re: [go-nuts] Regarding contracts

), and then hope the implementation never changes… That’s a lot of hoping. > On Oct 18, 2018, at 11:08 AM, Burak Serdar wrote: > > On Thu, Oct 18, 2018 at 10:03 AM robert engels wrote: >> >> Right, that is a big limitation - that means that internal details must be >>

Re: [go-nuts] Regarding contracts

> On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote: > > If X is a struct type, any type implementing all the methods of X and >containing all the fields of X can be substituted The above is the problem. This almost certainly requires dynamic access to fields, essentially making all

Re: [go-nuts] Regarding contracts

AM, Burak Serdar wrote: > > On Thu, Oct 18, 2018 at 8:53 AM Robert Engels wrote: >> >> >> >>> On Oct 18, 2018, at 9:41 AM, Burak Serdar wrote: >>> >>> If X is a struct type, any type implementing all the methods of X and >>> con

Re: [go-nuts] Regarding contracts

pointers in the elements - not if you want safe code - but it was just used an example of the abuse that will occur. > On Oct 18, 2018, at 10:56 AM, Burak Serdar wrote: > > On Thu, Oct 18, 2018 at 9:37 AM robert engels <mailto:reng...@ix.netcom.com>> wrote: >> &

Re: [go-nuts] Regarding contracts

- hard to determine as a developer - easily anyway. > On Oct 18, 2018, at 8:09 AM, Burak Serdar wrote: > >> On Thu, Oct 18, 2018 at 6:35 AM Robert Engels wrote: >> >> I meant to say contract not interface. Also as a user of said generic >> routine how do I kn

Re: [go-nuts] Command line password manager using AES symmetric key encryption, Argon2 KDF, Key-Agent and Keepass importer

ch is essentially a a poor person's HSM. > On Mon, Oct 15, 2018 at 7:21 PM robert engels wrote: >> >> That is not true. If you lose the key, anyone else can use the device - >> which is why there is usually an additional requirement beyond the hardware >> k

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

The easiest solution is that []int IS A IntList by definition, no ? Meaning that an “slice” has defined methods Len(), and At(). I would personally define other methods on slice too for convenience (like, Insert, Delete). The [] notation is just syntactic sugar for slice.At(). When used as a

Re: [go-nuts] Regarding contracts

Can you explain this a bit more, I must be missing something. Using the example: func F(a,b type T like(int,X)) { if a On Oct 18, 2018, at 2:13 PM, bjorn.de.me...@gmail.com wrote: > > I don't think this is fear, but rather KISS. The reason many people dislike > contracts from the official

Re: [go-nuts] Regarding contracts

more verbose - but it avoids the traditional problems with operator overloading leading to obtuse code. > On Oct 18, 2018, at 2:28 PM, Burak Serdar wrote: > > On Thu, Oct 18, 2018 at 1:22 PM robert engels wrote: >> >> Can you explain this a bit more, I must be mis

Re: [go-nuts] Why doesn't this benchmark test end?

No, think about it... If the setup time is 1 minute per iteration, and the timed activity is 1 usec per iteration, then in order to time for 1 second the test would need to run for a million minutes…. You need to restructure the test to avoid the setup on every test invocation. > On Oct 22,

Re: [go-nuts] Re: do you use binary-only packages?

I think there is a bigger concern than shipping binaries. I believe that the Go stdlib and runtime should be shipped as a shared library, and be field upgradable independent of the binaries. This is the only reasonable way to to distribute security patches in an efficient and stable manner.

Re: [go-nuts] Re: do you use binary-only packages?

nce Taylor wrote: > >> On Mon, Oct 22, 2018 at 7:18 PM, robert engels wrote: >> >> I think there is a bigger concern than shipping binaries. I believe that the >> Go stdlib and runtime should be shipped as a shared library, and be field >> upgradable independe

Re: [go-nuts] Failed iterator proposals?

I am sure it has been discussed, but why the aversion to using < > in type declarations? I guess I just don’t understand using bracketing notations that are already used for something else. When I see [] I can immediately see - ah, slice/map reference. When I see () I can immediately see - ah

Re: [go-nuts] Regarding contracts

October 2018 21:51:35 UTC+2, robert engels wrote: >> I guess I don’t understand the problem with using “method names” e.g. Less() >> in generic code - yes it is a little more verbose - but it avoids the >> traditional problems with operator overloading leading to obtuse code. >

Re: [go-nuts] Python heapq.merge in golang using channels?

I don’t think that is correct. If the channels provide sorted async data - you need to have a value available at every channel in order to produce a sorted merged. The consumer needs to wait until every channel has supplied a value. Otherwise - imagine 2 channels A,B. A provides 5, B has not

Re: [go-nuts] Regarding contracts

I think the problem with the proposal is that it is going to be very hard for the compiler to know all of the operations a type can perform since for concrete types the methods can be spread across multiple files. With an interface it is only declared in a single location. > On Oct 18, 2018,

Re: [go-nuts] Regarding contracts

to be an interface. > On Oct 18, 2018, at 7:21 AM, Robert Engels wrote: > > I think the problem with the proposal is that it is going to be very hard for > the compiler to know all of the operations a type can perform since for > concrete types the methods can be spread across

Re: [go-nuts] Temporary files in go

I think a more “standard” and certainly portable way to do this is with a tmp file, and a rename/move at the end - along with a clean-up of tmp at application start (if worried about crashes). Using the proper file and process permissions on the tmp file - since you need these to protect the

Re: [go-nuts] Go language should become an ANSI and ISO standard.

This may be of interest https://www.computer.org/csdl/proceedings/hicss/2001/0981/05/09815015.pdf > On Oct 13, 2018, at 12:18 PM, alanfo wrote: > > May I remind those who are in favor of Go standardization that Java and > Python have never been standardized by ISO/ANSI/ECMA but that hasn't >

Re: [go-nuts] Temporary files in go

Which is not Windows, which is giving up a lot of options, and is important to some people, where as just using tmp files is ok. I am not even sure if windows supports deleting an open file yet. > On Oct 12, 2018, at 3:09 AM, Beoran wrote: > > linkat() and openat() are posix 2008 standard

Re: [go-nuts] interface array and ... operator

But it is the varadic one that works according to OP. > On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha wrote: > > > why does A() not work while B works here, > > https://play.golang.org/p/59bpr8TCIge > > Type mismatch. The

Re: [go-nuts] interface array and ... operator

ble to > interface{}. this is fine. The function B() is assigning a []interface{} to > the variadic of ...[]string. Since interface{} is not assignable to string, > this is not allowed. > > Hope that clarifies. > > > On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, R

Re: [go-nuts] Go 2 Proposal Comments

patches. You will probably pay a performance hit due to lack of inlining, but for a large class of applications this would be a easy trade-off to make to simplify security handling. > On Oct 24, 2018, at 11:26 AM, Burak Serdar wrote: > > On Wed, Oct 24, 2018 at 10:21 AM robert enge

Re: [go-nuts] Go 2 Proposal Comments

addition of ‘var’ - but don’t get me started on what it happening with Java now - I think there are very different forces at work than the founding principles. > On Oct 24, 2018, at 11:12 AM, Burak Serdar wrote: > > On Wed, Oct 24, 2018 at 9:59 AM robert engels <mailto:reng...@ix.netcom

Re: [go-nuts] Go 2 Proposal Comments

Btw, for those that are interested, enum was added in Java5, the same time they added generics. It constituted the 3rd revision to the JLS. > On Oct 24, 2018, at 11:39 AM, robert engels wrote: > > Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply > to G

[go-nuts] Go 2 Proposal Comments

I'd like to offer a few comments on Ian's https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md Since the author admits the least amount of experience with Java, maybe my facts, and many

Re: [go-nuts] interface array and ... operator

erface{} to the variadic of ...[]string. Since interface{} is not assignable to string, this is not allowed. > On Oct 24, 2018, at 11:08 AM, Jan Mercl <0xj...@gmail.com> wrote: > > Nobody said that. > > On Wed, Oct 24, 2018, 18:04 robert engels <mailto:reng...@ix.netc

Re: [go-nuts] Re: do you use binary-only packages?

Is there documentation on how to do this, or was I misunderstanding your answer? Thanks. > On Oct 22, 2018, at 10:53 PM, Robert Engels wrote: > > Wait... you can ship a Go binary that dynamically links with the Go runtime > and stdlib at runtime??? Awesome. Can you point me

Re: [go-nuts] New keywords and backwards compatibility

I like the idea. Simple. I think the go documentation needs to have similar @Since annotations like Java. I would also strongly suggest no breaking APIs - ever... > On Oct 24, 2018, at 2:14 PM, Ian Denhardt wrote: > > Hey all, > > Today I've seen a lot of messages re: concerns about adding

Re: [go-nuts] Re: do you use binary-only packages?

Thanks. I have a better understanding of the situation after reading the reference. Sent from my iPhone > On Oct 23, 2018, at 4:53 PM, Ian Lance Taylor wrote: > >> On Tue, Oct 23, 2018 at 2:11 PM, Robert Engels wrote: >> >> So are there any plans for security pa

Re: [go-nuts] Re: do you use binary-only packages?

018, at 9:36 AM, Ian Lance Taylor wrote: > >> On Mon, Oct 22, 2018 at 8:53 PM, Robert Engels wrote: >> >> Wait... you can ship a Go binary that dynamically links with the Go runtime >> and stdlib at runtime??? Awesome. Can you point me to the docs on this. I’ve >>

Re: [go-nuts] websocket implentation in golang

You can look at github.com/robaho/go-trader See webserver.go and book.js In this case, the server sends updates (market changes) to the subscribed clients unsolicited, but on an interval (so rapid changes on the server don’t flood the network). I believe

Re: [go-nuts] Re: Go 2 Proposal Comments

PM, Scott Cotton wrote: > > > >> On Sunday, 28 October 2018 15:31:54 UTC+1, Robert Engels wrote: >> To clarify, think of the performance improvements in the GC in Go from 1.1 >> to 1.11. Amazing. But you only get these via recompiling which is a barrier. >> Ma

Re: [go-nuts] Re: Go 2 Proposal Comments

sing Java > analogy: the current Java is 11 being compatible with Java 1). > > Last, I don't remember life was that difficult prior to Java. Backward > compatibility was not Java invention. Many languages back then were already > backward-compatible in a reasonable way. The major lib

Re: [go-nuts] Re: Go 2 Proposal Comments

packaging Go binaries with dynamic linkage to the runtime and stdlib. Sent from my iPhone > On Oct 28, 2018, at 9:23 AM, Robert Engels wrote: > > Cool. Not sure why the JVM is not applicable to the discussion as it normally > ensures binary compatibility as languages evolve. >

[go-nuts] Go Performance

Hello Gophers, I’ve been chastised in the past regarding some of my Go performance tests - using Java as a baseline. In most of these micro-benchmarks Go has performed more poorly than expected. So, I ported nats (https://nats.io ) message broker (which is written in Go) to

Re: [go-nuts] Re: Go 2 Proposal Comments

; relevant. > > Scott > > >> >> On Sun, 2018-10-28 at 07:31 -0500, Robert Engels wrote: >> > Next thing Gophers will be crying for is lambda syntax... just wait. > > -- > You received this message because you are subscribed to the Google Grou

Re: [go-nuts] How to get current goroutine id?

I agree. I’ve read the arguments against thread-local (or goroutine local storage), and the passing of Context everywhere instead. It doesn’t make sense to me. Even a simple runtime.GetGoID() that returned a unique int would allow the design of much simpler server software. But I don’t think

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

just opinions. cross-platform GUIs suffer from the wrong >> incentives Ian pointed out. Also, in these days, GUIs are more and more >> integrated with platform specific organisation of services such as security, >> accessibility, ... I'm not a windows user so I can't say much abo

Re: [go-nuts] json.Marshal

Capital Letters = export > On Nov 1, 2018, at 9:22 AM, Alex Dvoretskiy wrote: > > No, no need to export, unless fields have weird names. Fields must be with > capital letters: > > https://play.golang.org/p/zMeKqW-4JT9 > > On Wednesday, October 31, 2018 at 11:12:05 PM UTC-7, kortschak wrote:

Re: [go-nuts] Correct way to solve slice of interface type problem

8 at 8:35:39 PM UTC-4, Justin Israel wrote: > > > On Wed, Oct 31, 2018 at 1:32 PM robert engels > wrote: > I have argued for a runtime/built-in to do this - it is so common…. (if doing > “kind of OO” in Go) > > I would love to have the ability to do it with built-in su

Re: [go-nuts] Correct way to solve slice of interface type problem

If you use interface based design it is repeated through out the code with no way to write a performant generic method. I am not a big fan of ‘reduced lines of code’ creating obscurity the hallmark of Go. In this case I think being able to pass a slice as an read only [] of interface makes

Re: [go-nuts] Go Performance

“fibers” library for light-weight threads, but that’s not standard Java either. > On Oct 30, 2018, at 3:46 PM, robert engels wrote: > > Btw, the math was off here, with 3 million vs. 5 million ops a second (and > these are essentially IO ops - sending messages to the broker), the

Re: [go-nuts] Re: Go Performance

To achieve similar performance numbers as reported, the resident Java memory size was 96 MB, while the Go was 14 MB. Again very impressive for Go. > On Oct 30, 2018, at 8:11 AM, Robert Engels wrote: > > I will do so and report back. > > On Oct 30, 2018, at 8:03 AM, T L

Re: [go-nuts] Re: Go Performance

> OP really should compare the memory consumptions of the Java version and Go > version. > > On Monday, October 29, 2018 at 4:53:52 PM UTC-4, robert engels wrote: >> >> Hello Gophers, >> >> I’ve been chastised in the past regarding some of my Go perfor

Re: [go-nuts] Go Performance

I’ve written lots of network service code. I understand what’s available. Actually, for a small number of clients threads are faster than async/nio. In this case there is only a single active thread during the test. The main benefit of using nio is that you can avoid the java space to native

[go-nuts] Re: Go Performance

under Shenandoah) has Java pulling slightly ahead in terms of average and min latency, with: latency avg 178187 min 150741 max 892040 Still can’t touch Go in terms of max due to the extremely low pause times I am assuming. > On Oct 29, 2018, at 3:53 PM, robert engels wrote: > >

Re: [go-nuts] Re: Go Performance

uesday, October 30, 2018 at 1:03:13 PM UTC, T L wrote: >> OP really should compare the memory consumptions of the Java version and Go >> version. >> >> On Monday, October 29, 2018 at 4:53:52 PM UTC-4, robert engels wrote: >>> >>> Hello Gophers

Re: [go-nuts] Re: Go Performance

his doesn't mean that something is more or less performant than the > other. > > > понедельник, 29 октября 2018 г., 23:53:52 UTC+3 пользователь robert engels > написал: > Hello Gophers, > > I’ve been chastised in the past regarding some of my Go performance test

[go-nuts] Re: Go Performance

Btw, if anyone is running comparison tests. I used a 3.4 ghz iMac with i7 (4 cores, 8 threads). The tests were all on the local machine (no physical networking involved). With both Go and Java, the CPU appears to be saturated - which is expected. > On Oct 29, 2018, at 3:53 PM, robert eng

Re: [go-nuts] Go Performance

Btw, the math was off here, with 3 million vs. 5 million ops a second (and these are essentially IO ops - sending messages to the broker), the difference is 0.13 microsecs per op - or 130 nanos. Pretty insignificant for IO based tasks. > On Oct 30, 2018, at 8:10 AM, Robert Engels wr

Re: [go-nuts] database for protobuf - profanedb or similar

cockroachdb is in Go and uses protobuf to communicate - but it provides pre-built easy to use clients for many languages. > On Oct 30, 2018, at 1:48 PM, Tharaneedharan Vilwanathan > wrote: > > Hi All, > > I am looking for a database for protobuf, preferably the one that fits Go >

Re: [go-nuts] database for protobuf - profanedb or similar

Just to learn Go, and do some performance tests. I had been a contributor to the Lucene project way back when, so the idea of doing a kv using LVM trees seemed like a good project - small enough in scope, but useful. I only brought it up because it is simple enough that if you want to learn Go

Re: [go-nuts] Correct way to solve slice of interface type problem

I have argued for a runtime/built-in to do this - it is so common…. (if doing “kind of OO” in Go) > On Oct 30, 2018, at 7:30 PM, Justin Israel wrote: > > > > On Wed, Oct 31, 2018 at 11:21 AM > wrote: > Hello, everyone. > Consider following code: > > package

Re: [go-nuts] database for protobuf - profanedb or similar

ho/keydbr> > On Oct 30, 2018, at 2:09 PM, robert engels wrote: > > cockroachdb is in Go and uses protobuf to communicate - but it provides > pre-built easy to use clients for many languages. > >> On Oct 30, 2018, at 1:48 PM, Tharaneedharan Vilwanathan > <mailto:vd

Re: [go-nuts] Correct way to solve slice of interface type problem

ote: > > > > On Wed, Oct 31, 2018 at 1:32 PM robert engels <mailto:reng...@ix.netcom.com>> wrote: > I have argued for a runtime/built-in to do this - it is so common…. (if doing > “kind of OO” in Go) > > I would love to have the ability to do it with built-in sup

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

Never mind I found the ForkJoinPool. > On Oct 25, 2018, at 6:22 AM, Robert Engels wrote: > > I see the pattern used in ErrGroup pipeline a lot: > > c := make(chan result) const numDigesters = 20 for i := 0; i < numDigesters; > i++ { > which leads me to qu

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

I see the pattern used in ErrGroup pipeline a lot: c := make(chan result) const numDigesters = 20 for i := 0; i < numDigesters; i++ { which leads me to question the effectiveness of this design. Sure, you bound the number of routines, and this should probably be something like cores * 2, but

Re: [go-nuts] Re: Go 2 Proposal Comments

OK, you got me, I’m sucked in - it was a nice balance of yes, BUT no. First, there is simply no debate, Java += Android, and you have the most successful language/platform ever. NO debate. Arguing against Java’s write-once, run anywhere implementation is a bad position to take. Yes, if you

Re: [go-nuts] interface array and ... operator

No need. I was just getting very confused trying to follow. > On Oct 25, 2018, at 10:59 AM, jake6...@gmail.com wrote: > > Yes. I was completely mistaken in my post. Apologies. > >> On Wednesday, October 24, 2018 at 12:14:36 PM UTC-4, robert engels wrote: >> I quo

Re: [go-nuts] Re: Go 2 Proposal Comments

with managed memory and no pointers and that is all, Go and the world would end up in a better place. Stop trying to make Go something that it isn’t. Square pegs, round holes, yada yada yada... > On Oct 26, 2018, at 11:27 PM, Burak Serdar wrote: > > On Fri, Oct 26, 2018 at 9:32 PM robe

Re: [go-nuts] Failed iterator proposals?

Wouldn’t you normally pass a consumer or collector function into the interator code? Then you only write the iterator once, and it is hidden. Similar to how the sync.Map.Range() works. Barring that, I don’t see how for(i:=c.Iterator();i.HasNext();) { v := i.Next() } is that much more

Re: [go-nuts] Failed iterator proposals?

018, at 2:52 PM, Eric S. Raymond wrote: > > robert engels : >> Wouldn’t you normally pass a consumer or collector function into the >> interator code? Then you only write the iterator once, and it is hidden. > > I'll look into that approach. There might be a readability

Re: [go-nuts] Go 2 Proposal Comments

different than yours is pretty rude. > On Oct 27, 2018, at 3:52 AM, Wojciech S. Czarnecki wrote: > > On Wed, 24 Oct 2018 10:59:12 -0500 > robert engels wrote: > >> If you head back to the genesis time of Java, > > Can you get all this Java babble out of the

Re: [go-nuts] IO memory issue in golang

Where is the panic listing? Sent from my iPhone > On Nov 4, 2018, at 2:28 AM, Aditya Giri wrote: > > I have 3 crons running in my application in production. 1st cron fetched > around 10k data and started to process. While the second cron tried to fetch > data and process it, IO memory issue

Re: [go-nuts] Go Performance

for concurrent “small IO” operations, and allows developers to write highly performant IO code in a very straight-forward manner. A job well done to the Go team! > On Nov 1, 2018, at 11:31 AM, robert engels wrote: > > Just an update for those who may be interested. > > With so

Re: [go-nuts] Re: Go 2 Proposal Comments

mpiler and build. > There is no need for version annotation and you have less maintenance for the > current compiler. > > On Sunday, October 28, 2018 at 5:40:23 AM UTC+7, robert engels wrote: > As others pointed out, this was not true when ‘enums’ were added, but still > th

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

This is the cross I was referring to https://github.com/fyne-io/fyne > On Oct 27, 2018, at 4:30 PM, Ian Lance Taylor wrote: > > On Sat, Oct 27, 2018 at 7:02 AM, Space A. wrote: >> >> I wish go2 team would focus on cross-platform GUI rather than

Re: [go-nuts] Static assert at compile time

I don’t think it is possible in any language - I think it is a very of the halting problem https://en.wikipedia.org/wiki/Halting_problem unless you are referring to checking a constant ? > On Oct 27, 2018, at 5:07 PM, hay wrote: > > Hi, > >

Re: [go-nuts] Go 2 Proposal Comments

ut “almost entirely” would probably make it not by much :) > On Oct 27, 2018, at 4:23 PM, Ian Lance Taylor wrote: > > On Sat, Oct 27, 2018 at 1:53 PM, Wojciech S. Czarnecki > wrote: >> On Sat, 27 Oct 2018 08:52:26 -0500 >> Robert Engels wrote: >> >>&

Re: [go-nuts] Re: Go 2 Proposal Comments

As others pointed out, this was not true when ‘enums’ were added, but still the Java compiler has always supported compiling using old version constructs. In the case of enums it was binary compatible. I think Ian’s proposal on the comment build flag to specify the language version is a good

Re: [go-nuts] Re: gomobile: what's the right way to make widgets?

I’m away from computer right now but the latest one that was posted about here seems very well done and looks decent as well. Sent from my iPhone > On Oct 27, 2018, at 9:34 AM, Gerald Henriksen wrote: > >> On Sat, 27 Oct 2018 07:02:46 -0700 (PDT), you wrote: >> >> I wish go2 team would

Re: [go-nuts] Re: Go 2 Proposal Comments

What exactly are you referring to? I wasn’t aware of Android no longer being Java. But also when I say java am referring to the JVM technology as well, so add in all of the JVM languages and it’s even more lopsided. Sent from my iPhone > On Oct 27, 2018, at 9:31 AM, Gerald Henriksen wrote: >

Re: [go-nuts] Re: Go 2 Proposal Comments

at 11:32:10 PM UTC-4, Robert Engels wrote: >> First, there is simply no debate, Java += Android, and you have the most >> successful language/platform ever. NO debate. > > Er, I can argue that VisualBasic + Windows is the most successfull but I have > no dog in that hun

Re: [go-nuts] Regarding contracts

Agreed, the following is where the disconnect is > On Oct 20, 2018, at 10:40 AM, Ian Denhardt wrote: > >> // Do we need LinkedList(T)? Maybe not.. >> func (l *LinkedList) Add(n *Node) { >> n.next=nil >> if l.head==nil { >>l.head=n >> } else { >>l.head.next=n >> } >> } if I declare

  1   2   3   4   5   6   7   8   9   10   >