[Galene] Heads up: Galene now requires Go 1.16

[Galene] Heads up: Galene now requires Go 1.16

[Juliusz Chroboczek]

I've mistakenly broken compilation of Galene with Go 1.15 back in April,
and nobody seems to have noticed, it looks like everybody has upgraded to
Go 1.16 or later.  (Go 1.16 was released in February 2021, the current
version is 1.18, and 1.19 should be released by the end of the month.)

I've just pushed a commit that makes the dependency on Go 1.16 or later
explicit.  If you're still using Go 1.15, please consider upgrading to
1.18 or 1.19.

-- Juliusz

[Galene] Re: Heads up: Galene now requires Go 1.16

[Dave Taht]

I noticed but upgraded.

btw, what are your feelings about go generics?

On Tue, Jul 12, 2022 at 8:48 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> I've mistakenly broken compilation of Galene with Go 1.15 back in April,
> and nobody seems to have noticed, it looks like everybody has upgraded to
> Go 1.16 or later.  (Go 1.16 was released in February 2021, the current
> version is 1.18, and 1.19 should be released by the end of the month.)
>
> I've just pushed a commit that makes the dependency on Go 1.16 or later
> explicit.  If you're still using Go 1.15, please consider upgrading to
> 1.18 or 1.19.
>
> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[Galene] OT: generics [was: Heads up: Galene now requires Go 1.16]

[Juliusz Chroboczek]

> btw, what are your feelings about go generics?

They are smartly done, unlike C++ generics they don't impose a single
implementation strategy.  They're done in Church style (where
instantiation consists in passing a type parameter), while I tend to
prefer Curry style (where instantiation is modelled as a case of
subtyping).  They don't support specialisation (where the user writes
a specially optimised implementation for the types they really care
about), which might or might not be a limitation.

We'll see if we get any nice libraries.  I'd love to see an implementation
of B-trees with good cache locality that is type-safe and efficient at all
types.

-- Juliusz

[Galene] Re: OT: generics [was: Heads up: Galene now requires Go 1.16]

[Dave Taht]

On Tue, Jul 12, 2022 at 9:18 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > btw, what are your feelings about go generics?
>
> They are smartly done, unlike C++ generics they don't impose a single
> implementation strategy.  They're done in Church style (where
> instantiation consists in passing a type parameter), while I tend to
> prefer Curry style (where instantiation is modelled as a case of
> subtyping).  They don't support specialisation (where the user writes
> a specially optimised implementation for the types they really care
> about), which might or might not be a limitation.

I hope they evolve. This was a very disappointing analysis of go generics:

https://planetscale.com/blog/generics-can-make-your-go-code-slower

However, the rust version of generics is essentially programming the
AST directly and if I really wanted a lisp, I'd have stuck with lisp.
I didn't care for C++ much, but BOOST was a bright light in it.

>
> We'll see if we get any nice libraries.  I'd love to see an implementation
> of B-trees with good cache locality that is type-safe and efficient at all
> types.
>
> -- Juliusz



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[Galene] Re: OT: generics [was: Heads up: Galene now requires Go 1.16]

[Dave Taht]

https://thenewstack.io/shaving-40-off-googles-b-tree-implementation-with-go-generics/
looked pretty exciting.

On Tue, Jul 12, 2022 at 9:45 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> On Tue, Jul 12, 2022 at 9:18 AM Juliusz Chroboczek <jch@irif.fr> wrote:
> >
> > > btw, what are your feelings about go generics?
> >
> > They are smartly done, unlike C++ generics they don't impose a single
> > implementation strategy.  They're done in Church style (where
> > instantiation consists in passing a type parameter), while I tend to
> > prefer Curry style (where instantiation is modelled as a case of
> > subtyping).  They don't support specialisation (where the user writes
> > a specially optimised implementation for the types they really care
> > about), which might or might not be a limitation.
>
> I hope they evolve. This was a very disappointing analysis of go generics:
>
> https://planetscale.com/blog/generics-can-make-your-go-code-slower
>
> However, the rust version of generics is essentially programming the
> AST directly and if I really wanted a lisp, I'd have stuck with lisp.
> I didn't care for C++ much, but BOOST was a bright light in it.
>
> >
> > We'll see if we get any nice libraries.  I'd love to see an implementation
> > of B-trees with good cache locality that is type-safe and efficient at all
> > types.
> >
> > -- Juliusz
>
>
>
> --
> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[Galene] Re: OT: generics [was: Heads up: Galene now requires Go 1.16]

[Juliusz Chroboczek]

> I hope they evolve. This was a very disappointing analysis of go generics:

No big surprise here.  He's saying that Go generics are fast for simple
types (where they are essentially implemented as macros) but not
necessarily faster than interfaces when used with interfaces.  The
alternative would be to have the compiler duplicate generic functions at
all types, as in C++, which has its own issues.

That's exactly as it was in Common Lisp: you'd write generic code as the
initial implementation, then do some profiling and manually specialise
your inner loops.  That's something I can live with.

-- Juliusz