Re: [go-nuts] Re: ANN: gijit, a Go interpreter

[Christopher Sebastian]

Thanks for the great explanation, Jason.  It really helps me to understand
the high-level-view much better.  :)

~Christopher

-- 
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: Why is there no standard `uuid` package?

[Henry]

@axel: The specification for UUID is defined in RFC 4122. You are free to use 
it or create your own variants. However, the specs is there. 

-- 
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: Why is there no standard `uuid` package?

['Axel Wagner' via golang-nuts]

On Fri, Feb 9, 2018 at 6:24 AM, Henry  wrote:

> I don't think UUID representation (whether with dash or without dash or
> how many dashes) is a strong argument for not including UUID into Go's
> stdlib.
>

Then how about the bigger problem: Semantics. There are tradeoffs of
throughput, latency, collision-resistance, time-sortability, density… and
what the correct tradeoff is depends heavily on the workload.

All of these qualify as "UUIDs" that might or might not be useful depending
on the workload:
* Centralized counter
* Combination of Node-ID and current time
* Combination of Node-ID and random number
* Combination of Node-ID, random number and current-time
* Random Number

In some workloads, time-sortable dense UUIDs are a good thing (e.g.
log-entries, where you will ~always read and write continuous ranges), in
some they are a bad thing (e.g. event-traces, where you will mostly read
and write random single entries and avoid hotspotting). Some workloads can
deal with a small probability of global collisions, as long as locally the
ids are sufficiently unique, some can't. Some workloads will have access to
the current time/system properties like a MAC/a central server, some won't…

The proliferation of UUID Go-packages should show you, that there are a
variety of different semantics that people want supported - settling on a
single one will be next to impossible.


> You can expose it in byte array, provide the default implementation for
> its string representation, and let the users work with the byte array if
> they need a custom string representation. By the way, the RFC did define
> the standard UUID string representation which is in the form of 8-4-4-4-12
> (--Mxxx-Nxxx-) that you can use as the default
> UUID string representation.
>
> That being said. It is also fairly trivial to implement your own UUID
> library. It takes a bit of reading to ensure your implementation conforms
> to the RFC. I know because I ended up implementing my own UUID library
> because there weren't such libraries back then.
>
> --
> 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 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: ANN: gijit, a Go interpreter

[Jason E. Aten]

On Friday, February 9, 2018 at 12:48:17 PM UTC+7, Christopher Sebastian 
wrote:
>
> gijit looks really interesting.  Do you have a high-level 
> description/diagram anywhere that gives an overview of how the system 
> works? [0]
>
> I took a brief look at the git repo, and it seems like you're translating 
> Go into Javascript, and then to Lua, and then using LuaJIT. [1] Is that 
> right?  [2] How do you manage the complexity of these seemingly-unwieldy 
> pieces and translation layers?
>
> It seems like you have your own 'parser' implementation (maybe copied from 
> the Go src tree? [3]).  How will you keep your parser (as well as the rest 
> of the system) up-to-date as Go changes?  [4] Is it a very manual process? 
> [5]
>

> Thanks for working on this important project!
> ~Christopher Sebastian
>

Thank you for the compliment and questions, Christopher.

0. No, at least, not yet.  The README is fairly extensive however. I would 
start by reading it
in full. The open (and closed) issues on github also provide
a sense of the work done to date, and that still TODO.

Perhaps the answer to [1] just below will help illustrate.

1. No, that's not quite right. Let me clarify:

a) GopherJS does:  Go source  ->  Javascript source.  

It translates a whole program at a time.

while

b) `gijit` does: 

 i) Go source -> Lua source.  

But in small chunks; for example, line-by-line.

Instead of whole program, each sequentially entered 
expression/statement/declaration, 
(or using :source, a larger fragment if required for mutually recursive 
definitions)
is translated and evaluated. These can be multiple lines, but as soon as the
gc syntax front-end tells us we have a complete expressions, we translate
and evaluate it.

Yes, the semantics will be subtly different. If you've used R/python/matlab
to develop your algorithms before translating them to a compiled language 
(a highly effective practice that I recommend, and one that motivated 
gijit's development), 
you'll know that this is of little concern.

ii) Then run that Lua source on LuaJIT.

So while the front end of gijit is derived from GopherJS, there is no 
javascript source generated.

There's still quite a bit of javascript remnants in the source, however, as 
many corner
cases haven't been tackled, so that might have misled a cursory inspection. 

I have adopted the practice, in the gopherJS derived code, of leaving in 
the 
javascript generation until I hit the problem with a new test. This lets me 
visually see, and experience when run, where I haven't handled a case yet.
There are many corner cases not yet handled.


2. Very carefully, with full Test-driven development. :) 

Seriously though, TDD is fantastic (if not essential) for compiler work.

I would add, I'm working with extremely mature building blocks.
So if there's a bug, it is almost surely in my code, not the libraries I'm 
using.

The three mains libraries are already themselves the highly
polished result of very high-quality (German and Swiss!) engineering.  

a) Mike Pall's LuaJIT is the work of 12 years by a brilliant designer and 
engineer.
Cloud Flare is now sponsoring King's College London to continue its 
development.

b) Richard Musiol's GopherJS is the work of some 5 years. It passes most of 
the Go standard library tests.

c) I don't know how long it took Robert Griesemer and
the Go team to write the Go front end parser and type 
checker, but there is a ton of time and effort and testing there. 

And a significant 4th:

d) Luar (for Go <-> Lua binary object exchange, so that binary imports of 
Go libraries work) is a mature library. 
A great deal of work was done on it by Steve Donovan and contributors.

This is all work that doesn't need to be reinvented, and can be leveraged. 

The slight changes to the above (vendored and modified) libraries in order 
work at the REPL are light relaxations of a small set of top-level checks.

3. I re-use the front-end syntax/parser from the gc compiler only in order 
to quickly determine if we have a complete
expression at the repl, or if we need to ask for another line of input.  

Then I throw away that parse and use the standard library's go/ast, 
go/parser, go/types to do the full parse and type-checking.

This is necessary because go/parser and go/types are what GopherJS is built 
around.

4. Go 1 is very mature, and changes very slowly, if at all, anymore, 
between releases.

5. Yes, it is manual. I note the changes to the parser and typechecker are 
important but quite small, and would rebase easily.

Best wishes,
Jason

-- 
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: ANN: gijit, a Go interpreter

[Christopher Sebastian]

gijit looks really interesting.  Do you have a high-level 
description/diagram anywhere that gives an overview of how the system works?

I took a brief look at the git repo, and it seems like you're translating 
Go into Javascript, and then to Lua, and then using LuaJIT.  Is that 
right?  How do you manage the complexity of these seemingly-unwieldy pieces 
and translation layers?

It seems like you have your own 'parser' implementation (maybe copied from 
the Go src tree?).  How will you keep your parser (as well as the rest of 
the system) up-to-date as Go changes?  Is it a very manual process?

Thanks for working on this important project!
~Christopher Sebastian

-- 
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: Why is there no standard `uuid` package?

[高橋誠二]

It's very reasonable, and as an actual decision, we fork that lib.
I understood that a stability of library is not so problem.

However, as Henry says, default UUID specification is defined on RFC.
Implementing it is useful, isn't it?


2018年2月9日金曜日 12時28分16秒 UTC+9 Dave Cheney:
>
> Your argument that the stdlib grows a uuid package is really a call for 
> stability. “3rd parties cannot provide us the stability we need, so the go 
> team must”. I don’t think that is a fair expectation on the go team, 
> especially as there is no clear standard for what a uuid is (having 
> multiple inplemebtations pushes the discussion into the domain of the 
> python standard library). 
>
> I think your problems would be best solved by forking the uuid library at 
> a revision that works for you, or sponsoring the development of a 
> sufficiently stable uuid library. There is clearly a market for one. 

-- 
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: Why is there no standard `uuid` package?

[Henry]

I don't think UUID representation (whether with dash or without dash or how 
many dashes) is a strong argument for not including UUID into Go's stdlib. 
You can expose it in byte array, provide the default implementation for its 
string representation, and let the users work with the byte array if they 
need a custom string representation. By the way, the RFC did define the 
standard UUID string representation which is in the form of 8-4-4-4-12 
(--Mxxx-Nxxx-) that you can use as the default UUID 
string representation.

That being said. It is also fairly trivial to implement your own UUID 
library. It takes a bit of reading to ensure your implementation conforms 
to the RFC. I know because I ended up implementing my own UUID library 
because there weren't such libraries back then. 

-- 
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: Why is there no standard `uuid` package?

[Dave Cheney]

Your argument that the stdlib grows a uuid package is really a call for 
stability. “3rd parties cannot provide us the stability we need, so the go team 
must”. I don’t think that is a fair expectation on the go team, especially as 
there is no clear standard for what a uuid is (having multiple inplemebtations 
pushes the discussion into the domain of the python standard library). 

I think your problems would be best solved by forking the uuid library at a 
revision that works for you, or sponsoring the development of a sufficiently 
stable uuid library. There is clearly a market for one. 

-- 
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: Why is there no standard `uuid` package?

[高橋誠二]

Thanks you for the opinion.
My colleagues are using satori/go.uuid, with web framework, "goa".
API breaking change broke that package and our team had trouble for 
versioning.
https://github.com/satori/go.uuid/issues/66

I know it is not the problem of the code of uuid generation itself,
but my friends in other companies also had the same problem,
or they create an original generator.
it is just the reinventing the wheel so I asked why go has no standard uuid 
package.

it's sure that defining the default format, but except for large-scaled 
system,
generally you can be satisfied with a plain "securerandom" string, can't 
you?

2018年2月9日金曜日 11時10分52秒 UTC+9 Dave Cheney:
>
> But that’s the problem, who’s default uuid format is chosen? And how to 
> justify this over the other users who want their default to be chosen. 
>
> The answer is as it currently stands, multiple uuid libraries exist 
> outside the standard library. 
>
> Can you tell me, in concrete terms, what are the benefits to you of a (I’m 
> going to assume the one that is compatible with your project) uuid 
> implementation being included in the standard library. 

-- 
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: Why is there no standard `uuid` package?

[Dave Cheney]

But that’s the problem, who’s default uuid format is chosen? And how to justify 
this over the other users who want their default to be chosen. 

The answer is as it currently stands, multiple uuid libraries exist outside the 
standard library. 

Can you tell me, in concrete terms, what are the benefits to you of a (I’m 
going to assume the one that is compatible with your project) uuid 
implementation being included in the standard library. 

-- 
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: Blocking reflect.Value{}.Call()

[snadrus]

A partial answer is banning reflect in a callstack, but that's 
heavy-handed. I could traverse up to a "safesql.ReflectOk on the stack

On Wednesday, February 7, 2018 at 2:54:13 PM UTC-8, Andy Jackson wrote:
>
> I realize that private functions of another package are not reachable by 
> reflection, but I'm looking for a way to ensure a public 
> interface-or-struct's function can be fully back-traced statically. 
>
> An interface function like 
> Query(sql string, args ...interface{}) Result  
> is an SQL injection risk if it can be called via reflection. This includes 
> the sqlx library simply being part of a program.
>
> My goal: to enhance SafeSQL to fully backtrace and know certainly that 
> there are no SQL injection risks.
>
> Alternative: I can add a comment to the functions I write:
> // Reflection Calls Disallowed
>
> But compiler assurance of this would be nice.
>

-- 
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: Why is there no standard `uuid` package?

[高橋誠二]

I agree UUID is vague but supplying "default" UUID generator on the 
standard package is significant.
If you'd like to use advanced ID generator, like snowflake, you can use 
that package.
The problem is there is no stable and de facto standard package of it.

2018年2月9日金曜日 3時17分38秒 UTC+9 Tamás Gulácsi:
>
> Because UUID is both vague (what format should it be stored? With- or 
> without dashes? Where to split?) and over-engineered (host's mac address in 
> the UUID? or use the full-random v4 ?).
> For example I use github.com/oklog/ulid - shorter and time-sortable 
> alternative.

-- 
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] [Question] database/sql

[Sam Whited]

On Thu, Feb 8, 2018, at 07:28, Mandolyte wrote:
> I'd like to use the same program against multiple databases and set the 
> driver by configuration. But since the driver is in the source code, I 
> don't see a way to do that.
> 
> In other words, I don't want to include this in my code:
> 
> > import (
> > _ "github.com/lib/pq"
> > )
> 
> 
> I want to load it at run time. Is this possible?

If you are accessing your datastore through a common interface instead of 
making SQL queries directly, you could have each separate database you want to 
support be a different plugin (https://godoc.org/plugin)  that implements your 
datastore abstraction and load the correct plugin at runtime.

It hardly seems worth the complexity or maintainability cost though.

—Sam

-- 
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] [Question] database/sql

[Tamás Gulácsi]

Though database/sql supports several drivers, the databases and their SQL 
dialects are quite different!

-- 
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: Why is there no standard `uuid` package?

[Sotirios Mantziaris]

i agree that there should be a std package version of uuid like in almost 
every other language.

On Thursday, February 8, 2018 at 3:43:08 AM UTC+2, 高橋誠二 wrote:
>
> Recently satori/go.uuid took a breaking change of API, and some of 
> frameworks which depend on the package.
> And google/uuid is unstable.
>
> Why Go doesn't have an official uuid package?
> Is there any load map to develop google/uuid and merge it to Go itself?
>
>

-- 
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] Why is there no standard `uuid` package?

[Tamás Gulácsi]

Because UUID is both vague (what format should it be stored? With- or without 
dashes? Where to split?) and over-engineered (host's mac address in the UUID? 
or use the full-random v4 ?).
For example I use github.com/oklog/ulid - shorter and time-sortable alternative.

-- 
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: Inheritance and OOP: Go one better

[matthewjuran]

Closures and function types/fields may have a place in discussing OOP-like 
Go constructs.

Matt

On Thursday, February 8, 2018 at 10:47:04 AM UTC-6, Stefan Nilsson wrote:
>
> Here is a short article about how to do OOP in Go with composition, 
> structurally typed interfaces and, in some special cases, embedding. I 
> believe this can often be a better approach than traditional OOP modeling 
> using inheritance. I'd love to hear you thoughts.
>
> Inheritance and OOP: Go one better 
> 
>

-- 
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] Let's collect options to add to the whitelist in #23749

[Ian Lance Taylor]

There have been several different reports of options missing from the
whitelist of cgo options that was just added to the go tool.  I
propose that we collect them all in https://golang.org/issue/23749 and
then write a single CL that adds all the appropriate ones.  That will
give us an easy backport to 1.9 and 1.8 if we think that is desirable.
In particular, let's avoid having a collection of several different
CLs to adjust the whitelist.

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] Inheritance and OOP: Go one better

[Stefan Nilsson]

Here is a short article about how to do OOP in Go with composition, 
structurally typed interfaces and, in some special cases, embedding. I 
believe this can often be a better approach than traditional OOP modeling 
using inheritance. I'd love to hear you thoughts.

Inheritance and OOP: Go one better 


-- 
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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Josh Humphries]

On Thu, Feb 8, 2018 at 12:17 AM, Rob Pike  wrote:

> Isn't the visitor pattern just a way to implement type switch in languages
> that don't implement type switch?
>
> That's certainly how I saw it when using C++. Go has a type switch, and so
> has no need for the visitor pattern, a perfect example of the principle
> that a design pattern is just a way to work around shortcomings in the
> language.
>

That is likely the origin of the visitor pattern, but that is not its only
use. JVM languages can switch on type, yet visitors are still prevalent in
several libraries there. The value above-and-beyond a type switch only
applies to OO languages (i.e. class-based inheritance):
re-using/specializing code by sub-classing a visitor implementation and
only overriding/decorating subset of methods.

Also, visitor patterns are sometimes used to abstract away the mechanics of
the tree traversal, too (such as in the "go/ast" package's Walk function).

And they can provide API symmetry for code that both consumes and produces
a data structure. So you implement the visitor to consume; you accept a
visitor and invoke its methods to produce. (For example, the ASM
 library for Java.)


>
> -rob
>
>
> On Thu, Feb 8, 2018 at 2:14 PM, Josh Humphries 
> wrote:
>
>> FWIW, it looks like someone else has gone through this exercise:
>> https://github.com/tmrts/go-patterns
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com
>>
>> On Fri, Feb 2, 2018 at 12:03 PM,  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
>>>
>>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>>
>>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>>
>>> 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.
>>>
>>> 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.
>>>
>>
>> --
>> 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 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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[matthewjuran]

I read that one of the Gang of Four has sadly died recently. To me their 
book seems to be part of American technology history and tradition and I’m 
glad to have a copy somewhere.

And, for structs that need stronger encapsulation (private fields, enforce 
> invariants at construction time), Go has its own pattern: the functional 
> option pattern.


I’m not sure how that’s related to encapsulation, but this options problem 
is appearing in the standard library because of cancellation via a context 
var. In the Go 2 proposals I’ve been suggesting another pattern where a 
struct type contains shared pointers and read-only values, is called by 
value instead of by pointer by methods, and has fields that are set in the 
value copies for optional behavior.

I haven’t recognized the functional option pattern before (my takeaway is 
“make use of … in API design”) and I’ll keep it in mind. Maybe it’s a good 
solution to this context problem.

Isn't the visitor pattern just a way to implement type switch in languages 
> that don't implement type switch?


The visitor does double dispatch where the behavior of each type can be 
swapped out. Maybe a type switch into a type switch would be equivalent.

This might be of interest for you: "Evaluating the Go Programming Language 
> with Design Patterns".


I’m seeing overuse of interface, but I’ll read this paper in more detail.

The Wikipedia article on Anti-patterns is interesting: 
https://en.wikipedia.org/wiki/Anti-pattern. I learned what “bike shedding” 
means, and I think that pattern would be better described as “working on 
the bike shed”.

Thanks,
Matt

On Thursday, February 8, 2018 at 9:22:23 AM UTC-6, Joshua Humphries wrote:
>
> On Wed, Feb 7, 2018 at 5:45 PM, roger peppe  > wrote:
>
>> As someone totally unfamiliar with the GoF patterns, hre's my take.
>> I looked at the wikipedia articles and tried to work out what
>> problem I thought the pattern was trying to address and then
>> wrote some Go code to do that. I'm generally in agreement
>> with those who say that these patterns are there largely to avoid
>> the pitfalls of languages with class-based inheritance.
>>
>
> Some are targeted specifically at C++/Java -- not due to class-based 
> inheritance but to language/syntax limitations. For example the builder 
> pattern is meant to make construction of objects more readable than 
> overloaded constructors/factories with telescoping argument lists. Go has 
> less need for this because of its struct literal syntax. And, for structs 
> that need stronger encapsulation (private fields, enforce invariants at 
> construction time), Go has its own pattern: the functional option pattern 
> .
>
> They certainly aren't all there to avoid pitfalls of class-based 
> inheritance. Many are intuitive solutions to certain classes of problems: 
> one could easily write code that adheres to one of these patterns without 
> even realizing it (adapters, facades, decorators, interceptors, commands, 
> strategies, flyweights, iterators, observers, DSLs). Admittedly, some are 
> less powerful/expressive without class-based inheritance, so less 
> applicable to Go. But, as alluded to in the previous paragraph, Go has some 
> of its own patterns.
>
>
>> abstract factory https://play.golang.org/p/syHr7QJ9e2q
>> - anything in Go that returns an interface rather than a concrete type
>> could be considered an abstract factory.
>>
>
> This isn't quite right. Your example is just a parameterized factory 
> method. This pattern is about the factory itself being abstract. Here's a 
> re-worked example: https://play.golang.org/p/joSYzhMeS0n
> This pattern is a specialization of the strategy 
>  pattern.
>  
>
>>
>> facade https://play.golang.org/p/U6DSg5pDC0w
>> - any type that has another type as a member and not much
>> significant logic in its own methods could be considered a facade.
>>
>
> And if that facade implements a particular interface then it is also an 
> example of the adapter  
> pattern. More adapter examples: bytes.NewReader() and strings.NewReader(). 
> They adapt []byte or string to the io.Reader interface.
>  
>
>>
>> proxy https://golang.org/pkg/bufio/#NewReader
>> - any Go function that takes an interface and returns a
>> value that implements the same interface could be considered
>> a proxy.
>>
>
> This describes the decorator pattern more than the proxy pattern. Usually, 
> a proxy isn't just a wrapper (like a decorator is) -- the proxy object is 
> some form of stand-in for some other resource, typically remote. RPC is a 
> much better example of the proxy pattern (like the "net/rpc" package, but 
> also things like gRPC). Sometimes proxies also add functionality (like the 
> decorator pattern), translate protocols (a la the adapter pattern), or 
> perform 

Re: [go-nuts] ANN: gijit, a Go interpreter

[Ali Nabavi]

Thanks! 

On Wed, Feb 7, 2018, 2:00 PM Jason E. Aten  wrote:

> https://github.com/gijit/gi
>
> My interactive Go REPL, gijit, is quite useful now. It has structs,
> pointers, defer, and interfaces implemented.  You can call into native Go
> packages.
>
> Enjoy,
>
> Jason
>
> --
> 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 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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Josh Humphries]

On Wed, Feb 7, 2018 at 5:45 PM, roger peppe  wrote:

> As someone totally unfamiliar with the GoF patterns, hre's my take.
> I looked at the wikipedia articles and tried to work out what
> problem I thought the pattern was trying to address and then
> wrote some Go code to do that. I'm generally in agreement
> with those who say that these patterns are there largely to avoid
> the pitfalls of languages with class-based inheritance.
>

Some are targeted specifically at C++/Java -- not due to class-based
inheritance but to language/syntax limitations. For example the builder
pattern is meant to make construction of objects more readable than
overloaded constructors/factories with telescoping argument lists. Go has
less need for this because of its struct literal syntax. And, for structs
that need stronger encapsulation (private fields, enforce invariants at
construction time), Go has its own pattern: the functional option pattern
.

They certainly aren't all there to avoid pitfalls of class-based
inheritance. Many are intuitive solutions to certain classes of problems:
one could easily write code that adheres to one of these patterns without
even realizing it (adapters, facades, decorators, interceptors, commands,
strategies, flyweights, iterators, observers, DSLs). Admittedly, some are
less powerful/expressive without class-based inheritance, so less
applicable to Go. But, as alluded to in the previous paragraph, Go has some
of its own patterns.


> abstract factory https://play.golang.org/p/syHr7QJ9e2q
> - anything in Go that returns an interface rather than a concrete type
> could be considered an abstract factory.
>

This isn't quite right. Your example is just a parameterized factory
method. This pattern is about the factory itself being abstract. Here's a
re-worked example: https://play.golang.org/p/joSYzhMeS0n
This pattern is a specialization of the strategy
 pattern.


>
> facade https://play.golang.org/p/U6DSg5pDC0w
> - any type that has another type as a member and not much
> significant logic in its own methods could be considered a facade.
>

And if that facade implements a particular interface then it is also an
example of the adapter 
pattern. More adapter examples: bytes.NewReader() and strings.NewReader().
They adapt []byte or string to the io.Reader interface.


>
> proxy https://golang.org/pkg/bufio/#NewReader
> - any Go function that takes an interface and returns a
> value that implements the same interface could be considered
> a proxy.
>

This describes the decorator pattern more than the proxy pattern. Usually,
a proxy isn't just a wrapper (like a decorator is) -- the proxy object is
some form of stand-in for some other resource, typically remote. RPC is a
much better example of the proxy pattern (like the "net/rpc" package, but
also things like gRPC). Sometimes proxies also add functionality (like the
decorator pattern), translate protocols (a la the adapter pattern), or
perform routing/multiplexing/demultiplexing.

Another related pattern is the interceptor pattern (aka
chain-of-responsibility
).


>
> factory method: https://play.golang.org/p/AmQ7lQHAPDy
> - any function or method that creates and returns an object could
> be considered a factory. Go doesn't have constructors so this
> is just normal.
>
>
This statement describes "factory method", but is not at all what the
factory method pattern is about. This pattern is specific to class-based
inheritance. The idea is to create a virtual/abstract factory method that
sub-classes override to return different sub-types/implementations.

Since Go does not have class-based inheritance, the closest I could
envision is "override" behavior via a function field. Here's a take on it
based on the example in the wikipedia page
:
https://play.golang.org/p/EnZ4sRFdmyT



> visitor: https://play.golang.org/p/w74EhhuAhT5
> - I'm not sure that this is a great pattern. Doing a callback for every
> object in a hierarchy seems fine, but requiring a different method
> to be implemented for each kind of object seems unnecessary - if
> you add another kind of object, then all the code using the visitor
> will break (but that could also be considered an advantage, I guess,
> as it means your clients are forced to consider all possible kinds).
>

This one also is more suited to class-based inheritance as there is usually
a base class implementation that has a no-op implementation for all
callbacks. That way, the code implementing the visitor is not broken
whenever a new method is added to the visitor. (In Go, you could embed a
no-op visitor, so that you only need to implement the subset of applicable
methods.) For what it's worth, adding other kinds of 

[go-nuts] Re: ANN: gijit, a Go interpreter

[Zellyn]

Very nice. You might be interested in this Group 
too: https://groups.google.com/forum/#!forum/go-interpreter

On Wednesday, February 7, 2018 at 3:00:06 PM UTC-5, Jason E. Aten wrote:
>
> https://github.com/gijit/gi
>
> My interactive Go REPL, gijit, is quite useful now. It has structs, 
> pointers, defer, and interfaces implemented.  You can call into native Go 
> packages.
>
> Enjoy,
>
> Jason
>

-- 
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] [Question] database/sql

[Mandolyte]

Yeah, makes sense... I was just trying to do something I could do in 
Java... but it's interpreted and isn't creating an executable.

No biggie... just wanted to be sure I wasn't overlooking any tricks. 

Thanks for the quick answer!

On Thursday, February 8, 2018 at 8:39:02 AM UTC-5, Jan Mercl wrote:
>
> On Thu, Feb 8, 2018 at 2:29 PM Mandolyte  
> wrote:
>
> > I want to load it at run time. Is this possible? 
>
> Why? The driver code is already linked into your program, otherwise you 
> would not be able to load it later.
>
> -- 
>
> -j
>

-- 
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] [Question] database/sql

[Shawn Milochik]

You'd just have to compile in all the drivers you want to support. Then use
environment variables to get settings per database.

That's why sql.Open() takes a string as its first argument; so you can tell
it which one (potentially of many) to use.

-- 
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] [Question] database/sql

[Jan Mercl]

On Thu, Feb 8, 2018 at 2:29 PM Mandolyte  wrote:

> I want to load it at run time. Is this possible?

Why? The driver code is already linked into your program, otherwise you
would not be able to load it later.

-- 

-j

-- 
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: Asymmetrical I/O load on single TCP connection

[Everton Marques]

For the archives.

go version go1.10rc2 linux/amd64

The tool uses the same loop code for both sending and receiving data.
Calling runtime.Gosched() in the top of the loop improved the behavior:

2018/02/07 21:26:40 report clientReader rate:   8277 Mbps  51741 calls/s
2018/02/07 21:26:40 report clientWriter rate:   7895 Mbps  49345 calls/s
2018/02/07 21:26:42 report clientReader rate:   8210 Mbps  51322 calls/s
2018/02/07 21:26:42 report clientWriter rate:   7800 Mbps  48753 calls/s
2018/02/07 21:26:44 report clientReader rate:   8347 Mbps  52177 calls/s
2018/02/07 21:26:44 report clientWriter rate:   7734 Mbps  48339 calls/s
2018/02/07 21:26:46 report clientReader rate:   7195 Mbps  44969 calls/s
2018/02/07 21:26:46 report clientWriter rate:   7451 Mbps  46574 calls/s

One can check the workLoop 
here: https://github.com/udhos/goben/blob/master/goben/client.go

Everton


Em quarta-feira, 7 de fevereiro de 2018 17:21:39 UTC-2, Everton Marques 
escreveu:
>
> Hi,
>
> I wrote a simple utility https://github.com/udhos/goben to test TCP 
> throughput between two hosts.
> At each endpoint, the tool spawns two goroutines: one for reading from 
> net.TCPConn as fast as possible, other for writing into it as fast as 
> possible.
> However I'm consistently obtaining uneven rates like these:
>
> 2018/02/06 23:13:47 report clientReader rate:  20089 Mbps 125557 calls/s
> 2018/02/06 23:13:47 report clientWriter rate:417 Mbps   2606 calls/s
> 2018/02/06 23:13:49 report clientReader rate:  18245 Mbps 114039 calls/s
> 2018/02/06 23:13:50 report clientWriter rate:   1295 Mbps   8097 calls/s
> 2018/02/06 23:13:51 report clientReader rate:  19722 Mbps 123263 calls/s
> 2018/02/06 23:13:52 report clientWriter rate:   2179 Mbps  13620 calls/s
> 2018/02/06 23:13:53 report clientReader rate:  15851 Mbps  99077 calls/s
> 2018/02/06 23:13:54 report clientWriter rate:   4274 Mbps  26718 calls/s
>
> Notice the input rate (reader) is way higher than output rate (writer).
>
> For comparison, this is the result from a single-threaded tool written in 
> C (https://github.com/udhos/nepim):
>
>  kbps_in   kbps_outrcv/ssnd/s
>   3 cur 8 8873837.00 8950252.00 47920.50 34142.50
>   3 cur 6 8655077.00 8654946.00 47166.50 33016.00
>   3 cur 4 8773173.00 8772125.00 47800.50 33463.00
>   3 cur 2 8700428.00 8700690.00 47408.50 33190.50
>   3 avg 0 8730680.00 8745727.00 47481.90 33362.30
>   3 min 0 8655077.00 8654946.00 47166.50 33016.00
>   3 max 0 8873837.00 8950252.00 47920.50 34142.50
>
> I guess I'm hitting some goroutine scheduling issue?
>
> How can I improve scheduling fairness (?) in order to get similar loads on 
> both directions?
>
> Thanks,
> Everton
>
>

-- 
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] [Question] database/sql

[Mandolyte]

I'd like to use the same program against multiple databases and set the 
driver by configuration. But since the driver is in the source code, I 
don't see a way to do that.

In other words, I don't want to include this in my code:

> import (
> _ "github.com/lib/pq"
> )


I want to load it at run time. Is this possible?

-- 
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] “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Egon]

In practice it's seen together with two problems:

1. Emulating multiple dispatch with overloading: technically, it doesn't 
really solve the same problem as GoF described, but it looks a lot like it.

Example: https://en.wikipedia.org/wiki/Visitor_pattern#C++_example

2. Navigate a complex structure with callbacks:

Examples:
1. https://en.wikipedia.org/wiki/Visitor_pattern#Dynamic_Visitor
2. https://golang.org/pkg/go/ast/#Walk
3. https://golang.org/pkg/path/filepath/#Walk

When you put these two solutions together, you get the original "Visitor 
Pattern".

--

When the language doesn't support overloading, the implementation is 
usually done such that it doesn't require it. Instead of overloaded 
starting point in the structure, you'll have an specific one.

As a contrived example, you could convert the filepath.Walk into the 
original(ish) "Visitor Pattern" by having multiple callbacks instead of one 
or an interface:

type Handler interface {
HandleError(err error)
HandleFile(path string, info os.FileInfo) error
HandleDir(path string, info os.FileInfo) error
}

*In this case, it would be a worse solution and I wouldn't recommend it. *

--

I would like to rant about the badness of GoF Design Patterns... as Coplien 
said, there are no patterns in GoF book [1] 
. The problem with GoF can easily 
demonstrated by how hard it is to find good real-world examples of the 
patterns and that cannot be eliminated with different language. The best 
Patterns (as described by Alexander) are timeless and guide to a better 
solution and help you solve a problem that technology cannot fix.

[1] Are there any Patterns in GoF? (https://stackoverflow.com/a/24664544)

On Thursday, 8 February 2018 07:17:55 UTC+2, Rob 'Commander' Pike wrote:

> Isn't the visitor pattern just a way to implement type switch in languages 
> that don't implement type switch?
>
That's certainly how I saw it when using C++. Go has a type switch, and so 
> has no need for the visitor pattern, a perfect example of the principle 
> that a design pattern is just a way to work around shortcomings in the 
> language.
>
> -rob
>
>
> On Thu, Feb 8, 2018 at 2:14 PM, Josh Humphries  > wrote:
>
>> FWIW, it looks like someone else has gone through this exercise:
>> https://github.com/tmrts/go-patterns
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com 
>>
>> On Fri, Feb 2, 2018 at 12:03 PM,  
>> 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
>>>
>>> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>>>
>>> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>>>
>>> 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.
>>>
>>> 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...@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...@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: “Design Patterns: Elements of Reusable Object-Oriented Software” in Go

[Volker Dobler]

On Thursday, 8 February 2018 09:01:29 UTC+1, Haddock wrote:
>
>
> This might be of interest for you: "Evaluating the Go Programming 
> Language with Design Patterns 
> ".
>
>
Interesting read. From the paper:

"We found that this was common and that having to use
 different names was inconvenient — there is no naming
 convention for multiple different factory methods, so
 clients wishing to instantiate an object must either guess
 *or check the documentation*." 
[Schmager, Cameron, Nobel, l.c., sec 4.1, page 5, emphasis mine]

It seems checking the documentation is something one should
not be required to do. And I now that lots of developers never
take a look at documentation. But why? What's wrong with
reading a few sentences or skimming a 3 page manual?

V.

-- 
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

[Haddock]

This might be of interest for you: "Evaluating the Go Programming Language 
with Design Patterns ".

Am Freitag, 2. Februar 2018 18:03:54 UTC+1 schrieb matthe...@gmail.com:
>
> 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
>
> Abstract Factory: https://play.golang.org/p/SWwuX49eysd
>
> Factory Method: https://play.golang.org/p/FRgDBx2CLFf
>
> 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.
>
> 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.