Re: [go-nuts] Preserving extra properties using JSON unmarshal / marshal?

['Eric Johnson' via golang-nuts]

Thanks for the pointers.

I was hoping for an easier answer. Maybe will look into patching stdlib.

Eric.


On Sat, Feb 22, 2020 at 1:15 AM Brian Candler  wrote:

> Looks like your thoughts are the right ones:
>
> https://stackoverflow.com/questions/33436730/unmarshal-json-with-some-known-and-some-unknown-field-names
>
> --
> 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.google.com/d/topic/golang-nuts/UZri3aWypTI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/376071d9-6852-419b-923c-9d36f46bf158%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANu9%3DNdyFZ30oROwFYPXCShahws8Wmb7dwP-itH0TjMssw6vzQ%40mail.gmail.com.

Re: [go-nuts] Preserving extra properties using JSON unmarshal / marshal?

['Eric Johnson' via golang-nuts]

Understand all that. It doesn't help.

Asking the question a different way, as concrete code always clarifies. For 
something like the following snippet of code:

const testJSON = `{
"first_name": "first",
"last_name": "last",
"favorite_color": "orange",
"age": 92
}`

func TestUnmarshalling(t *testing.T) {
var res struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
}
err := json.Unmarshal([]byte(testJSON), &res)
assert.NoError(t, err)
out, err := json.MarshalIndent(&res, "", "\t")
assert.NoError(t, err)
assert.Equal(t, testJSON, string(out))
}

Is there anything I can do to the "res" struct" to preserve the 
"favorite_color" and "age" properties from the original JSON, so that the 
final assert.Equal() passes? Ideally, as I indicated in the original post, 
it would be something along the lines of an additional struct member that 
acts as the catch-all for any values not found for the struct. (hence the 
line "Extras map[string]interface{} `json:",extra" that I put in my 
example.)

Stepping through the standard library, it seems pretty clear that the 
standard library simply discards JSON properties that it doesn't map to 
fields. I think the crucial lines 
<https://golang.org/src/encoding/json/decode.go#L753> (decode.go, 753-769) 
indicate that if a field is not found, no target value ("subv") is set, and 
then the resulting data is discarded.

Since the standard library doesn't support it, I'm wondering if there are 
any other reliable JSON encode / decode libraries out there that might?

I have three options, that I can tell:

   - Find an alternate library that supports something like this (hence the 
   post)
   - Use the standard library by implementing the Unmarshaler interface on 
   the struct, use normal unmarshaling for the known fields, then also 
   unmarshal as a map[string]interface{}, remove all the fields that I don't 
   want, and store the results in the "Extra" field myself. This will result 
   in double-parsing each struct and a lot of extra boilerplate code. Then 
   also need to do appropriate somethings to implement Marshal as well.
   - Fork the standard library JSON package, add the support myself, and 
   submit it back as a possible enhancement(!).
   
Using the standard library as is seems like a bad option, given the extra 
boilerplate that would be required for each struct. I'm hoping someone has 
already made an implementation that does this!

Eric.

On Friday, February 21, 2020 at 1:41:20 PM UTC-8, Chris Burkert wrote:
>
> Take a Look at 
> https://blog.golang.org/json-and-go:
>
> The json package uses map[string]interface{} and []interface{}values to 
> store arbitrary JSON objects and arrays; it will happily unmarshal any 
> valid JSON blob into a plain interface{} value. The default concrete Go 
> types are:
>
>- bool for JSON booleans,
>
>
>- float64 for JSON numbers,
>
>
>- string for JSON strings, and
>
>
>- nil for JSON null.
>
>
> Does this help?
>
> 'Eric Johnson' via golang-nuts > 
> schrieb am Fr. 21. Feb. 2020 um 19:00:
>
>> If I've got a structure like this:
>>
>> type jsonData struct {
>> FirstName string `json:"first_name"`
>> LastName  string `json:"last_name"`
>> }
>>
>> I can marshal / unmarshal JSON as:
>> {
>>   "first_name": "first",
>>   "last_name": "last"
>> }
>>
>> What if my input JSON is this:
>> {
>>   "first_name": "first",
>>   "last_name": "last",
>>   "favorite_color": "orange",
>>   "age": 92
>> }
>>
>> Is there an existing library to have a structure that's something like 
>> this:
>>
>> type jsonData struct {
>> FirstName string `json:"first_name"`
>> LastName  string `json:"last_name"`
>> Extrasmap[string]interface{} `json:",extras"`
>> }
>>
>> Such that a JSON unmarshal and marshal will preserve the data of the 
>> original JSON?
>>
>> I think I can probably make something work with the standard library, 
>> except that it will require extra marshaling / unmarshaling steps that will 
>> be annoying to reproduce for each structure that needs to capture extra 
>> data. So I'm hoping there's a better solution?
>>
>> Eric
>>
>>
>> -- 
>> You received this message because you are sub

[go-nuts] Preserving extra properties using JSON unmarshal / marshal?

['Eric Johnson' via golang-nuts]

If I've got a structure like this:

type jsonData struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
}

I can marshal / unmarshal JSON as:
{
  "first_name": "first",
  "last_name": "last"
}

What if my input JSON is this:
{
  "first_name": "first",
  "last_name": "last",
  "favorite_color": "orange",
  "age": 92
}

Is there an existing library to have a structure that's something like this:

type jsonData struct {
FirstName string `json:"first_name"`
LastName  string `json:"last_name"`
Extrasmap[string]interface{} `json:",extras"`
}

Such that a JSON unmarshal and marshal will preserve the data of the 
original JSON?

I think I can probably make something work with the standard library, 
except that it will require extra marshaling / unmarshaling steps that will 
be annoying to reproduce for each structure that needs to capture extra 
data. So I'm hoping there's a better solution?

Eric


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/630827e2-8277-4231-9ab1-31881198a386%40googlegroups.com.

[go-nuts] Re: Error checking in Go: The `try` keyword

['Eric Johnson' via golang-nuts]

To make an attempt at articulating why the error handling in Go is valuable 
as-is, I note the following points:

   - It is explicit, not hidden
   - The default idiom highlights "error checking being done here" (Go 
   developers learn to look for lines "if err != nil".)
   - It is possible to set breakpoints on the error case
   - Code coverage of unit tests reports when the error case has been 
   exercised.
   - It has the full flexibility of identifying the failure scenario, not 
   limited to err != nil (although that is the overwhelming use)
   - It has the full power and flexibility of the language for handling the 
   error - it can be logged, returned, recovered from, sent to a channel, etc.
   - If wrapping my error extends to multiple lines (due to longer 
   messages, number of parameters in the error, etc., that works using 
   existing language constructs.
   - It supports arbitrary return statement complexity, including multiple 
   return values.
   - It is straightforward to parse / analyze.

That said, it has some drawbacks, particularly in the most common cases.

   - Vertical space: Even in complex cases, the error handling inside the 
   "if" block can be reduced to at most two statements. One line for 
   "handling" the error, and a second line for returning it (or a modified / 
   wrapped version of it). With two additional vertical lines of boilerplate, 
   that's either a 100% or 200% increase in vertical space (the "if" 
   statement, and the closing brace). This limits the amount of code that can 
   fit on my screen, which constrains my ability to comprehend larger 
   functions.
   - Verbosity: The moment we're know we're checking for errors, the "if 
   err != nil {", the "return", and the "}" are usually just extra syntax.
   - Scanning complexity: What if the check is not err != nil, but err != 
   NotFound? Is this an error case, or an expected case? The current construct 
   hides that distinction. We have to look to the next line to see how it is 
   handled to know that it is an error return.
   - When there are multiple returns on a function, the error handling must 
   specify them all, even though the common case is to return a "zero" value.

For language design purposes, the most common scenario for handling an 
error is a single-line error return. When it comes to error handling, there 
are two paths to choosing a new solution:

   - Identify a solution that captures the 80-90% case of if err != nil { 
   return ... }
   - Identify a solution that can be used for *all* error handling, where 
   the existing if err != nil then becomes a legacy code base choice, because 
   it does not use the new construct which more clearly conveys "error 
   handling here".

For the benefit of the language, I would prefer a solution that fits the 
second category, not one that fits the first category. Due to the fact that 
this proposed solution does not address the arbitrary response complexity, 
it seems like it fits the first category. If there's a way to tweak the 
proposal so that it can be used for *every* error handling case, then that 
would be better.

Go has a long history of implementing orthogonal solutions that happen to 
combine well. It is possible that error handling is one of those places 
that could benefit from teasing this question apart a little more.

Eric


On Thursday, February 6, 2020 at 7:28:24 PM UTC-8, addi...@gmail.com wrote:
>
> Error checking in Go: The try keyword.
>
> This isn’t a complete proposal it only describes basic idea and the 
> changes suggested.
> The following are modifications that deals with some of the problems 
> introduced in the original proposal 
> 
> .
>
> (I apologize if something very similar that uses a simple method to deal 
> with adding context has been posted before but I could not find it.)
>
> First, try is a keyword not a function builtin.
>
> Here’s how error handling with the try keyword works:
>
> try err
>
> is equivalent to:
>
> if err != nil {
> return err
> } 
>
> That’s it.
>
> Example:
>
> f, err := os.Open("file.dat")
> try err
> defer f.Close()
>
> f.WriteString("...")
>
> But, how to add context to errors?
>
>  because try only returns if err != nil.
> You can create a function that returns nil if an error is nil.
>
> In fact, a function like this already exists in the errors package here.
> https://github.com/pkg/errors/blob/master/errors.go
>
> // Wrap returns an error annotating err with a stack trace
> // at the point Wrap is called, and the supplied message.
> // If err is nil, Wrap returns nil.
> func Wrap(err error, message string) error {
> if err == nil {
> return nil
> }
> err = &withMessage{
> cause: err,
> msg:   message,
> }
> return &withStack{
> err,
> callers(),
> }
> }
>
> Example using it with try
>
> f, err := os.Open("file.dat")
> try errors.Wra

Re: [go-nuts] Re: Go mindshare is low & ~flat, per Google Trends

['Eric Johnson' via golang-nuts]

On Sunday, January 26, 2020 at 10:27:35 PM UTC-8, pentel...@gmail.com wrote:
>
>
> IMHO, golang didn't make a dent on key areas to become a language of 
> choice like big data (analytics, complex event processing, etc.) and 
> consequently, hot topics like artificial intelligence. Exactly areas where 
> python excels today.


At least when it comes to analytics, ML, AI, there are various languages at 
play in this space. Python isn't replacing "R" either. I don't think we 
should expect that it would either. One of Python's intended strengths for 
AI / ML / analytics involves REPL, which is specifically not a targeted 
feature of Go. On the other hand, when it comes to situations like the 
execution of AI / ML models in performance critical environments, I have 
heard / read of anecdotal evidence of teams opting for Go.

The question isn't whether Go making an impact for a specific area, it is 
whether it is making an impact where it is appropriate. For that, from what 
I see, the answer is overwhelmingly *yes*.

Eric.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1c8579d4-27b5-470b-a49d-1bca548bc8f7%40googlegroups.com.

Re: [go-nuts] [Proposal] database/sql: add interface that unite DB and Tx

['Eric Johnson' via golang-nuts]

Indeed. The strength of Go's interfaces is precisely that a library 
provider does not need to create interfaces, unless they are critical to 
the implementation of the library. You should create these types of 
interfaces when you need them.

There's a subtle versioning problem here. If Go adds a method that applies 
to both the DB and Tx objects, the proposed interface could not add the 
method in question without breaking the compatibility promise. So that 
would mean an interface with a similar purpose but a new name, in order to 
maintain compatibility.

There are differences in meaning between performing operations on the DB 
object vs. performing them on the Tx. Only in your code own do you know if 
it is safe to hide these distinctions behind an interface.

In a transaction, it isn't necessary to close a statement after it is used, 
because it will be closed when the transaction ends 
, whereas with the DB 
connection, explicit close is necessary 
.

The sql package has really good reasons for forcing the clients to think 
about what they really need, rather than providing the proposed interface.

Eric.

On Thursday, January 16, 2020 at 9:36:50 AM UTC-8, Marcin Romaszewicz wrote:
>
> I have that exact interface in all of my DB code, and I never use sql.Tx 
> or sql.DB directly. You don't need Go's libraries to adopt this at all, 
> just use your own.
>
> On Wed, Jan 15, 2020 at 11:20 PM Mhd Shulhan  > wrote:
>
>> ## Problem
>>
>> At some point we have a function that receive an instance of database 
>> connection to query rows in specific table.
>>
>> Let's say that function F() accept DB that query table T.
>>
>> If function F() called with DB instance, it will query only rows that has 
>> been committed into database.
>>
>> IF function F() called with Tx instance, it will query all rows including 
>> the one that has not been committed yet into database.
>>
>> Since DB and Tx are different types, we will have two functions that 
>> almost have identical code,
>>
>> func F(db *sql.DB) (output int) {
>>   q := `SELECT … FROM T WHERE …`
>>   err := db.QueryRow(q).Scan(&output)
>>   …
>>   return output
>> }
>>
>> func FWithTx(tx *sql.Tx)(output int) {
>>   q := `SELECT … FROM T WHERE …`
>>   err := tx.QueryRow(q).Scan(&output)
>>   …
>>   return output
>> }
>>
>>
>> ## Proposed solution
>>
>> Add an interface Session (the name is not fixed yet) to package sql with 
>> the following signature,
>>
>> type Session interface {
>> func Exec(query string, args ...interface{}) (Result, error)
>> func ExecContext(ctx context.Context, query string, args 
>> ...interface{}) (Result, error)
>> func Prepare(query string) (*Stmt, error)
>> func PrepareContext(ctx context.Context, query string) (*Stmt, error)
>> func Query(query string, args ...interface{}) (*Rows, error)
>> func QueryContext(ctx context.Context, query string, args 
>> ...interface{}) (*Rows, error)
>> func QueryRow(query string, args ...interface{}) *Row
>> func QueryRowContext(ctx context.Context, query string, args 
>> ...interface{}) *Row
>> }
>>
>> Session interface is combination of DB and Tx that contains all identical 
>> methods.
>>
>>
>> ## Rationale
>>
>> Without Session, user will have two functions that have the same code,
>>
>> By using Session, we can minimise duplicate code in the user level. for 
>> example using the previous problems definition the function F() become one,
>>
>> func F(session sql.Session)(output int) {
>>   q := `SELECT … FROM T WHERE …`
>>   err := session.QueryRow().Scan(&output)
>>   …
>>   return output
>> }
>>
>>
>> ## Discussion
>>
>> Any thought about this proposal?
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/C8AB29FF-7A85-445A-B09E-A0E7CB322A4C%40gmail.com
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f4cab90-67e0-4f85-83d9-8e4f4e8c0ff7%40googlegroups.com.

[go-nuts] Re: golang with XSLT

['Eric Johnson' via golang-nuts]

Tips:

   - When ever you're wondering about a good library for , two good 
   places to start are https://go-search.org , 
   and https://github.com/avelino/awesome-go.
   - As an alternative to finding a Go implementation, reuse an existing 
   one (libxslt) by calling out to C code. It may sound scary or difficult, 
   but it should be relatively straightforward.
   - Call out to an executable that does the work for you (cmd.Exec). 
   Unless the XSLT transformation is a performance critical one, calling out 
   to a process to do the work will get the job done.

Good luck!

Eric

On Thursday, August 15, 2019 at 5:24:28 PM UTC-7, p Chak wrote:
>
> Hi,
>  I am newbie to golang programming and planning to use xslt. Please let me 
> know the best XSLT API for golang.
>
> Thanks
> Praveen
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c4944e07-b257-4ece-b87f-e2e1d0e4d629%40googlegroups.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

['Eric Johnson' via golang-nuts]

And then, it also occurs to me that perhaps I can answer my own question. 
Taking advantage of three aspects of the ecosystem.

#1) Most open source Go libraries are on GitHub
#2) Many (most?) CVEs for open source projects will include a reference 
back to the project, and these references can be extracted from the cvelist 
 project.
#3) GitHub has an API to fetch the language of a GitHub repository.

Putting those three together, it might be possible to filter every CVE 
entry that has a reference to GitHub, then every GitHub project in that 
list that is implemented in Go, and turn that into a list of 
vulnerabilities for packages. Then match on those packages. That might 
generate a short list of projects that have had vulnerabilities. That far 
more reasonable list could then be augmented by a small amount of open 
source labor to annotate with the versions known to be vulnerable, when new 
items appear.

>From a completely different direction, the CVE quality team is looking to 
add more data to CVE entries. Seems like implementation language + package 
management name as additional data in the CVE record itself might also help 
address the issue. That would be generalizable to Java, Javascript. Rust, 
Python, and Go, for starters.

Before I send that idea in to the quality WG, does anyone here have a 
better suggestion?

Eric

On Tuesday, August 13, 2019 at 9:50:19 PM UTC-7, Eric Johnson wrote:
>
> It would be great to hear of an answer to this question. I suspect there 
> isn't one, though.
>
> The trouble is, one of the first hurdles is to identify Go libraries that 
> have CVEs against them. It is very easy to find CVEs for the Go standard 
> library, but I cannot see any easy way to scan the vulnerability databases 
> for vulnerable projects that happen to be implemented in Go.
>
> On top of that, for the purposes of dependency scanning, we really only 
> need to care about those projects implemented in Go that have non-main 
> packages. The main packages may have vulnerabilities, but those will never 
> show up in a dependency scan...
>
> If one can identify that list, then the open source tool to find any 
> dependent libraries that might have vulnerabilities would be pretty 
> straightforward.
>
> Unfortunately, identifying that list is might be really hard. Currently 
> probably only possible for companies that have a business model that 
> supports paying people to investigate each and every one of the 
> vulnerabilities that shows up with a CVE
>
> Maybe someone on this list can think of a great way to filter the CVE 
> list
>
> Eric.
>
> On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>>
>> I've been introduced to https://rubysec.com/ which has a database 
>> which easily integrates with builds to check for known security 
>> vulnerabilities in third party libraries and was wondering whether 
>> anything similar exists for go packages? 
>>
>> A quick search finds https://snyk.io/vuln?type=golang which appears 
>> similar but is basically a pay service based on node.js. 
>>
>> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
>> looks interesting but doesn't include go. 
>>
>> Does such an open source version exist for go which is written in go 
>> and integrates easily with builds? 
>>
>> -- 
>> Steve Mynott  
>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/95bd2530-182c-4d0f-8d70-b303bf8b1e9d%40googlegroups.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

['Eric Johnson' via golang-nuts]

It would be great to hear of an answer to this question. I suspect there 
isn't one, though.

The trouble is, one of the first hurdles is to identify Go libraries that 
have CVEs against them. It is very easy to find CVEs for the Go standard 
library, but I cannot see any easy way to scan the vulnerability databases 
for vulnerable projects that happen to be implemented in Go.

On top of that, for the purposes of dependency scanning, we really only 
need to care about those projects implemented in Go that have non-main 
packages. The main packages may have vulnerabilities, but those will never 
show up in a dependency scan...

If one can identify that list, then the open source tool to find any 
dependent libraries that might have vulnerabilities would be pretty 
straightforward.

Unfortunately, identifying that list is might be really hard. Currently 
probably only possible for companies that have a business model that 
supports paying people to investigate each and every one of the 
vulnerabilities that shows up with a CVE

Maybe someone on this list can think of a great way to filter the CVE 
list

Eric.

On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>
> I've been introduced to https://rubysec.com/ which has a database 
> which easily integrates with builds to check for known security 
> vulnerabilities in third party libraries and was wondering whether 
> anything similar exists for go packages? 
>
> A quick search finds https://snyk.io/vuln?type=golang which appears 
> similar but is basically a pay service based on node.js. 
>
> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
> looks interesting but doesn't include go. 
>
> Does such an open source version exist for go which is written in go 
> and integrates easily with builds? 
>
> -- 
> Steve Mynott > 
> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c5ea3214-26ef-41c9-a5eb-b8ed4c65c448%40googlegroups.com.

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

['Eric Johnson' via golang-nuts]

On Thu, Dec 6, 2018 at 4:37 PM roger peppe  wrote:

> How would generics help you here? The WithTxn function is already generic
> (courtesy of closures) and there's no reason it couldn't be put in a
> publicly importable package somewhere.
>

When I use the equivalent functionality, I tie it to an interface
specifically for the database changes / queries allowed. Makes for great
separation between the database layer and the business logic. That means,
however, every time I have a new database API, there's a new interface, and
a new implementation of the function.

Eric.


> On Thu, 6 Dec 2018, 10:26 pm Eric Johnson 
>>
>>
>> On Thu, Dec 6, 2018 at 12:16 AM roger peppe  wrote:
>>
>>>
>>>
>>> On Wed, 5 Dec 2018 at 18:55, 'Eric Johnson' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>>> I always go with the approach that uses the equivalent of the
>>>> "Transact()" method.
>>>>
>>>> On top of that, rather than use a generic *sql.Tx parameter to the
>>>> "txFunc" function, I pass an interface that is specific to the operations
>>>> of the database layer for my application.
>>>>
>>>
>>> That's an interesting idea. For the record, this is the code we use:
>>>
>>
>> This is one of *the* places in my code where I'd probably immediately
>> take advantage of "generics" in Go. This function to wrap transactions
>> could be written generically, and then not have to be copied from
>> application to application. While I could go with the work-around to leave
>> the function in the *sql.Tx parameter form, the other approach is *so*
>> useful that I copy the function instead.
>>
>> Eric
>>
>>
>>>
>>> package transaction
>>>
>>> import (
>>> "context"
>>> "database/sql"
>>> "fmt"
>>>
>>> "gopkg.in/errgo.v1"
>>> )
>>>
>>> // WithTxn executes a function inside a transaction context.
>>> func WithTxn(db *sql.DB, ctx context.Context, f func(*sql.Tx) error)
>>> error {
>>> txn, err := db.BeginTx(ctx, nil)
>>> if err != nil {
>>> return errgo.Mask(err)
>>> }
>>> if err := f(txn); err != nil {
>>> return rollback(txn, err)
>>> }
>>> return rollback(txn, txn.Commit())
>>> }
>>>
>>> func rollback(txn *sql.Tx, err error) error {
>>> if err == nil {
>>> return nil
>>> }
>>> errRollback := txn.Rollback()
>>> if errRollback != nil {
>>> return errgo.NoteMask(err, fmt.Sprintf("failed to roll back
>>> (error: %v) after", errRollback), errgo.Any)
>>> }
>>> return err
>>> }
>>>
>>>>
>>>>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

['Eric Johnson' via golang-nuts]

On Thu, Dec 6, 2018 at 12:16 AM roger peppe  wrote:

>
>
> On Wed, 5 Dec 2018 at 18:55, 'Eric Johnson' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I always go with the approach that uses the equivalent of the
>> "Transact()" method.
>>
>> On top of that, rather than use a generic *sql.Tx parameter to the
>> "txFunc" function, I pass an interface that is specific to the operations
>> of the database layer for my application.
>>
>
> That's an interesting idea. For the record, this is the code we use:
>

This is one of *the* places in my code where I'd probably immediately take
advantage of "generics" in Go. This function to wrap transactions could be
written generically, and then not have to be copied from application to
application. While I could go with the work-around to leave the function in
the *sql.Tx parameter form, the other approach is *so* useful that I copy
the function instead.

Eric


>
> package transaction
>
> import (
> "context"
> "database/sql"
> "fmt"
>
> "gopkg.in/errgo.v1"
> )
>
> // WithTxn executes a function inside a transaction context.
> func WithTxn(db *sql.DB, ctx context.Context, f func(*sql.Tx) error)
> error {
> txn, err := db.BeginTx(ctx, nil)
> if err != nil {
> return errgo.Mask(err)
> }
> if err := f(txn); err != nil {
> return rollback(txn, err)
> }
> return rollback(txn, txn.Commit())
> }
>
> func rollback(txn *sql.Tx, err error) error {
> if err == nil {
> return nil
> }
> errRollback := txn.Rollback()
> if errRollback != nil {
> return errgo.NoteMask(err, fmt.Sprintf("failed to roll back
> (error: %v) after", errRollback), errgo.Any)
> }
> return err
> }
>
>>
>>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

['Eric Johnson' via golang-nuts]

I always go with the approach that uses the equivalent of the "Transact()" 
method.

On top of that, rather than use a generic *sql.Tx parameter to the "txFunc" 
function, I pass an interface that is specific to the operations of the 
database layer for my application.

This pattern has three benefits:

   - Code that changes the database has standard Go semantics - if 
   something goes wrong, return an error.
   - Guaranteed to correctly call either "Commit" or "Rollback" as 
   appropriate
   - The specifics of the exact SQL queries is hidden behind the interface. 
   Any database compatibility is now isolated in one place/package in the 
   code, instead of having to look for all the places in your code where 
   transactions might be used.

Eric.

On Monday, December 3, 2018 at 1:53:30 PM UTC-8, Ben Hoyt wrote:
>
> Hi folks,
>
> We found some subtle bugs in our db transaction code for handling 
> commits/rollbacks. Here's the pattern we were using (not real, but shows 
> the issue):
>
> func DoTwoThings() error {
> tx, err := db.Begin()
> if err != nil {
> return err
> }
> // commit or rollback the transaction before we return
> defer tx.Close(&err)
>
> err := InsertFoo(tx)
> if err != nil {
> return err
> }
> if _, err := UpdateBar(tx); err != nil {
> return err
> }
> return nil
> }
>
> The problem is there's a subtle but potentially quite bad bug with this 
> usage pattern -- if the InsertFoo succeeds but UpdateBar fails, the first 
> "err" variable will be nil, so the deferred tx.Close() will COMMIT the 
> transaction rather than ROLLBACK, and the database will be in an 
> inconsistent state.
>
> The code above is a bit contrived, and you can easily fix it by moving the 
> "_, err := UpdateBar()" outside of the if so it's referring to the same 
> "err" variable, but it's very easy to miss and get it wrong. So we decided 
> it was a bad pattern and started thinking about the best way to fix.
>
> One idea is a RollbackUnlessCommitted() function which you can defer, and 
> then you call Commit() once manually (stolen from gocraft/dbr):
>
> func DoTwoThings() error {
> tx, err := db.Begin()
> if err != nil {
> return err
> }
> defer tx.RollbackUnlessCommitted()
>
> err := InsertFoo(tx)
> if err != nil {
> return err
> }
> if _, err := UpdateBar(tx); err != nil {
> return err
> }
> tx.Commit()
> return nil
> }
>
> Another idea is to create a "Transact" function which takes an anonymous 
> function and does all the transaction handling:
>
> func (db *DatabaseImpl) Transact(txFunc func() error) (err error) {
> tx, err := db.Begin()
> if err != nil {
> return
> }
> defer func() {
> if p := recover(); p != nil {
> tx.Rollback()
> panic(p) // re-throw panic after Rollback
> } else if err != nil {
> tx.Rollback() // err is non-nil; don't change it
> } else {
> err = tx.Commit() // err is nil; if Commit returns error 
> update err
> }
> }()
> err = txFunc(tx)
> return err
> }
>
> And then the DoTwoThings function becomes:
>
> func DoTwoThings() error {
> return db.Transact(func() error) {
> err := InsertFoo(tx)
> if err != nil {
> return err
> }
> if _, err := UpdateBar(tx); err != nil {
> return err
> }
> })
> }
>
> I think the second is probably safer and nicer, but it's slightly awkward 
> in that it requires an extra level of indentation. Still, awkward is better 
> than buggy.
>
> Does anyone else have a better pattern for this kind of thing, or feedback 
> on the above?
>
> -Ben
>
>

-- 
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 https://groups.google.com/d/optout.

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

['Eric Johnson' via golang-nuts]

Is an alternate solution to use Go as a source language, then translate to 
an allegedly "ISO" language?

Eric.

On Thursday, October 11, 2018 at 8:57:39 PM UTC-7, Beoran wrote:
>
> So no matter if I say yes or no, both ways are bad? I think is not a very 
> fair way to argue.
>
> Anyway, with the Ruby standard you can do either. The Ruby standard 
> defines that there are strictly conforming Ruby processors, which implement 
> the standard and conforming Ruby processors which may have any number of 
> additional implementation defined extensions, alternate syntax and language 
> features. 
>
> After the standard was written, mruby was implemented to be a strictly 
> conforming Ruby processor, which doesn't influence or hold back the 
> development of the other Ruby implementations at all.
>
> And all other Ruby implementations can be considered confirming, which is 
> worth millions of $$$ to Ruby developers. The organizations and governments 
> I mentioned   tend to have deep pockets, and the Ruby standard enables us 
> to gain approval from said bureaucrats. So, we can now use Ruby for these 
> well funded projects, since now it is an international standard.
>
> So actually, because the Ruby standard was carefully written to enable 
> this, it has been win/win for Ruby developers. You can use a strictly 
> conforming mruby if you like or need to, or use any other Ruby 
> implementations as conforming ones and please the bureaucrats.
>
> I consider that we should do the same for Go. When done carefully it will 
> also be a win/win.
>
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: I am not in favor of generics.

['Eric Johnson' via golang-nuts]

On Tue, Sep 18, 2018 at 6:21 AM Robert Engels  wrote:

> I am going to refer everyone involved in this discussion on generics to
> this once again. I know it is long, read the summary... but it’s important:
>
>
> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
>

I'm skimming that paper. Thanks for sharing. Paper definitely identifies
benefits for adding generics.

This quote jumped out at me for its relevance to this discussion:
"We observed parameterization of 1152 types, but actually found about 46 %
of these types (532) only had exactly one type argument ever used
throughout the project’s history, suggesting that needless or premature
generification of objects occurs fairly frequently.We observed
parameterization of 1152 types, but actually found about 46 % of these
types (532) only had exactly one type argument ever used throughout the
project’s history, suggesting that needless or premature generification of
objects occurs fairly frequently."

Put in the term of this discussion thread, the study notes that about 45%
of the time (for the Java projects studied), portions of the code get
harder to read, with little or no clear benefit. There's no basis for
thinking that the same problems will or won't occur with any generics added
to Go, but it seems like a reasonable place to point to for concerns
driving this thread.

Eric.


>
> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki 
> wrote:
>
> On Tue, 18 Sep 2018 04:38:55 -0700 (PDT)
> ffm2...@web.de wrote:
>
> Every average Joe Java boilerplate coder gets along with generics.
>
> Barely, if at all, understanding whats under.
>
> "Smart Copy Paste ... A book for normal programmers"
> https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM
>
> But even there you can manage without thinking and just doing
>
> trial and error if you wanted to.
>
>
> OP, I and many others want to defend Gol off this very attitude.
> Go is among few contemporary languages that allows me to fully
> understand what my resulting binary will do, down to the syscall
> level. Thats precious.
>
>
> I think it will neither be tricky to make use of nor to read the code.
>
>
> I claim opposite. All and any Gopher will be expected to cope with hard to
> read and yet harder to understand generic code. Even if she herself will
> vowed not to use it. In a short while we all will be obeying first Java's
> commandment "thou shalt not peek under".
>
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> --
> 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 https://groups.google.com/d/optout.
>
> --
> 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.google.com/d/topic/golang-nuts/3ia8XrUgqOg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: I am not in favor of generics.

['Eric Johnson' via golang-nuts]

On Monday, September 17, 2018 at 9:04:26 AM UTC-7, jucie@zanthus.com.br 
wrote:
>
> Go core team is working hard to bring generics to the language because 
> several people asked for it. With all due respect for those users and for 
> people working hard to make generics a reality, I feel that a greater 
> number of people would suffer after generics adoption. So, I feel compeled 
> to manifest my opinion: sorry guys, Go with generics will be worse than Go 
> without generics.
>

I think you're right, that adding parameterized typed method invocations 
will add complexity, and therefore people will suffer more. However, to me, 
it isn't obvious, without a final proposal against which to assess that 
concern, that the pain will outweigh the gain.

Certainly, the existing proposal suffers from at least one area of 
considerable additional complexity - "contracts" - which is both a great 
way to address the problem space, and an area of new complexity 
incompatible with Go's existing language choices. I look forward to seeing 
the next round of drafts and how they incorporate concerns about contracts.
 

>
> The language strives for simplicity since its inception and that is what 
> attracted a large part of its user base. We must think about who we will 
> want to have in our community 10 years from now. Supporting generics would 
> please a minority to the detriment of a large number of potential users.
>

What pushes me in the direction of encouraging attempts to address the 
missing language feature of generics are two aspects:

   - Copy and paste coding is an enormous source of errors, and to the 
   extent that generics addresses some of those scenarios, that is a big win 
   for the language and the developers. Writing yet another "for ... range" 
   loop to perform the same mutation on a very similar type is not a big deal 
   the 2nd time, but by the time I've had to do that for a fifth time, I'm 
   unhappy about it, for sure. (YAFRL - "yet another for ... range loop")
   - Go already has "generic" capabilities. "range", channels, select, and 
   type-casting are generic language constructs, "Make", "copy", "append" all 
   provide generic functions, and maps and slices are generic data structures. 

Developers certainly do not have a problem using the existing "generic" 
capabilities of the language, so I think there's a case to be made that 
they will not consider additional "generic" capability that much harder to 
absorb.


> Today Go is easy to learn and tools are easy to implement. Please keep it 
> that way.
>

I agree with that sentiment!

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] The generics draft proposal underspecifies contracts

['Eric Johnson' via golang-nuts]

Two thoughts about the contracts proposal:

   - In the proposal a contract is loosely defined as the resulting 
   implications from a function. In the interests of starting a discussion, it 
   seems like a great starting place. However, it feels like it would be 
   useful to spell it out in the draft proposal. Otherwise, discussions about 
   whether a contract syntax is the best form are difficult to assess.
   - Since the contract is loosely defined as following the syntax of a 
   function, that leaves open the opportunity for contracts that specify the 
   same thing to be written in radically different ways. Go's strength stems 
   in part from the clarity of purpose for the code written in Go.

What's defined in a contract, made explicit - is this an exhaustive list?

   - Which operators work on an instance of a type (==, <, >, ++, --)?
   - What can an instance of the type be cast to?
   - What is the base type of the type? (int, float, int64, string, 
   struct{}, [], map[], interface{}...).
   - What method signatures can be found on an instance of a type?
   - What members and their types can be found in instances of structure 
   types?

Does that capture it?

Clarified this way, it seems clear that generics support could be added to 
the language over time, instead of in one gigantic change. For example, 
what if the generics implementation, in its first manifestation, didn't 
support all the operators? That capability could be added in the future, 
without breaking backward compatibility. Or, in the first iteration, 
perhaps "range" could only be used on generic slices, instead of also 
including maps?

As to the imprecise syntax of the contract, the more I think about it, the 
more I think I want an explicit contract syntax, instead of a mock function 
syntax. The mock syntax approach means that different portions of the Go 
community could develop different "idioms" for specifying the same thing, 
which runs in the opposite direction of how the Go team has traditionally 
defined the language.

Having said all that, I'm pleased to see the thought that has gone into the 
proposal. Thanks so much for all the hard work.

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Printfln on fmt and log

['Eric Johnson' via golang-nuts]

Hi Anirudh,

On Tuesday, May 22, 2018 at 4:29:59 PM UTC-7, Anirudh Vyas wrote:
>
> Hi - 
>
> I want to have a Printfln on log and fmt - Currently I use fmt.Printf( " 
> yada yada \n", some_yada_yada) to  achieve same effect. Is there a plan to 
> add this simple yet extremely useful function?
>

I doubt it, because:

   - the substitution of "Printfln" vs. adding "\n" saves *no* typing
   - moving the "ln" to the beginning of the line moves the meaning ("new 
   line") away from the location where its meaning is intended. Go is all 
   about being explicit to avoid confusion.
   - Printf - with fair regularity - gets used with "\n" sprinkled 
   throughout the format string, rather than just at the end (an unusual use 
   for Println), so that invites the question - why is the "\n" at the end of 
   the string special?
   - The provided functions have a long history behind them.

Eric.

>
>
> Thanks
> Anirudh
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Language is a platform, which golang still does not pay attention to !!!

['Eric Johnson' via golang-nuts]

I have a different perspective

On Thursday, April 5, 2018 at 10:26:19 AM UTC-7, bingj...@gmail.com wrote:
>
> Almost 10 years golang appears in the world. 10 years is not a short 
> duration. I think if it is not popular until 2020, it will never be popular.
>
> Golang is designed for cloud and internet areas. Really?
>
> The creators of golang have a lot of experience in C and C++. And golang 
> borrows features from C and C++. But C and C++ do not fit the requirements 
> of cloud and internet areas.
>
> Let's look at two popular programming languages java and php. What is the 
> most important features of these two languages? Simple, ugly but 
> practical... I find one feather: they are both not just programming 
> languages but also platforms. They are almost the same in Windows and 
> Linux. That's why java and php are very popular in recent days.
>
> C and C++ are just pure programming languages, not platforms. On Unix and 
> Windows, C and C++ are very different. A developer of windows C++ is not a 
> developer of UNIX C++, and a Linux C developer is not a Windows C developer.
>
> If golang wants to be widely used by developer all over the world before 
> 2020, it must learn some thing from java and php, must be a 
> programming-language-is-a-platform.
>
> Until now, programs written in golang still does not have binary 
> distribution format like jar, dll or so. People have to share libraries by 
> source code. It is so foolish.
>

As my company is a potential vendor of commercial Go libraries, I've been 
interested in this very question. I believe your assertion is incorrect. It 
is possible, but not pleasant, to share pre-built Go libraries. The 
challenge is that you have to include stub code to make it work, and make 
sure the timestamps on the stubbed-out code don't get updated. Of course, 
you also have to ship the binaries specific to the platform that the target 
developer is going to use, but that is possible. The advantage of shipping 
the stub code is that you can get all the benefits of existing IDE tooling 
that work off of the source to generate documentation, and understand the 
meaning of your code and how it is used.
 

> Yes, Golang is very like C and C++, which are only pure programming 
> language, But this times, we need "language as/is platform" technologies, 
> just like php and java.
>

What is meant by "language as/is platform"? Just about any library I need, 
I can find for Go. And they happen to work across multiple platforms, just 
like with Java. As with Java before it, Go delivers on database APIs, web 
APIs, and protocols. There's a robust ecosystem of third-party libraries to 
make coding in Go much better. Numerous IDEs and editors include excellent 
support for Go.

Tons of community, including Meetups around the world.

One piece that has been missing relates to versions on libraries. That has 
been addressed in various ways, and a proposal that will most likely join 
the toolchain is in the queue for Go 1.11 (vgo).
 

> I have watched golang for many years, but never turn to it. Why? I think 
> it is still semi-finished product. Creators of golang are researchers, not 
> engineers, they worked too slow.
>

What would meet the definition of finished? Java still isn't finished, all 
these years later, because they're still adding language features (not just 
libraries!). Is Java slow because of this?

Go has felt to me like it moves very rapidly, as incredible enhancements 
come very quickly to the ecosystem. The compiler is itself now written in 
Go, and most of the runtime, which means that it is more possible for Go 
developers to help tweak the future direction of the language than it is 
for say Java developers, for whom the JVM will mostly be a black-box 
written in C++ that they probably never understand.

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

['Eric Johnson' via golang-nuts]

An interesting idea. Some thoughts

On Friday, February 2, 2018 at 9:03:54 AM UTC-8, matthe...@gmail.com wrote:
>
> I’m looking at patterns summarized on Wikipedia from “Design Patterns: 
> Elements of Reusable Object-Oriented Software” and writing out a few as the 
> equivalent in Go.
>
> Visitor: https://play.golang.org/p/A5tNzxMmetH
>

Your visitor pattern here seems to not be a "visitor" pattern. I would 
think that the Go equivalent would define an interface, and visit based on 
that interface.
 

>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>

This isn't really an example of a factory method, because it isn't 
instantiating things of different types.
 

>
> Facade: https://play.golang.org/p/forPdwy9VCi
>
 

>
> Proxy: https://play.golang.org/p/DFWuDPTOzEP
>
> I’m curious how more experienced people rank these and the other patterns.
>

I didn't look at all your examples, but in most cases, it seems like error 
handling, which would be an important part of a Go example, is completely 
absent in the examples given here.

Eric
 

>
> Matt
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] interaction of defer and named returns is too subtle and non-local

['Eric Johnson' via golang-nuts]

I was looking at fixing an issue flagged by gometalinter, and realized I 
didn't understand the actual behavior of defer statements. Specifically, I 
was not handling the error return of a close operation.

I wrote a test program so I could understand the behavior, which led to 
these two function

package main

import "fmt"

func checkDefer(newVal int, val *int) {
fmt.Printf("current value is %v\n", *val)
*val = newVal
}

func main() {
fmt.Printf("variableOnUnnamedReturn value is %v, expected 30\n", 
variableOnUnnamedReturn(20, 25, 30))
fmt.Printf("variableOnNamedReturn value is %v, expected 45\n", 
variableOnNamedReturn(35, 40, 45))
}

func variableOnUnnamedReturn(start, test, def int) int {
retval := start
defer checkDefer(def, &retval)
retval = test
return retval
}

func variableOnNamedReturn(start, test, def int) (retval int) {
retval = start
defer checkDefer(def, &retval)
retval = test
return retval
}


The body of the two functions differs only by a single ":", and yet, the 
output of the Printf calls differs. This appears to be due to very subtle 
differences between how named and unnamed returns are handled in the 
context of defer statements.

I looked through the language spec, and did not see this clearly spelled 
out. It is not obvious to me, a relatively experience Go developer, that 
the "variableOnUnnamedReturn" function should return a 25 in the above use, 
but the "variableOnNamedReturn" function returns a 45 in the above use.

As near as I can tell, operationally, the "unnamed" return could be 
re-written in something like the following fashion (where addDeferredOps is 
a collector for deferred operations.):

retval := start
dos := addDeferredOps(func() { checkDefer(def, &retval)} )
retval = test
_retval1_ = retval
dos.performDeferredOps()
return _retval1_

Which makes it obvious that the call to checkDefer() won't change the 
return of the function. Whereas, the "named return" version effectively 
amounts to this:

retval := start
dos := addDeferredOps(func() { checkDefer(def, &retval)} )
retval = test
dos.performDeferredOps()
return retval

I read the language spec, and simply didn't see the description of the 
difference between these two behaviors. Seems mostly like a language bug, 
to me. Feels like the named and unnamed return cases should behave the 
same. I can see why they don't (expressions on the return line, instead of 
simple uses of the variables), but that doesn't make me happy about having 
to explain the difference to others on my team.

Eric.



-- 
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 https://groups.google.com/d/optout.

[go-nuts] Is it possible to launch a Meltdown or Spectre attack with Go code?

['Eric Johnson' via golang-nuts]

Anyone have any insight into whether it is possible to launch a Meltdown or 
Spectre attack using Go code?

Go's general practice of preventing access beyond slice limits, and its 
habit of zeroing memory makes me think triggering a Spectre or Meltdown 
attack with Go code is very unlikely.

On the other hand, maybe clever use of the unsafe package means it is 
possible?

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: [urgent] need aguments to justify use of Go for a scientific application

['Eric Johnson' via golang-nuts]

One last bit of perspective here, which may be relevant to your project?

I've found that Go has the lowest cognitive load "switching" load. I have a 
job that mostly doesn't involve coding. When I get to code, I have a 
limited window in which I can jump in and make changes. Amongst the 
languages I've worked with, which includes Ruby, Python, Java, Bash, and 
C++, Go is the clear winner. By which I mean, the time it takes me to 
switch back to writing Go code and start making effective changes is 
shorter than it is with any other language I've mentioned.

With languages like Python and Ruby, I've found switching costs to be very 
high. The lack of compile time type-information means it is difficult to 
determine what the "type" of a parameter to a function, or the result of a 
method might be. You have to go and look at other chunks of code to figure 
that out, and that can be costly. Also, the use of exceptions means that 
there are always invisible control flows that are hard to remember / see 
when switching back to code.

With Java, the class hierarchy, the distinctions between public, private, 
protected, and package level accessibility all add complexity that some 
part of my brain needs to recall / rediscover before I can be confident of 
the correctness of a change.

C++ is even more complex than Java. Mental switching costs are even higher.

If your project is one that involves only short windows of opportunity to 
work on code, while mostly focusing on other tasks - like analyzing your 
data - then Go might be an enormous benefit. If your project is structured 
more like an ordinary software development project, with focused developers 
who can work on the project for four to seven hours a day, this aspect of 
Go won't matter.

Eric.


On Wednesday, December 6, 2017 at 1:56:01 AM UTC-8, Christophe Meessen 
wrote:
>
> Hello, 
>
> I'm a computer scientist in charge of developing an image processing 
> pipeline for telescope images. 
> It will also have a web server and DB connection.
>
> The project is going through reviews by external experts, and the problem 
> I'm facing is that my proposal to use Go is about to be rejected. 
>
> The main opposing arguments are 
> - everybody uses python in astrophysics
> - it is very easy to find someone who knows python
> - risk that I, sole Go programmer, might become unavailable
>
> I would have the same arguments if I was project leader and unfamiliar 
> with Go. 
>
> The counter arguments I found so far are that
> - Go is simpler and safer than Python
> - I learned Go in a week-end
>
> The problem is that they don't convince people who don't know Go, are not 
> experienced software developers, and don't want to do the due diligence. 
> It's the usual inertia to change.  
>
> What other arguments could I use ?
>
> Do you know other significant scientific experiments that have adopted Go 
> ? 
>
>
>
> I have found this github project. 
> https://github.com/indigo-astronomy/indigo
> INDI is a well known Python Observatory Control System. 
> INDIGO is its translation into Go. 
>
> I have also found SciPipe https://github.com/scipipe.
> It is a Go pipeline framework used in scientific applications. 
>
>
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 suggestion - what dependencies included in a build?

['Eric Johnson' via golang-nuts]

The compiler, at least, knows which packages were used to compile the
source. Even absent additional metadata from something like Gopkg.lock, the
compiler could still include info about the packages compiled into a
binary. Knowing that something might be vulnerable - but not knowing the
version from the executable - is still better than not knowing at all.

Eric.

On Wed, Aug 16, 2017 at 10:00 PM, Jakob Borg  wrote:

> Keep in mind that you can't assume vcs info is available at build time.
> They may be building from a downloaded tarball, in which case you *may*
> have a Gopkg.lock (if everyone uses dep) but not much else. They may be
> Debian and build from source packages where the Go compiler sees no version
> info at all - but the package manager knows the information you want. Etc.
>
> //jb
>
> On 16 Aug 2017, at 20:11, 'Eric Johnson' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> I note it as something for Go 2, if only because it would be good to
> standardize it across all Go binaries, so it was possible to introspect
> *every* Go executable. Otherwise, I have to push to get all teams using
> go to adopt the same approach to building in this information, rather than
> having each team do it different. On top of that, it still doesn't solve my
> problem for third-party already-built binaries.
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: defer func() { _ = resp.Body.Close() }()

['Eric Johnson' via golang-nuts]

For the truly paranoid, perhaps write a helper function "EnsureClosed()" or 
something like that, which will do the close, but perhaps also 
appropriately log a failure to close.

On Wednesday, August 16, 2017 at 5:05:39 AM UTC-7, Gert wrote:
>
> To pass errcheck I need to do something like
>
> defer func() { _ = resp.Body.Close() }()
>
> instead of 
>
> defer resp.Body.Close()
>
> Is this something the errcheck tool can figure out to mark as valid 
> instead or does the errcheck tool need help from the compiler so the second 
> case is also ok?
>
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 suggestion - what dependencies included in a build?

['Eric Johnson' via golang-nuts]

I note it as something for Go 2, if only because it would be good to
standardize it across all Go binaries, so it was possible to introspect
*every* Go executable. Otherwise, I have to push to get all teams using go
to adopt the same approach to building in this information, rather than
having each team do it different. On top of that, it still doesn't solve my
problem for third-party already-built binaries.

An indirect solution that captures the hash of the vendor directory
(presumably the git commit hash?), doesn't solve the problem particularly
well, even for internally built binaries, because I'd still then need to go
back to the source tree to answer the question - "is this executable
vulnerable?" That's more time consuming, more prone to failure, and the
failure modes are harder to resolve (don't have access to source code,
network is down, etc.).

We don't need to worry about this with dynamically linked libraries,
because we can actually see the versions of the libraries on the system
directly. To make the Go binaries functionality equivalent, I want to be
able to see the answer to the question without having to go to separate
systems.

Eric.


On Wed, Aug 16, 2017 at 9:10 AM, Lars Seipel  wrote:

> On Tue, Aug 15, 2017 at 04:58:00PM -0700, 'Eric Johnson' via golang-nuts
> wrote:
> > As I scan reports of vulnerable software, I'm concerned that it is
> > impossible to tell, from a Go binary, what was used to build that binary.
>
> A lot of projects are already doing this, if somewhat indirectly: they
> put a git commit hash into the binary that includes their (in-repo)
> vendor directory.
>
> Should vendor fall out of fashion at some point, one can surely come up
> with a different scheme. I don't see why this should be tied to a
> possible Go 2, though. It's pretty much independent from the language.
>
> Might be more appropriate to work on it in the context of dep. Could be
> as simple as making sure that dep can emit the required information for
> people to pick up during their build.
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Go 2 suggestion - what dependencies included in a build?

['Eric Johnson' via golang-nuts]

As I scan reports of vulnerable software, I'm concerned that it is 
impossible to tell, from a Go binary, what was used to build that binary. 
Which means that if I depend on some library that is discovered to have a 
vulnerability, I cannot look at each of the binaries I have deployed, and 
discover if those binaries are vulnerable. This is starting to worry me, as 
my company builds more and more software with Go.

Now that "dep" is emerging as a standard tool, perhaps we can include the 
dependency information in the built binaries in a way that is discoverable 
with a common tool?

Possibly we also want to establish a convention, such as a command line 
parameter "--buildinfo" that can be specified to spit out that very info?

I'm happy to contributing to further exploring implementation, but I 
figured I'd start by asking a question, in case someone is already working 
in this direction.

Eric.

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] No Allman-Style, No go!

['Eric Johnson' via golang-nuts]

On Saturday, September 21, 2013 at 7:04:09 AM UTC-7, Michael Daconta wrote:
>
> As you can see, the code has semi-colons in each required location.  So, I 
> ask you - why is the above code illegal?
>

Why is breaking the speed limit illegal? On many roads, it is set 
arbitrarily low because that's the way the neighbors want it, with no 
evidence that it makes anyone safer. In the case of Go, the spec defines it 
that way, that's why it is illegal. If you've ever written bash scripts, 
you likely know there are some very weird choices in that language too. 
That doesn't keep people from using it.
 

> All I've heard so far, is that "it is because the automatic insertion of 
> semi-colons requires this stupid behavior".  Given the above code should 
> require NO automatic insertion of semi-colons - why the stupid behavior?
>

Calling the behavior stupid will not win anyone over to your side.
 

> As for the folks on the thread saying "get over it" - sorry, I would turn 
> the question back to you and say - why are you blindly accepting something 
> so foolish?  There are things in a programming language that MUST be 
> enforced, this should not be one of them.
>

I've spent several decades programming. Brace style has never affected my 
ability to code effectively, and I've always needed to be flexible, in 
order to adopt to the tastes of the people I work with. So in that sense, 
it doesn't matter. Indeed, given a choice, I mostly prefer something that 
conserves on vertical space, since the view in my editor is a critical 
constraint, thus preferring to have braces on the same line. Python goes 
one step further and eliminates both braces, which is a step too far, for 
me. Entirely a personal preference, from what I can tell. As for having Go 
enforce a particular format, it turns out to be very valuable, because it 
means that looking at diffs in source control never has the problem of 
showing just changes to spaces, and you can look at anyone else's code, and 
see the exact same style. THAT was a very valuable design choice.

As for accepting something so foolish, *every* language has design 
trade-offs. I do not accept them blindly, but accept them deliberately.
 

>   So, either the language designers must admit their language is poorly 
> designed,
>

Nope - they just made a design trade-off that you happen to disagree with.
 

> or they need to fix the problem!
>

The Go community seems to be *very* pragmatic, and evidence driven. The 
language doesn't have features unless their needed. Can you define and 
demonstrate the problem? Can you show the brace style gets in the way of 
effective Go programming? If you can come up with relevant evidence, then 
you probably stand a chance of convincing people that the language at least 
needs to allow for braces on the next line, even if it isn't the default. 
Given that the industry has been chasing this question for decades, though, 
I don't think you'll find the evidence.
 

>   Ignoring the problem or flippantly asserting there is no problem,
>

The language designers used their combined decades of experience and made a 
choice. The community has accepted this design trade-off. Whereas, you 
assert there is a problem, but provide no data. That's the source of the 
skepticism.
 

> is the worst thing they can do as it goes against the very reasons you 
> design a new language for in the first place.
>

On the contrary, they made the language to suit their needs, and their 
background. Your mileage may vary.

Eric. 
 

>
> - Mike
>
> On Saturday, September 21, 2013 9:49:42 AM UTC-4, Rémy Oudompheng wrote:
>>
>> Compiler laziness is a minor argument. Humans must also understand 
>> semicolon insertion rules, justifying the choice of simple rules. 
>>
>> The choice of a standard formatting also makes the use of grep easier. 
>>
>>
>> 2013/9/21, Michael Daconta : 
>> > I assume you say this with tongue-in-cheek; however, I cannot believe 
>> this 
>> > design decision was made.  For something to borrow so liberally from C 
>> only 
>> > 
>> > to enforce "one-true" bracing style is frankly ridiculous. 
>> > When someone has coded for a long time using their favorite bracing 
>> style, 
>> > the numerous hours of frustration to learn this new language become not 
>> > worth it.  Just due to inadvertent, habitually return to a bracing 
>> style 
>> > the language designers deemed improper - which, in fact, is actually 
>> due to 
>> > 
>> > the laziness of their compiler.  I believe they could improve the 
>> compiler 
>> > to correct this.  So, while I could write my own compiler for this - 
>> there 
>> > is actually an easier solution, just ignore this language until the 
>> > language designers do the right thing.  And if not, ignore it all 
>> together. 
>> > 
>> > Though I like many features of the language from looking at the "go 
>> tour", 
>> > I can take it or leave it. 
>> > 
>> > While I new this post could be flame bait, I actually had to post it

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

['Eric Johnson' via golang-nuts]

Again, I'm mostly for generics being added to Go, because I've found 
occasion where they would be useful...

On Thursday, July 20, 2017 at 6:40:00 AM UTC-7, M P r a d e s wrote:
>
> Go could have least have parametric functions (ex :
>
> func Foo(value T)T { /.../ }
>
> bar := Foo(3) //types are verified at compile time, no need for 
> reflection or interface {} on any runtime trick.
>
> ).
>

To get at the value of adding generics, knowing what "Foo" is doing is 
important. Presumably, the function operates on "value" in some way.

Can we say that it implements an interface? Then let's suppose the 
existence of an interface "X". I can currently rewrite your "Foo" function 
as:

type X interface {
Clone() X // documentation needed to clarify that the clone is really 
of the derived type implementing X.
DoFoo()
}

func Foo(value X) X {
   result := value.Clone()
   result.DoFoo()
   return result
}

Now supposing I have a struct B, where *B implements "X", and is currently 
in variable "orig".

When calling this, to reflect that the result of Foo is still of type *B, 
the following is required.
   fooClone:=(*B).(Foo(orig))

What I want to be able to write, and have *B as the type of "clone":
   fooClone:=Foo(orig)

What we need the function signature to specify, then, is two pieces of 
information, that the parameter "value" is of the same type as its return, 
and that it implements interface "X". Also, my intuition suggests 
distinguishing generic types from concrete ones syntactically, so add an 
indication that's true. Perhaps try a few (+, ^, %).

A bunch of options that all get at the same idea, using different 
characters and different approaches:
func Foo(value T^->X) T^
func Foo(value T%:X) T%
func Foo(value T+:X) T+
func FooX>(value T^) T^
func FooX>(value T%) T%
func FooX>(value T+) T+

where the "->" could really be anything syntactically appropriate, but what 
it means is "T" implements X. Again, not sure of the right syntax, and not 
sure this is required.

In the "X" interface itself, we have a slightly different problem for the 
"Clone" method. We need someway to indicate "the concrete type of the 
thing". For that, we use the syntax indication of a generic type (^, %, or 
+, above) appended to something. "@" seems like a natural fit. That 
probably needs to look something like this:

Clone() @^

Putting it all together, choosing my favorite representation from above:
type X interface {
Clone() @+
DoFoo()
}

func Foo(value T+:X) T+ {
   result := value.Clone()
   result.DoFoo()
   return result
}

Now, I can write what I wanted to write:

fooClone := Foo(orig)

There's a *completely separate question* as to whether the compiler 
generates code that is effectively of the form:
fooClone := (*B).(Foo(orig))

I'm not sure I care about that. I'm more concerned about the correctness of 
the code.

Eric.
 

>
> But talking about this is kind of useless until Go rids itself of its over 
> reliance on runtime features like reflection. I suspect Go reflection 
> capabilities are why the language stopped evolving significantly at first 
> place. String tags are another symptom of that "disease".
>
> It's possible to write the snippet above with reflection today 
> (reflect.MakeFunc) , it shouldn't be.
>
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: "interface{} says nothing", lets consider it destroys information

['Eric Johnson' via golang-nuts]

While I lean towards the view that Go should add support for type generics, 
I'm not sure your example actually provides sufficient detail to be an 
argument for them.

On Monday, July 17, 2017 at 2:07:46 AM UTC-7, mhh...@gmail.com wrote:
>
> in func do(i interface{}) interface{} (return i), do says nothing because 
> "interface{} says nothing", 
>
> from the caller pov, it looses information at the return call, 
>
> var x = "o"
> do(x) // <- return lost the track it was a string
>
> if you delegate that func to another func, 
> it can t says anything else rather than nothing unless it introduces type 
> assertion.
> func to(do func(interface{})interface{}) func (interface{}) interface{} { 
> return func (i interface{}) interface{} {return do(i)} }
>
> if the observation become "interface{} destroys information", 
> does it make sense to consider a "value type of any type that carries out 
> its input type" ?
> func do(any )  {return any}
> do("thing") <- this is explicitly string
>
> Acting the same way as interface, except that little thing about 
> destroying/preserving an information.
>
> It can be delegated to func that works on anything, still returns concrete 
> types.
> func to(do func(**)) func () ** { return func (i )  
> {return do(i)} }
>
> to(do)("whatever") // got a string, right ?
>
> One step forward, 
> what if  might be able to say "any type with a constraint on that 
> interface",
> func do(any )  {return any}
> do(WhateverStringerCapable{}) <- much like using a regular parameter of 
> type Stringer/interface{}, but now the return call reflects the invoke call 
> , so its more complete than interface{}/Stringer.
>

If the "do" method takes and returns a Stringer, then why not just declare 
it that way? To make this a more interesting discussion, you have to get 
into the details of what the "do" function actually needs to do? Why can't 
it just use standard interfaces?

As I see it, one of the generics problems comes from using the built-in 
slices and maps. As it current stands, if I create a method:

func concat(foo []Stringer) String {
result = ""
for _, s := range foo {
result = result + s.String() + ";
}
return result
}

but suppose I have two structs, Foo, and Bar, and both *Foo, and *Bar 
implement Stringer.

I cannot do this:
func myFunc(f []*Foo, b []*Bar) string {
return concat(f) + concat(b)
}

This seems like a more concrete scenario than the one you identified.

Eric.
 

>
> no?
>
> Or maybe there is a reason in destroying that information ?
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Are functional options idiomatic

['Eric Johnson' via golang-nuts]

On Sunday, July 9, 2017 at 9:12:06 PM UTC+2, Anmol Sethi wrote:
>
> Hello everyone!
>
> I’m writing a new library where I need to be able to configure a struct. 
> This struct and its configuration will be accessed concurrently. One design 
> pattern I see throughout the standard library and community is to make the 
> struct and its configuration fields public but all other fields private. 
>

> e.g.
>
> type MyServer struct {
> ConfigureMe int
> usedInternally string
> }
>
> This nicely complements Go’s default values and is very terse to use. This 
> is exactly how structs such as http.Server and autocert.Manager (part of 
> the new acme library) are used.
>
> As aforementioned, the configuration fields in my struct need to be 
> accessed concurrently. My issue is that since the configuration fields are 
> public, they can be freely mutated by a package user and so a race 
> condition may occur. I’m not sure how big of an issue this is considering 
> its very unlikely that someone will mutate the struct once its being used 
> but the design feels a bit fragile to me.
>

As you point out, race conditions might be a problem. That depends whether 
your configuration involves maps, or if it involves multiple parts of the 
configuration that a client might need to change together. If that's the 
case, then don't do it that way. This depends, in part, on whether or not 
your object can be seamlessly reconfigured at any time.

Another way of configuration options that I've considered involves using 
shadow configuration. Let clients change publicly accessible fields, and 
shadow the former values. This approach might be useful if your service can 
only change the actual configuration at specific times. When you hit those 
points, check the configuration in the struct versus the one previously 
used. When different, change and update the shadowed version.
 

>
> In search of a better way, I thought about using a config struct but then 
> I found Dave Cheney’s post 
> https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis about 
> using functional options and now I’m thinking of using those. However, I 
> haven’t seen this API design used anywhere at all in any library I have 
> ever used (or in the standard library at all) so I was wondering whether or 
> not it’s idiomatic.
>

Seems idiomatic to me. However, it does bake in a particular pattern of 
configuration that can only be done once, with an initialization function, 
rather than configuration that can be updated at any time.

>
> I’m not sure if I’m being overly pedantic in my criticism of having the 
> configuration fields public in the struct. I don’t have too many 
> configuration fields so maybe functional options will be overkill.
>

Seems to me the two approaches satisfy different needs. Public fields of a 
structure imply full configurability on the fly - such as logging 
configuration, whereas Cheney's approach implies configuration at launch. 
You might, in fact, need to use both.
 

>
> I’m not really sure what I should go with now and I’ve hit a mental block 
> with my design. I’m hoping someone will have some thoughts on what approach 
> I should go with.
>

Start with simpler. If you can change configuration on the fly, but need to 
worry about race conditions, then provide a method to update the config 
regardless.

Eric

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Handling errors in functions

['Eric Johnson' via golang-nuts]

My take is something like the following would be more idiomatic

// SummonerByName returns profile address and an error. We need it in case 
where
// we cannot get the profile for some reason
func SummonerByName(name string, server string) (*SummonerProfile, error) {
 var resp, err = http.Get(fmt.Sprintf(ENDPOINT, server,name,string(KEY)))
 if err != nil {
return nil, fmt.Errorf("GET request from RITO's API error: %v", err)
 }
 defer resp.Body.Close()
 
 var profile SummonerProfile
 if resp.StatusCode != http.StatusOK {
 return nil, errors.New("The resp code was not 200")
 }
var rawBytes, err := ioutil.ReadAll(Response.Body)
if err != nil {
return nil, fmt.Errorf("problem reading stream: %v", err)
}
if err = json.Unmarshal(rawBytes, &profile); err != nil {
return nil, fmt.Errorf("JSON decoding problem: %v", err)
}
 return &profile, nil
}

Eric

On Wednesday, June 21, 2017 at 5:44:36 AM UTC-7, Martin Spasov wrote:
>
> Hey,
>
> Is it possible to give a default nil value to an error at the beginning of 
> a function and then just assign to it in case of need ? What I want to do 
> is something like the following : 
>
> func GetSummonerByName(name string, server string) *SummonerProfile err  {
> //The function should return profile address and an error. We need it in 
> case where we cannot get the profile for some reason
> var Response,ResponseError  = http.Get(fmt.Sprintf(ENDPOINT, 
> server,name,string(KEY)))
> var profile = SummonerProfile{}
> var err = nil
> if ResponseError != nil {
> err := errors.New("Error with the GET request from RITO's API")
> } else if Response.StatusCode != 200 {
> err := errors.New("The response code was not 200")
> } else {
> //
> var ByteResponse, ByteError  = ioutil.ReadAll(Response.Body)
> if ByteError != nil {
> err := errors.New("The ByteReader did not work properly")
> } else {
> var err = json.Unmarshal(ByteResponse, &profile)
> if err != nil { 
> err := errors.New("The decoding of the JSON went wrong")
> }
> }
> }
> defer Response.Body.Close()
> return &profile, error
> }
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] package/ to help with testing of "Read()" failures...?

['Eric Johnson' via golang-nuts]

Looks like iotest package provides tools to simulate various weird read 
behaviors.

However, I want to simulate a failure, instead of just a slowdown or a 
change in whether the EOF error is returned after the last full read. 
Something like "ReadFailAfterN" which will trigger a non-EOF error after N 
bytes read

Googling for various combinations of keywords hasn't gotten me very far, 
because "fail" and "error" come up too commonly.

Anything out there?

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Runtime code generation?

['Eric Johnson' via golang-nuts]

Indeed. This is the same answer I was going to give.

Run-time code generation implies a whole bunch of different scenarios with 
a whole bunch of use-cases. There are resource sharing concerns, security 
concerns, and performance concerns that need to be nailed down. Otherwise 
it is difficult to identify whether it is possible or desirable to 
accomplish what the original post is inquiring about.

Eric.

On Wednesday, May 10, 2017 at 3:19:51 PM UTC-7, Erwin Driessens wrote:
>
> You could let your application generate valid Go source, call the compiler 
> to build a plugin, and load that plugin. I haven't tried that yet, but i 
> think it should work. Downside is that you need to Go tools on the target 
> machine for it to work. I don't know how many times you have to generate 
> new functions, the plugin system can't unload a plugin, so things might not 
> go so smoothly when you need to do this a lot of times in a single run of 
> the program.
>   
>
> On Friday, August 30, 2013 at 10:21:18 PM UTC+2, jzs wrote:
>>
>> Hi gophers,
>>
>> I was studying runtime code generation and was wondering if there's a way 
>> to generate a function at runtime.
>>
>> Let's say we have a function: fun(a,b) {return a+b}
>>
>> This function is parsed to our program as a string, parsed and compiled 
>> to a function in go.
>>
>> In C# and java you can do this as you have access to the clr and jvm 
>> which can jit compile your function for you.
>>
>> Now go is a statically compiled language and as far as I can see the 
>> reflect package is not powerful enough for such operations.
>>
>> Are my assumptions correct that this is not currently possible? 
>> Could it be done through cgo?  (If yes a hint to c documentation would be 
>> nice :) )
>> Would it be possible in go in the future?
>>
>> Creative ideas are welcome but prefer portable solutions so no assembly 
>> generation through c or such :)
>>
>> For performance reasons it wouldn't be beneficial to have a. Net runtime 
>> running that you sent a million requests to.
>>
>> Kind regards,
>> Jzs.
>>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Is it ok to separate Open and Close logic?

['Eric Johnson' via golang-nuts]

In this kind of scenario, I recommend a (type) wrapper for *File

Rework the code as:

type Doer *File

func NewDoer(f string) (Doer, err) {
  file, err := os.Open(f)
  // ...
}

func (d Doer) Close() error {
  return d.Close()
}


Everything else being the same, your caller can then expect "New()" 
followed by "defer Close()", so that they can do the right thing.

Eric.

On Wednesday, May 10, 2017 at 8:55:35 AM UTC-7, st ov wrote:
>
> Most examples of opening and closing a file have both calls in the same 
> function
>
> func DoFileStuff() {
>   file, _ := os.Open("file")
>   defer file.Close()
>
>   // do stuff with file
> }
>
> This makes sure any open file is closed.
> But how common is it to separate that logic into functions? 
> Should this be absolutely avoided as it could result in a file left open?
>
>
> func DoStuff(f string) {
>   file := OpenFile(f)
>
>   // call DoingStuff for some practical reason
>   DoingStuff(file)
> }
>
> func DoingStuff(f *File) {   
>// do stuff on file
>Cleanup(f)
> }
>
> func OpenFile(f string) *File {
>   file, _ := os.Open(f)
>   return file
> }
>
> func Cleanup(f *File) {
>   f.Close()
> }
>
>
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] "Selling" Go to Management

['Eric Johnson' via golang-nuts]

Just answered a question on Quora today that might be helpful:

https://www.quora.com/Why-would-anyone-program-in-Go/answer/Eric-Johnson-157?share=ca0e6b40&srid=zEgo

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Introspecting a built Go application - how?

['Eric Johnson' via golang-nuts]

A question has been bugging me for the past few weeks. How can I tell what 
was used to build a Go application?

As I see various security notices scrolling by my email inbox, I see things 
like Tomcat or OpenSSL announcing security updates,  the JRE, or for that 
matter, Go itself.

Once I see one of those alerts, frequently I want to be able to ask, "are 
the systems I administer affected?"

For a first approximation, StackOverflow says:
https://stackoverflow.com/questions/18990242/find-out-the-version-of-go-a-binary-was-built-with

But that doesn't appear to work with the first Go executable I tried (on 
macOS).

Version of Go is a start, but it would also be great to know the packages. 
After a point, I don't expect many ongoing security issues with the Go 
standard library, but I do expect to see more problems with the supporting 
packages, so I want to know those, too!

If I know the packages, even better if I can know the versions of those 
packages, or perhaps the version control commits?

Is this a known planned feature? Is there an existing way to do this that 
I've overlooked?

Eric.

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

['Eric Johnson' via golang-nuts]

My 2 cents:

On Saturday, April 1, 2017 at 4:26:20 AM UTC-7, Axel Wagner wrote:
>
> Ian:
> Re your question: See my example given above (or the one below, which is 
> probably more authentic). For example, you might be allocating the returned 
> struct, and piece by piece filling in the fields. If there can be errors, 
> the natural expression might be, to just return the allocated struct, 
> whereas to then return nil, you need to explicitly branch. For example, say 
> I'd want to have a type which operates on some file:
>
> type Foo struct {
> file *os.File
> }
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> return &Foo{
> file: f,
> }, err
> }
>
> vs.
>
> func NewFoo(fname string) (*Foo, error) {
> f, err := os.Open(fname)
> if err != nil {
> return nil, err
> }
> return &Foo{
> file: f,
> }, nil
> }
>
> I would usually write the latter version, even if the former is shorter 
> and the extra branch isn't necessary, because people shouldn't rely on the 
> first return if there's an error anyway.
> Because I do feel like people might not be so careful and then 
> dereferencing a nil *Foo will be a clearer symptom to debug, than debugging 
> whatever weird value Open might theoretically return being used 
> accidentally.
>

I have chased enough evil uninitialized variable bugs in my time to come 
down strongly on the side of, when there's an error, return unusable data. 
It need not be nil, but it needs to fail immediately upon use. In the file 
case above, the "file" member may be unusable, but the instance of the Foo 
object may work just fine for some number of methods.Without seeing your 
whole implementation of "Foo", it is impossible to tell whether returning 
non-nil value here is a problem. If there are a bunch of methods that can 
work if the "file" member is broken, then returning "nil" is a courtesy to 
future users of your API. However, you can start painting yourself into a 
corner quickly. You don't have a guarantee that Open will return "nil" in 
case of error, so how can the other methods of your structure tell whether 
the object is improperly initialized? The only way you get there is by 
having a specific "if" statement that checks the error, and sets the "file" 
member to an explicit value. Or you could just return "nil" for *Foo.

It is worth keeping in mind that:

func (f *Foo) doSomething() {
   // ...
}

... it is perfectly valid for "f" to be nil. So be careful out there.

Others have also noted partial read scenarios, where returning some data 
makes sense. Those should be commented specifically. In other cases, 
though, your documentation could at most state the return an unusable value 
in cases of error, without specifying whether it is nil or not.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: the case for returning interface vs struct

['Eric Johnson' via golang-nuts]

Structs give the caller so many immediate benefits:

   - If there's internal state that clients shouldn't muck around with, 
   then (a) keep a field private, or (b) keep a field private and make it a 
   pointer to state (such as mutexes).
   - Structs can be copied directly.
   - Set and get don't require more methods

On that basis alone, even for simple structures, code saves at least three 
methods in an interface (one "set", one "get", and one "Clone"). Less code 
to maintain all around.

On top of that, when writing test code, mocking out someone's else's API, 
returning structs results in more maintainable code. Why? If the API 
returns a structure, then the mock must define an interface that captures 
precisely what is needed from the structure. Whereas, if an API returns an 
interface, then the mock implementation may not bother with defining a 
subset interface, thus writing a much larger mock implementation than 
needed. Again, less code to maintain.

In the end, Go gives you the power to choose either approach, depending on 
the situation. From my experience with Go code, the default position to 
return structures (well, typically pointers to structures) ends up being 
less code, and easier to understand over time. It also forces the design of 
libraries to be open about the contents of structures, which usually 
results in easier to understand APIs.

Eric.

On Wednesday, March 1, 2017 at 8:01:14 PM UTC-8, Henry wrote:
>
> Hi, 
>
> I am trying to come up with a general guideline about returning struct vs 
> returning interface. I have used both approaches. Despite the common wisdom 
> is to return struct, I believe that returning interface is generally 
> superior to returning struct. Here are my arguments for returning interface:
>
> First, you may not want your data type to be copied by value. The data 
> type may contain mutexes, references to other data types, etc. If you 
> are returning struct, you may need to put comments in your code to prevent 
> people from copying your data type by value. Note that this isn't ideal 
> because an implementation is supposed to be a black box and the user should 
> not need to know whether there is a mutex, etc. inside the struct.  
>
> //DO NOT COPY. I MEAN IT!
> type VolatileDataType struct{
>mtx sync.RWMutex
>data  map[string]OtherData
>//etc..
> }
>
> With the above comment, while people may remember not to do this:
> myCopy := myVolatileDataType //myVolatileDataType is of type 
> VolatileDataType
>
>
> It is harder to prevent people from doing these:
> func DoWork(data VolatileDataType){
>//...
> }
> //or this 
> func DoWork() VolatileDataType{
>//...
> }
> //or this
> myChannel := make (chan VolatileDataType)
>
>
> If you are returning interface, you avoid all these complications in a 
> somewhat simpler way:
> type VolatileDataType interface{
>Clone() VolatileDataType
>//...
> }
>
> type volatileImpl struct{
>mtx  sync.RWMutex 
>data map[string]OtherData
>//etc...
> }
>
> func NewVolatileDataType() VolatileDataType{
>return &volatileImpl{
>   //etc...
>}
> }
>
>
> By returning interface, people can do all the followings without any 
> problem. You are actually passing around references to the actual object, 
> and you will have to explicitly call its copy method if you need a copy.
> myPtr := myVolatileDataType //in the case of passing the actual data type 
> around 
> //or
> myCopy := myVolatileDataType.Clone() //if the data type supports copying
>
> func DoWork(data VolatileDataType){
>//...
> }
>
> func DoWork() VolatileDataType{
>//...
> }
>
> myChannel := make (chan VolatileDataType)
>
> In the case where your data type can be safely passed around by value, it 
> doesn't matter whether you return interface or struct. So there isn't 
> a problem in returning interface.
>
> Second, returning interface removes the need for dereferencing your data 
> type. It results in a cleaner syntax. It also allows better equality 
> comparison. Structs that contains map, etc. needs deeper equality 
> comparison.
> s1:= MethodStruct1() //func() MyStruct
> s2:= MethodStruct2() //func() *MyStruct
>
> if s1 != *s2{
>//do something
> }
>
> i1:=MethodInterface1() //func() MyInterface
> i2:=MethodInterface2() //func() MyInterface
>
> if i1.Equal(i2){
>//do something
> }
>
>
> Finally, even if you are returning interface, you can still accept a 
> subset of its interface (per Go's wisdom of accepting small interface).
> type VolatileDataType interface{
>String() string
> }
>
> func NewVolatileDataType() VolatileDataType{
>//...
> }
>
> func Print(target Stringer){
>   //...
> }
>
> Print(NewVolatileDataType()) //still works fine.
>
>
> I wonder whether it is correct to conclude that in general people should 
> return an interface, unless there is a real reason not to. Or better is "to 
> accept and return interfaces".
>
> Let me know what your experiences are regarding this matter.
>
> Th

[go-nuts] Re: Should a program always exit in main()?

['Eric Johnson' via golang-nuts]

On Tuesday, February 7, 2017 at 3:12:13 PM UTC-8, Francis Chuang wrote:
>
> I am working on a client library that starts a Kafka consumer to listen 
> for messages from a kafka stream and run some user defined handlers.* I 
> want the design to be "crash-only" as much as possible*, so will be 
> avoiding cleanups during unexpected shutdowns.
>

That's sort of a curious model. Your description would make sense if you 
were describing an application, but you're describing a library. By 
building that design assumption into your library, you're limiting the 
possible uses of the library. That approach also makes it incredibly 
difficult to write unit-tests for your code.
 

>
> For example, here's a simple sketch:
>
> func myHandler(m client.Message) error{
> ...
> }
>
> c := client.New(...)
> c.AddHandler(myHandler)
> c.Start()
>
> c.Start() looks like this:
>
> func (c *Client) Start(){
>   
>for{
>  select{
>
>case m := <-c.message:
> 
>  for _, handler := range c.handlers{
>   err := handler(m)
>  }
> }
>}
> }
>
> If the handler encounters an error, I have the following options:
> - call log.Fatal() within the for _, handler := range loop. This seems to 
> be the simplest, but it doesn't seem right for a library to exit.
> - remove the return error from the handler, and call log.Fatal() within so 
> that the handler terminates the whole program.
> - create an error channel, have the for _, handler := range loop write 
> errors to that channel. In main(), have a for, select loop to read from the 
> error channel and call log.Fatal() there.
>

Only the last one seems acceptable for logic in a library. Because the 
decision to exit the program actually no longer belongs to the library, but 
to "main()", or a function called from main(). Not even clear to me that 
you want to call log.Fatal() there, either. Since you're talking about 
multiple Go routines, it sounds like you may have a race condition where 
multiple errors may have occurred. By calling log.Fatal(), you're 
guaranteeing that only one of those errors will be printed. The error 
message you may get may not be the most useful or relevant one, depending 
on the errors, and the race condition problems.

Instead it seems like you might want to do proper cleanup of all the 
launched goroutines, and then drain the error channel in main(), and then 
exit. That way, you get all the error messages.
 

>
> Which of these options is the most idiomatic?
>

Exiting the program abruptly is not idiomatic. The one that moves that 
decision closest to the "main()" function seems like the best idea.

Eric.
 

>
> Cheers,
> Francis
>

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: How has your company adopted Go ?

['Eric Johnson' via golang-nuts]

> On Jan 3, 2017, at 8:47 AM, Haddock  wrote:
>
> I large organization where Java JEE architects are around bringing Go into 
> the game is almost impossible. Many architects have build up their careers on 
> application servers and EJBs without really understanding what that big big 
> hammer is needed for in that situation and just keep repeating the same 
> recipes.

I suspect large organizations are much more amenable than you think.
What with all the development that targets browsers, the prototyping
that might happen in Python, and all the small utilities that they
certainly need to build, there's probably much more opportunity than
you expect.

Eric

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: How has your company adopted Go ?

['Eric Johnson' via golang-nuts]

Stand-alone services are definitely the way to go. Pick a small service
that either is yet to be written, or is performing badly in its current
Java implementation.

Eric

On Dec 29, 2016, at 12:35 AM, Haddock  wrote:

This thread is very interesting to me as I'm working exclusively with Java
and am looking for ways to bring in other approaches such as using Go.
Could some of you drop some few lines in what way in your company Java is
combined with Go? That would give me an idea where to start experimenting
in order to show some use cases to my boss.

Thanks, Haddock

-- 
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.google.com/d/topic/golang-nuts/UE8NGYbb6ec/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: How has your company adopted Go ?

['Eric Johnson' via golang-nuts]

On Monday, December 19, 2016 at 5:03:43 AM UTC-8, Tieson Molly wrote:
>
> What arguments or factors have contributed to your company adopting Go?
>

My company does enough different kinds of work that the question is too 
broad. To some, "adoption" might imply broad usage. In practice, usage 
evolves over time, and use of Go is slowly increasing over time.
 

>
> Many businesses see switching to a new language or even using a new 
> language side by side with their existing  language choice as a business 
> risk.
>

My company primarily used to use Java. In recent years we've explored 
options other than Java for two reasons that I can tell, because of the 
pressure Oracle has started putting on the Java ecosystem, and because 
there are many more viable options to Java than their used to be.

We looked at other JVM languages. Besides the fact that they didn't get rid 
of the potential licensing issues from Oracle, they also implied a lot of 
investment in learning new syntax and programming languages, but without 
any significant change in the runtime profile of the resulting programs. 
Seems like a very expensive effort for minimal gain.

That meant exploring the non-JVM languages. D, Rust, Go, Javascript, 
Python Go is, well, ... practical and effective in many cases.

Eric.
 

>
>   Best regards,
>
>   Ty
>
>
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: With GO - Can I say Procedural is better than OO?

['Eric Johnson' via golang-nuts]

On Saturday, September 24, 2011 at 9:14:22 AM UTC-7, nvcnvn wrote:
>
> I just read here: 
> http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_language 
> And all of the GO example we have is not writen in OOP way. 
> So can I say that GO see the benefit of  Procedural  over OO!? 
>

Object oriented programming means different things to different languages.

Depends on the examples you're looking at. For most example code in the 
standard docs, you're looking at a demonstration of an API. You instantiate 
a structure, and call a method or two on that structure. It doesn't "feel" 
object oriented, because you're talking about methods on a type (usually a 
structure) instead of a class. Once you start adding in interfaces when you 
need them, your perspective on the language may change considerably.
 

>
> For myself, I fell ok with Procedural programming! Just need to stay 
> come, do some document for your code and that will help me avoid 
> duplicate of code, or easy to maintain and modify my code.


As with all things programming, best to learn a number of different 
paradigms, so you can apply the right one in the right context.

Eric.
 

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Beautify XML

['Eric Johnson' via golang-nuts]

On Friday, November 4, 2016 at 2:32:24 PM UTC-7, Tong Sun wrote:
>
> How to beautify a given XML string in GO? 
>

As someone who has spent a fair amount of time in the complexities of XML, 
it is worth noting that XML is not equivalent to JSON in the context of 
your question.

Only with a schema or a DTD for the XML instance in question can you be 
certain of whether or not white-space is significant.

There's also considerations like canonicalization and normalization, which 
also don't apply to JSON.

When generating XML from a data structure, you can already know where the 
data structure would ignore white-space. So it would be possible to 
generate "beautiful" XML in that context, but it has to be done as part of 
the generation. The beautification cannot be done *safely* by some tool 
after-the-fact, at least not without much further context (schemas, DTDs, 
etc.), or without assumptions by the user of such an API.


> The xml.MarshalIndent() only apply to a GO structure, not XML strings. 
>

Yes. See my points above.

Eric.

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: package versioning

['Eric Johnson' via golang-nuts]

On 10/12/16 2:32 AM, Peter Vypov wrote:



On Wednesday, October 12, 2016 at 2:04:19 AM UTC+2, Eric Johnson wrote:

My view is that the general case requires putting such metadata in
a separate file for a package.

Yes, I agree with you that having multiple Go files with such comments 
creates repetition (having to update multiple files) and forgetting to 
update one of those makes it ambiguous which particular version is 
going to be installed.


[...] after the current package management efforts nail down that
metadata file.

Having been working with dependency management tools such `godep` and 
`glide` would much prefer not to deal with any metadata files at all, 
with their location, format, and naming conventions.
I suspect the annoyance of this will disappear when the team trying to 
standardize this actually succeeds, and then it is always the same 
metadata files. Then, you'll eventually be glad they're there.


How about an implied metadata file when you specify package versions 
on the `go get` command line but nowhere in source code or metadata 
files. Would such a tradeoff work?


|
go get-u github.com/spf13/cobra:v1.10.0\
  github.com/spf13/viper:v0.10.0\
  github.com/pelletier/go-toml:v0.3.4

|

This has a drawback that dependent packages are going to be installed 
as their latest versions, so the ordering is important.


If I can't source control it, I don't think it will work.



The reason for asking this question is that in recent months tools 
like `glide` (https://github.com/Masterminds/glide) gained popularity 
and some third-party packages require you to do `glide up` to populate 
it properly in addition / instead of the regular `go  get`. This means 
that for a package that uses such a glided package, you'd need to 
create a Makefile (or shell script) with a `glide up` and other 
non-`go` commands in it (which is ugly).


Again, hopefully the dependency management team will make some headway. 
Then we might see an evolution of the standard tools.


Eric.

--
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 https://groups.google.com/d/optout.

[go-nuts] Re: package versioning

['Eric Johnson' via golang-nuts]

On Tuesday, October 11, 2016 at 5:55:23 AM UTC-7, Peter Vypov wrote:
>
> This question has been asked here a number of times, but the last time a 
> few months ago: are there any plans to add support for package versioning 
> (understanding VCS tags in the import paths), that is to teach `go get` to 
> pull specified version (tag) of the package rather than the most recent 
> version? As an alternative to storing packages in /vendor.
>
> My suggestion would be similar to Mr. McVetta's in 
> https://groups.google.com/forum/#!searchin/golang-nuts/package$20versioning%7Csort:relevance/golang-nuts/-65WPrNcT3U/5w1mkmE-4BsJ,
>  
> but specifying the version as a comment tag rather than in the import path. 
> This should be sufficient to prevent importing two different versions of 
> the same package.
>
> import (
> ...
> "github.com/spf13/cobra" // v0.8.0 
> "github.com/spf13/viper" // v1.10.0
> )
>

My view is that the general case requires putting such metadata in a 
separate file for a package. For example, an obvious problem case - what if 
you have multiple source files in the package? I suspect that's where the 
Go Package Management team ends up.

So my guess is that any convention / language standard around putting such 
versioning comments in to the source files would only be considered / 
settled after the current package management efforts nail down that 
metadata file.

Two possible use cases come to mind:
1) Convenience over using a separate file for stating dependencies.
2) Support for "go run" type usage that automatically fetches 
dependencies

The first case seems to be antithetical to the Go design principles of 
keeping language features orthogonal, and avoiding having multiple ways of 
doing the same thing. The second case seems possibly interesting, but 
implies a lot of mechanism for a rare case.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: Licenses

['Eric Johnson' via golang-nuts]

On Thursday, September 29, 2016 at 1:12:41 AM UTC-7, dja...@gmail.com wrote:
>
> Hi,
> May be OT, but:
>
> Can i  translate some GPLv2 licensed C code to GO, and publish it under 
> BSD new license ?
> Code comments are from original C code.
>

The correct way to do this would be to perform a "clean-room" 
implementation. Have one person create a specification based on the 
original C library, and have a second person implement the specification. 
Ideally, the form of the specification is neither C nor Go. The second 
person should not, under any circumstances, look at the original C code.

Eric

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Mocking os.Open and related calls for more code coverage

['Eric Johnson' via golang-nuts]

Why not, instead of passing a file path as a parameter, pass a function that 
returns a ReadCloser (and error, of course). That way, you can preserve the 
existing semantics of your function, but move the decision of what to open, how 
to open, and how to handle the error for when it fails - all out of your 
function.

Or just use a temp file.

Eric

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Eric Johnson' via golang-nuts]

On 8/31/16 2:04 AM, Harald Weidner wrote:

Hello,

On Tue, Aug 30, 2016 at 04:41:29PM -0700, 'Eric Johnson' via golang-nuts wrote:


I looked at the k-nucleotide program, and was unable to figure out a way to
make it faster.
This is, of course, exactly what the test is suppose to be checking - the
speed of the built in map. Anyone else have any insight?

The Java counterpart of this benchmark does not use the Java build-in
maps, but imports a map implementation for fixed data types from the
fastutil project.

http://fastutil.di.unimi.it/

I hadn't noticed that. That would seem to violate the spirit of the test:
"The work is to use the built-in or library hash table implementation to 
accumulate count values - lookup the count for a key and update the 
count in the hash table. Don't optimize away the work."


Eric.

--
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Eric Johnson' via golang-nuts]

I looked at the k-nucleotide program, and was unable to figure out a way 
to make it faster.


Most of the time appears to be spent on this one line:
pointer, ok := counts[key]

pprof reports:
   19080ms 56.50% 56.50%22100ms 65.44% runtime.mapaccess2_fast64

This is, of course, exactly what the test is suppose to be checking - 
the speed of the built in map. Anyone else have any insight?


Eric.

On 8/30/16 3:46 PM, Michael Jones wrote:


I looked at that this morning and sped it up a little.

*From: *'Isaac Gouy' via golang-nuts 
*Reply-To: *Isaac Gouy 
*Date: *Tuesday, August 30, 2016 at 12:15 PM
*To: *golang-nuts 
*Subject: *[go-nuts] Re: In case you missed it: language benchmarks 
for Go 1.7, and language adoption




On Tuesday, August 30, 2016 at 10:09:39 AM UTC-7, Scott Pakin wrote:

Go 1.7 is faster than C on the mandelbrot test and faster than
C++ also on reverse-complement?  How did /that/ happen?


mandelbrot -- look at the program source code.

-- 
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 https://groups.google.com/d/optout.

--
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.google.com/d/topic/golang-nuts/dyq3z5dWqrc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 https://groups.google.com/d/optout.

Re: [go-nuts] In case you missed it: language benchmarks for Go 1.7, and language adoption

['Eric Johnson' via golang-nuts]

Well, sure. I read that too. I think it is still useful that my intuition
that Go is gaining adoption aligns with what prominent metrics are
reporting, even if it is because the reporting changed how they measured.

Eric.

On Mon, Aug 29, 2016 at 5:22 PM, Ian Lance Taylor  wrote:

> On Mon, Aug 29, 2016 at 4:51 PM, 'Eric Johnson' via golang-nuts
>  wrote:
> >
> > And then, for language adoption, the TIOBE language index for August of
> > 2016:
> > http://www.tiobe.com/tiobe-index/
> >
> > (Note that the above is updated every six months, and I've not been able
> to
> > find a link to previous versions of the reports, however, you can look
> for
> > the trend for Go itself http://www.tiobe.com/tiobe-index/go/ ).
> > Go finally breaks into the top twenty.
>
> It's because they changed their definition of Go.  Quoting from
> farther down the page: "The restriction "Google" has been removed from
> the search queries for the programming language Go. Ilja Heilager
> sorted out that without the search term "Google" the resulting Go hits
> are still referring to the Go language. After having removed this
> restriction Go jumped from position #55 to #20. Thanks Ilja!"
>
> Ian
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] In case you missed it: language benchmarks for Go 1.7, and language adoption

['Eric Johnson' via golang-nuts]

Not that I think these account for much, but sort of fun to point at:

https://benchmarksgame.alioth.debian.org/u64q/go.html
(Short summary - now with Go 1.7, Go is faster for most benchmarks.)

And then, for language adoption, the TIOBE language index for August of 
2016:
http://www.tiobe.com/tiobe-index/

(Note that the above is updated every six months, and I've not been able to 
find a link to previous versions of the reports, however, you can look for 
the trend for Go itself http://www.tiobe.com/tiobe-index/go/ ).
Go finally breaks into the top twenty.

As with any metrics, these are selective measures, and not really good 
indicators by themselves. But at least they're positive with respect to Go.

Eric.

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Re: defer at struct level

['Eric Johnson' via golang-nuts]

On Sunday, August 21, 2016 at 3:04:02 PM UTC-7, Asit Dhal wrote:
>
> Hi all,
> I use defer to release resource at function level.
>
> func test() {
>   a := A.Open()
>   defer a.Close()
>   //other code
> }
>
> I need the object a, to be wrapped in a struct. Can someone tell me how to 
> make a.Close() in this case *elegantly ?*
>

Maybe not what you're getting at, but based on your very brief description, 
why not put a "Close" method on the surrounding struct and defer Close on 
the containing struct?

Eric.
 

>
> Warm Regards,
> Asit Dhal
> http://bit.ly/193ASIT
>

-- 
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 https://groups.google.com/d/optout.

[go-nuts] Anyone aware of a CVSS v3 parser & score computation library?

['Eric Johnson' via golang-nuts]

go-search.org and Google just found CVSS v2 implementations.

Anyone have any tips?

Eric.

-- 
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 https://groups.google.com/d/optout.

Re: [go-nuts] Re: [ANN] UniDoc PDF Toolkit for golang

['Eric Johnson' via golang-nuts]

On Monday, July 18, 2016 at 4:45:37 AM UTC-7, rog wrote:
>
> On 16 July 2016 at 16:33, Daniel Theophanes  > wrote: 
> > I would also note that AGPL is probably unusable in most Go programs 
> > (statically linked and all). -Daniel 
>
> Why so? You just need to make your program open source, which shouldn't 
> be too onerous a requirement I'd've thought. 
>
 
IANAL, but the viral nature of the AGPL might be an issue.

Just to be clear, I understand your business proposition, and if it works 
for you to use the AGPL, then you should do that. I'm just addressing the 
question of how the use of the license plays out.

Any project that builds upon your project is effectively also under the 
AGPL, whether or not they want to provide their extensions under a 
different open source license. In fact, allowing downstream developers to 
use a different license than AGPL is just asking for trouble.

The exceptions you've provided for open source use probably make perfect 
sense to a lawyer, but to a developer downstream of this, it is one more 
thing that they have to keep track of. Imagine a poor user who does a "go 
get" of a library built upon your library, and they vendor it into their 
source tree. They might not notice that the go get operation pulled down a 
dependency that is licensed differently from the dependency that they were 
fetching. If you're lucky, the dependent library will include a license 
file that explicitly declares the dependency. If your unlucky, developers 
who are not lawyers won't notice the constraint, and it will end up causing 
people headache, just because it deviates from the community norm of a BSD 
or Apache style license.

I don't know that there's an easy way to solve this, because the chosen 
license fits a known open source business model.

Eric.

-- 
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 https://groups.google.com/d/optout.