Thanks for the follow up Eric. Your experience with the concurrency
primitives lines up with my experience porting projects from various
languages into Go. The ability to maintain exceptionally low cognitive
overhead when adding concurrency is pretty amazing.
On an unrelated note, if in the fut
This is a belated addition to my notes on the Go translation of
reposurgeon. I'll be adding it to the revised version I post to golang-dev.
One extremely positive thing I must say before closing. Translation from
Python, which is a dreadful language to try to do concurrency in due to its
globa
On Thursday, January 30, 2020 at 2:05:17 AM UTC-5, Liam wrote:
>
> I'd suggest re-posting this on golang-dev; I almost missed it as I rarely
> read -nuts.
>
That's a good idea. I think what I'll do is revise it lightly in view of
some of the feedback I've gotten here and post it there.
--
You
On Sun, Jan 26, 2020 at 9:16 AM Eric Raymond wrote:
> And that's the insight that led be to the extension I proposed. I asked
> myself what the most natural way to pass out a soft close might be.
If you're proposing combining generators and exceptions, be aware of
how complicated the exact seman
On Tue, Feb 4, 2020 at 8:56 PM Jason E. Aten wrote:
> b := helper(i: 2)
>
> would give you the whole new &fArg{x:0, y:0, i:2} back in b.
I'm not sure how helpful that really is, given that you can already write:
b := &fArg{i: 2}
--
You received this message because you are subscribed to the
Here's an idea for named arguments. Given:
type fArg struct {
x float64
y float64
i int
}
func f(a fArg) {
...
}
func f2(a *fArg) {
...
}
## Then, consider call example 1:
f(x:1.9, i:2)
-> this would be translated into an implicit struct creation either value
or value plus a poi
On Monday, 3 February 2020 23:10:01 UTC, Jon Conradt wrote:
>
> While names arguments like foo(x= 1.0, y = 23) may look like syntactic
> sugar, I think you are right that they improve readability, especially of
> long argument lists. The counter argument I suppose if that you could pass
> struct
While names arguments like foo(x= 1.0, y = 23) may look like syntactic
sugar, I think you are right that they improve readability, especially of
long argument lists. The counter argument I suppose if that you could pass
structs around, but that gets ugly fast.
Thinking about how this would be
On Saturday, 25 January 2020 22:16:26 UTC, Eric Raymond wrote:
>
>
> And that's the insight that led be to the extension I proposed. I asked
> myself what the most natural way to pass out a soft close might be.
>
>
Suppose we continue with the idea of an iterator being a goroutine which
stuffs
I miss named function arguments too.
The closest replacement I've discovered in Go is pass a struct literal, or
pointer to such, which can then document or leave out arguments as desired.
e.g.
type temperature struct {
fahrenheit float64
celciusfloat64
}
// define
func set(t temparatur
I miss named function arguments too.
The closest replacement I've discovered in Go is pass a struct literal, or
pointer to such, which can then document or leave out arguments as desired.
e.g.
type temperature struct {
fahrenheit float64
celciusfloat64
}
func set(temperature{celcius: 3
That was a great read, thank you.
Re throw/catch, this is one of the few Go2 error handling proposals still
open, tho it hasn't yet seen substantive feedback from the Go team:
https://github.com/golang/go/issues/27519
I'd suggest re-posting this on golang-dev; I almost missed it as I rarely
rea
On Mon, Jan 27, 2020 at 3:23 PM Eric Raymond wrote:
> Consider a parser in which your handler function for a given token or subtree
> consists of a bunch of if/then returns, and not matching one of them means
> you should throw upwards to an error handler.
FWIW,
https://github.com/google/wuff
On Monday, January 27, 2020 at 9:51:43 AM UTC-5, Philip Boampong wrote:
>
> I assumed the ugliness is about the recover logic being exposed in the
> catch signature and in the handler function. If you change catch to
> take the exception handler as a callback you can hide the recover
> logic w
> > log.Fatal and os.Exit have the same problem. They are not "terminating
> > statements", so if you want them at the bottom of a function with result
> > parameters you have to add a panic("unreachable").
>
> Excellent point. But contemplating being able to declare library functions
> termina
On Monday, January 27, 2020 at 11:18:50 AM UTC+1, Manlio Perillo wrote:
> [...]
>
> What about introducing a support type. As an example (not tested)
> https://play.golang.org/p/WkHyEI52xKu
>
>
Here is an updated version of the Pipeline type, with error handling:
https://play.golang.org/p/Qs6_fI
On Saturday, January 25, 2020 at 9:46:19 AM UTC+1, Eric Raymond wrote:
> [...]
> An early reviewer pointed out that if the Go code were an entire
> function it could be expressed something like this:
>
> ---
>
> func pipeline(source T)
On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote:
>
> log.Fatal and os.Exit have the same problem. They are not "terminating
> statements", so if you want them at the bottom of a function with result
> parameters you have to add a panic("unreachable").
>
Excellent poin
On Sunday, January 26, 2020 at 9:06:47 PM UTC-5, Robert Engels wrote:
>
> I think trying to write Python in Go is problematic.
>
Of course it is. If I were starting a Go program from scratch I certainly
wouldn't try to code as though the language were Python.
The real burden of my experience
I think trying to write Python in Go is problematic. You say you intentional
did and didn’t worry about “improving” the code. Using interfaces and Go design
patterns is not improving - it’s writing proper Go imo.
> On Jan 26, 2020, at 6:14 PM, pboampo...@gmail.com wrote:
>
>
> > === Catchab
> === Catchable exceptions require silly contortions ===
I think the community is aware of the problem but still trying to find a
more Go-like solution. Take a look at some of the proposals if you haven't:
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md
https://gi
I spotted a typo:
On Saturday, January 25, 2020 at 3:46:19 AM UTC-5, Eric Raymond wrote:
>
> The Go translation of reposurgeon is better - more maintainable - code
> than the Python original, not just faster. And this is because I
> rewrote or refactored as I went; as I've explained, I tried very
Really interesting post, thank you.
On iterators without leaking goroutines, have a look at the standard library's
bufio.Scanner and database/sql.Rows. These provide easy iteration over
arbitrary sequences in a compact idiomatic form.
--
You received this message because you are subscribed to
On Saturday, January 25, 2020 at 5:43:24 AM UTC-5, Brian Candler wrote:
>
> 1. When the issue of keyword arguments has come up before, usually someone
> suggests passing a struct as the function argument. Did you try this? It
> might be worth mentioning in your analysis, if only to give an ex
On Saturday, January 25, 2020 at 10:04:19 AM UTC-5, Robert Engels wrote:
>
> Whenever I see a type switch it screams to me “use an interface and
> restructure. “
>
You may be right. On the other hand, I think I've already gone far enough
down the interface road to have collected most of the ga
Very in-depth and interesting.
Although I agree with most of the points, I think a better use of interfaces
would address some of your concerns, and have more maintainable code.
Whenever I see a type switch it screams to me “use an interface and
restructure. “
>> On Jan 25, 2020, at 4:43 AM
Very insightful.
I am relatively new to go, but I would like to make a few observations.
1. When the issue of keyword arguments has come up before, usually someone
suggests passing a struct as the function argument. Did you try this? It
might be worth mentioning in your analysis, if only to g
27 matches
Mail list logo
