[go-nuts] Error Handling Proposal(s)

Is there a thread on proposals on error handling (with any chance to be worked on, by the Go team)? Found this one by Russ Cox, but couldn't find any active threads on GitHub

[go-nuts] Suppress Warning in VSCode

This is a simple snippet for writing BDD-style tests in go. When the package support is imported in the tests for another package, vscode shows a warning composite literal uses unkeyed fields. How to suppress this message? What

[go-nuts] Code Quality CLI Tool for Churn vs Complexity

Is there any code quality CLI tools for Churn vs Complexity? (which provides the same functionality as codeclimate service, but off-line, as a single command-line program - there are some nice tools like golangci-lint and gocyclo, but they do not provide this functionality) -- You received

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

ving these facts in mind, the way the proposal implements generics is all about clearer piping of functionality - not building towers of functionality. On Thursday, December 24, 2020 at 8:43:35 AM UTC+1 wilk wrote: > On 23-12-2020, Kaveh Shahbazian wrote: > > --=_Part_8328_927921797.16087

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

Axel provided good insights about the history and the big picture of generics. Since the beginning, not having generics was not a goal - or a promise. >From Computer Science - Brian Kernighan on successful language design : "Perl's time has passed because

[go-nuts] Re: 3 part write up on C# vs Golang performance

The efficient use of memory in Go makes it an interesting option for serverless services. There is no comparison in start-up time in the posts - just guessing here also Go might do a bit better. Also, the initial stack size for goroutines seems to be 2 KB now, not 8 KB ( source

[go-nuts] Snake, Kebab, Camel, Pascal Case Conversion

caseconv is a Go Module for string case conversion - snake, kebab, camel, pascal cases. Please open an issue if you have found any bugs. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from

[go-nuts] Re: Any embedded scripting language for Go

If you like using/trying one from lisp family, there is also Zygo . On Wednesday, October 21, 2020 at 7:33:16 AM UTC+2 aravind...@gmail.com wrote: > Hi, > > I am looking for a way to build interactive app,where user will be giving > instructions to draw

[go-nuts] Re: "eg tool" for modules

Update: The eg refactoring tool does support modules - for the case that I used it for. There was a mistake on my side before. On Monday, August 10, 2020 at 5:52:49 PM UTC+2 Kaveh Shahbazian wrote: > There is a related issue <https://github.com/golang/go/issues/24661>, on &g

Re: [go-nuts] [ generics] Moving forward with the generics design draft

I am excited about sum-types as much as generics themselves. Also, it's nice that any is a keyword restricted to be used inside the type parameter declaration as a type constraint. Very nice! --- P.S. Of-course now the proposal seems to go with brackets. Nevertheless, I wrote this comment

[go-nuts] Re: Generics and parentheses

After playing in generics playground with a dozen of cases that came to my mind, IMHO brackets seem to be more clear than parentheses for declaring type parameters. Also using the type keyword before the type parameter reduces the cognitive load drastically. type StateFn[type T] func(T)

[go-nuts] Re: "eg tool" for modules

There is a related issue <https://github.com/golang/go/issues/24661>, on Go GitHub repository, tracking support for modules. On Sunday, August 9, 2020 at 12:23:12 AM UTC+2 Kaveh Shahbazian wrote: > The "eg" tool - from Go Tools <https://github.com/golang/tools> > Re

[go-nuts] "eg tool" for modules

The "eg" tool - from Go Tools Repo/Module - does not support Go Modules. 1 - Is there an alternative example-based refactoring tool, that provides the same functionality? 2 - Are there any plans to support Go Modules by "eg" tool? P.S. The *astutil*

Re: [go-nuts] Error Handling in Go 2

ue/pattern*. Which leads to more clear code. For anything more complicated (in terms of conditions for handling the error), we have to write the more complicated solution. On Thursday, July 30, 2020 at 5:46:39 AM UTC+2 Ian Lance Taylor wrote: > On Wed, Jul 29, 2020 at 7:46 AM Kaveh Shahba

[go-nuts] Error Handling in Go 2

Go can already pass/pipe the result of a function, which returns multiple values, to another function, which accepts the same values as arguments. A similar mechanism can be used for handling errors, by passing/pipe them to a special construct. Now, assume we have a function named funcCtx:

Re: [go-nuts] Go 2018 Survey "Error handling 5%"

Go can already pass/pipe the result of a function, which returns multiple values, to another function, which accepts the same values as arguments. Now, assume we have a function named funcCtx: func funcCtx() (res int, err error) { // ... } Having that, these does not look that ugly: func

[go-nuts] Re: Generics and parentheses

Proposals that employ the type keyword, look more Go-ish. Go is already doing many things differently than other PLs in C-ish family - the if without parentheses and no semicolon are two of things that hit most when switching frequently between Go and another PL. func SomeContext() { var

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

Thank you, I didn't know about this attack (of-course I need to spend some time to understand it). -- 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

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

I was already familiar with the behavior of ordering. The part that was new for me, was the missing map entries. Which of-course was documented - provided by Paul. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

Re: [go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

Thank you Paul, On Tuesday, May 26, 2020 at 7:37:34 AM UTC+2, Paul Jolly wrote: > > > Why the output of this code is nondeterministic? > > See https://golang.org/ref/spec#For_statements, specifically the "For > statements with range clause" subheading, specifically this bullet: > > > 3. The

[go-nuts] Nondeterministic Behavior of for Loop Ranging Over a map

Why the output of this code is nondeterministic? Go Playground package main import ( "fmt" ) func main() { series := make(map[int]int) series[0] = 0 i := 1 for k, v := range series { fmt.Println(k, v) if i < 10 {

[go-nuts] Re: Go 1.14 Release Candidate 1 is released

> > "Goroutines are now asynchronously preemptible." Very nice! "A consequence of the implementation of preemption is that on Unix systems, > including Linux and macOS systems, programs built with Go 1.14 will receive > more signals than programs built with earlier releases. This means that

[go-nuts] Re: Inject Mock Instead of Actual Implementation in Tests, Using "wire"

It is inside the documentation of wire - I should read it more carefully: here <https://github.com/google/wire/blob/master/docs/best-practices.md#mocking>. On Saturday, April 13, 2019 at 6:25:12 PM UTC+2, Kaveh Shahbazian wrote: > > BTW I am aware that some build tag tricks

[go-nuts] Re: Inject Mock Instead of Actual Implementation in Tests, Using "wire"

BTW I am aware that some build tag tricks can be used to achieve this. I was wondering it there is an idiomatic way or any best practices for using wire. On Saturday, April 13, 2019 at 3:19:58 PM UTC+2, Kaveh Shahbazian wrote: > > Assume wire is going to be used for dependency injectio

[go-nuts] Inject Mock Instead of Actual Implementation in Tests, Using "wire"

Assume wire is going to be used for dependency injection here. And we have a provider function called NewService that returns an interface. There is the actual implementation for that interface that - for example - connects to PostgreSQL. And we have also the mock for that interface. Now we

Re: [go-nuts] Go Modules And Sub-Packages

> > Honest question, what do you mean by sub-package? > I do not know what is the official phrase here. But to me the example is quite clear. To break it down further, assuming the module is at version 3.1.9, how should we import package2 inside package1? For example should the import path be

[go-nuts] Go Modules And Sub-Packages

How do you use Go modules with sub-packages? Do you use relative path for them? If you use *replace* directive in go.mod file, how do you manage the version? Example: .../github.com/user/package1 .../github.com/user/package1/package2 .../github.com/user/package1/package3

[go-nuts] Go Module File

Where can I find the complete reference for Go module files (go.mod)? I am particularly interested in getting fluent in using local packages/sub-packages and also redirecting import paths - for example for times I need to use a fork. -- You received this message because you are subscribed to

[go-nuts] Re: named go routines?

Go's concurrency is based on CSP (communication sequence process), not Actor Model. Hence you can have channels and manage all the communications through channels. For this, there is no need for named actors - unlike the actor model, where all communications are managed via mailboxes. These

Re: [go-nuts] Go Module Vesion and Git Tags

Thanks! Apparently it works now. And I am a bit confused now since version is part of both the path and the version and it has to be imported like "github.com/dc0d/farsi/v2/calendar". But I guess understanding that is my homework - it just feels a bit odd! -- You received this message

Re: [go-nuts] Go Module Vesion and Git Tags

Sure! This is the module that is being imported: https://github.com/dc0d/farsi And the consumer app: package main import ( "fmt" "github.com/dc0d/farsi/calendar" ) func main() { fmt.Println(calendar.IranNow()) } And its go.mod file: module draft require github.com/dc0d/farsi

[go-nuts] Go Module Vesion and Git Tags

A required modules is added to my go.mod file with version v2.0.0 - which I expect to give me the v2.1.0. But after running go mod tidy the version inside go.mod file becomes v0.0.0-20180902075018-e96d84f0b065. The project is public on GitHub and has tags v1.0.0, v2.0.0 and v2.1.0. What am I

[go-nuts] Re: go mod tidy fails with latest version of a module

Got help on the matter. Problem is with echo itself. After v3.2.2 they have dropped the letter v from tags. -- 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] Re: go mod tidy fails with latest version of a module

echo has a version v3.1.0-rc.1 with a not standard format. That's why it works with v3.0.0+incompatible. Or at least that's my guess. -- 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

[go-nuts] go mod tidy fails with latest version of a module

With this line in go.mod: require github.com/labstack/echo v3.3.5 For go mod tidy it fails with: go: finding github.com/labstack/echo v3.3.5 go: errors parsing go.mod: /home/path-to/draftmod/go.mod:6: invalid module version "v3.3.5": unknown revision v3.3.5 But if the line get changed to:

Re: [go-nuts] Re: Nil Channels and Case Evaluation

I did not say anything is incorrect. But the error message (no cases) is confusing and unclear because obviously there is a case there. Something like all channels of cases are nil is more clear or some other more proper/clear message. -- You received this message because you are subscribed

Re: [go-nuts] Re: Nil Channels and Case Evaluation

According to this thread, for this program: package main func main() { var c chan struct{} select { case c <- f(): } } func f() struct{} { println("f called") return struct{}{} } The error message in the output: f called fatal error: all goroutines are asleep -

[go-nuts] Re: New Embedded Document Database (Alpha)

> > Badger provides multi-key transactions, so any high level logic may use it. > > Already doing that. It requires you expose your own transactions that use Badger's one. > It will be sick if you build non-transactional storage on top of > transactional. > It is transactional. If transactions

[go-nuts] Re: New Embedded Document Database (Alpha)

That's possible. Yet it will not help with implementing another database based on that key-value store. Because even if (I do not know how and doubt that) badger provides CAS capabilities, one can not simply use it directly because: - The meaning and implementation of CAS at document level

[go-nuts] Re: New Embedded Document Database (Alpha)

BTW CAS is now implemented and added employing a rev field inside the json document (and again this idea is from CouchDB!). -- 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

[go-nuts] Re: New Embedded Document Database (Alpha)

Indeed this JSON store is transactional and takes advantage of this feature provided by badger. But CAS is another story and is orthogonal to transactions. Even when using common RDBMSs we need some form of optimistic concurrency. Assume we are about to update the balance for an account. How

[go-nuts] Re: New Embedded Document Database (Alpha)

And I am in desperate need of bugs! -- 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

[go-nuts] Re: New Embedded Document Database (Alpha)

Seven more examples added and other tiny improvements. Next step is to add CAS features. There are two main options for this: putting the CAS sequence/timestamp inside the document or as a separate value. Each one has their pros and cons. I am trying to find out which approach requires least

[go-nuts] Re: Measure Memory Fragmentation

The package: https://github.com/dc0d/bufferpool/ -- 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,

[go-nuts] Measure Memory Fragmentation

Is it possible to measure/visualize memory fragmentation? I have implemented a package that creates a buffer pool (pool of []byte) which are created from a single underlying big array. But I do not know how to actually measure/visualize the memory fragmentation. -- You received this message

[go-nuts] Re: On Accepting Interfaces and Structs

could define a set of functionality that a consumer needs from state.State, > you could then have Concrete1, Concrete2, and Concrete3 all implement > that functionality. Then consumer can just use them directly as > interfaces ... or perhaps that is using them indirectly. Anyway, I hope >

Re: [go-nuts] Re: Accessing Slices Made From Same Array Concurrently

Final code is here: https://github.com/dc0d/bufferpool I hope I got it right! On Monday, April 23, 2018 at 9:48:20 PM UTC+4:30, Kaveh Shahbazian wrote: > > @rog Thanks! Three-value slice operator was a very nice hint. > > The original intention was to implement a buffer-pool (po

[go-nuts] Re: On Accepting Interfaces and Structs

'wheels', and inside engine is 'carb/injector' > 'pistons' 'cams' 'ignition' inside ignition is ignition timing, throttle > etc etc. If you follow a model of containers you will get clean boundaries > between things, and the path from user to data will be much more clear. > > On T

[go-nuts] Re: On Accepting Interfaces and Structs

@Jake @Bryan Thanks! Current solution I use: A package that holds the shared data type State: package state type State struct { Latitude float64 Longitude float64 Mark string Name string // ... } Three packages with different implementations and algorithms:

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

Also -race does not complain about this: https://play.golang.org/p/IeA4npcemf5 On Monday, April 23, 2018 at 10:51:05 AM UTC+4:30, Kaveh Shahbazian wrote: > > @Silviu The code is mutating same item from two goroutines. While the > original target is to create a buffer pool that th

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

@Silviu The code is mutating same item from two goroutines. While the original target is to create a buffer pool that their items is not being mutated from two goroutines - actually they can not do that because at a specific time only one goroutine has access to one buffer. @Tamas Regarding

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

it's important to run race-enabled > binaries under realistic workloads." > > > On Sunday, 22 April 2018 07:56:48 UTC-4, Kaveh Shahbazian wrote: >> >> @Silviu >> >> But no slice expansion is happening. >> >> On Sunday, April 22, 2018 at 5:41

[go-nuts] Re: On Accepting Interfaces and Structs

alise part of the superclass and enable you to write a set of > functions with part of the implementation (for example, a tree store) while > letting you change the data type to something else. It's composition, as > opposed to inheritance. > > On Saturday, 21 April 2018 14:51:55 UTC+3,

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

r, []byte(fmt.Sprintf(*"%15d"*, k1))...) > > The buckets will overlap (more than 10 bytes) and you will get the race > triggered in the detector > > Silviu > > > On Saturday, 21 April 2018 12:40:04 UTC-4, Kaveh Shahbazian wrote: >> >> @Ankit That's what I thought. Yet th

Re: [go-nuts] On Accepting Interfaces and Structs

is a POGO (as in POJO or POCO - plain old Go object, just an analogy). On Saturday, April 21, 2018 at 4:36:40 PM UTC+4:30, Axel Wagner wrote: > > On Sat, Apr 21, 2018 at 1:52 PM Kaveh Shahbazian <kaveh.sh...@gmail.com > > wrote: > >> Is there a way to actually achieve th

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

u remove k,v:=k,v or append more than 10 bytes to v >> inside goroutine which will take up space on next slice's bytes. >> >> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian >> wrote: >>> >>> @ Louki Sumirniy >>>

[go-nuts] On Accepting Interfaces and Structs

Regarding "Accept interfaces, return concrete types", how can it be applied for structs that represent a payload/value? For example in package first, logger is defined as: type logger interface { Debugf(template string, args ...interface{}) Errorf(template string, args ...interface{})

[go-nuts] Re: Accessing Slices Made From Same Array Concurrently

@ Louki Sumirniy Slices are values AFAIK. There is no passby pointer. And the point is, race detector does not flag anything: https://play.golang.org/p/NC8mBwS1-0P -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group

[go-nuts] Accessing Slices Made From Same Array Concurrently

Is it safe to access slices that shares a back array concurrently? (Assuming the length of slices will not change) -- 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

[go-nuts] Re: Go-path from a source other than $GOPATH (and package management)

Indeed it is possible to set the $GOPATH in a shell. And if I use other tools with a specific project, for example VSCode, then I have to start all of them from the same terminal. Which is not the most desirable outcome. Anyway, as I have mentioned before, this solves nothing when multiple

Re: [go-nuts] Go-path from a source other than $GOPATH (and package management)

BTW I was wrong about multiple go-paths. During implementation, I've learnt lots of import path overwriting must take place to handle nested dependencies of different versions, properly. Well then, waiting for vgo. -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Go-path from a source other than $GOPATH (and package management)

com/golang/go/issues/17271#issuecomment-268301191 > > In any case I think all of this becomes irrelevant in the context of vgo: > > https://research.swtch.com/vgo > > On 19 April 2018 at 13:48, Kaveh Shahbazian <kaveh.sh...@gmail.com > > wrote: > >> Is it possib

[go-nuts] go get -tags

How does *go get -tags* work? -- 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

[go-nuts] Go-path from a source other than $GOPATH (and package management)

Is it possible to tell go tools to get the go-path from a source other than $GOPATH? Notes: Assuming the answer is no, I wish it was possible. For example when running a go command from the current directory, it go search the current directory, or goes up, until it finds a (for example)

[go-nuts] Creating snap app using Go

How one should make a snap app using Go (1.10.1)? The snapcraft tool uses Go 1.6. -- 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] Re: Using log Package with log.Lshortfile Flag

Filed an issue . -- 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

[go-nuts] Re: Using log Package with log.Lshortfile Flag

Line 13 is where the method inflog.Println is being passed (not called) - passed to function trace. At that point inflog.Println should be treated just like a value. Then function trace calls inflog.Println (on line number 37). Then method inflog.Println gets deferred (not yet called) and

[go-nuts] Re: Using log Package with log.Lshortfile Flag

The first function inflog.Println is not even being called. It is being passed to the function tract as an argument. And the result of function trace is being sent to another call to function inflog.Println. The result of function trace is a struct which has a String method and the the String

[go-nuts] Using log Package with log.Lshortfile Flag

The code resides here . The output from the program is: NaClMain [ info ] 23:00:00 main.go:13: main.main started NaClMain [ info ] 23:00:00 main.go:13: main.compute1 started NaClMain [ info ] 23:00:00 main.go:13: main.compute2 started NaClMain [ info ]

[go-nuts] Justifying dot imports using comments

Why isn't it possible to justifying a dot import using a comment (like blank imports)? (Go 1.10.1, golint, ubuntu) -- 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

Re: [go-nuts] Re: Channels vs Actors

I had a related question asked on Elixir Forum: Is handle_call part of the Actor Model? Since it sequentialize/synchronize things, is sound a bit like CSP (to me). An answer provided by Joe Armstrong (one of Erlang inventors)

Re: [go-nuts] Multiple directory paths in $GOPATH and go get

Thanks! The reason for this question: wanted to have one $GOPATH/bin but different $GOPATH/src. On Friday, March 9, 2018 at 4:33:24 PM UTC+3:30, ohir wrote: > > On Fri, 9 Mar 2018 04:46:16 -0800 (PST) > Kaveh Shahbazian <kaveh.sh...@gmail.com > wrote: > > > As I

[go-nuts] Multiple directory paths in $GOPATH and go get

As I understand it's possible to have multiple directory paths in *$GOPATH*, separated by the OS path separator. Is there a way to tell *go get* to use the second (nth) item in the path collection? -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

On Wednesday, February 28, 2018 at 11:00:13 PM UTC+3:30, Axel Wagner wrote: > > Can you elaborate/link to example code? Because it seems to work just fine > <https://play.golang.org/p/P0gUjbf6qRD>. > > > On Wed, Feb 28, 2018 at 6:58 PM Kaveh Shahbazian <kaveh.sh...@gmail

[go-nuts] Re: Arbitrary Secondary Indexes for boltdb

Usage tests from boltdb added. Sample usage here <https://godoc.org/github.com/dc0d/boltron#example-DB--BoltronIndexTimeJSON>. Any bug reports are most welcome! On Tuesday, February 27, 2018 at 5:29:01 PM UTC+3:30, Kaveh Shahbazian wrote: > > This <https://github.com/dc0d/b

Re: [go-nuts] Re: JSON and Embedded Types (Aliases)

. On Tuesday, January 23, 2018 at 9:59:10 PM UTC+3:30, Kaveh Shahbazian wrote: > > Did not try that and changed that instance of this code. > > On Tuesday, January 23, 2018 at 9:04:36 PM UTC+3:30, rog wrote: >> >> Have you tried out the behaviour on Go tip (or the go 1.10 bet

[go-nuts] Arbitrary Secondary Indexes for boltdb

This package contains implementation for arbitrary secondary indexes for boltdb (the version maintained by coreos ) - currently alpha quality with not enough tests. The selector passed as the definition of the index is a bit

[go-nuts] Re: vgo and handling major versions

+1 I love gopkg.in and use it extensively - gopkg.in + tags + GOPATH is my happy combination. On Monday, February 26, 2018 at 1:11:21 PM UTC+3:30, Maxim Ivanov wrote: > > gopkg.in already "redirects" different import paths to different > branches in your repo. You then use correct module name

[go-nuts] Re: vgo and handling major versions

:30, wilk wrote: > > On 26-02-2018, Kaveh Shahbazian wrote: > > > It would be nice if vgo could handle something like (in .mod files) > > `pkg > >>1.2.1 branch-name-*` and the `*` part could be a major number and the > > `1.2.1` is tag. The `branch-name-

[go-nuts] vgo and handling major versions

(IMHO - assuming vgo would care about this) About branches: Having branches for major versions helps greatly. A major version can literally be a whole different package by breaking the API or even introducing a completely new one. However keeping some previous major versions might be

Re: [go-nuts] Re: Shuffle Items in a Slice

I thought it's a cool trick! >>> 2 - Is anything bad about doing this? >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.googl