+1
On Monday, February 19, 2018 at 12:37:14 PM UTC-5, Michael Jones wrote:
>
> Matthew Juran wrote: *"...but if you use maps, slices, append, make, you
> are already using generics."*
>
> This seems deeply insightful to me. Perhaps a better question than the
> self-defeatingly open question of "
On Mon, Feb 19, 2018 at 9:29 PM Rob Pike wrote:
> Jesper,
>
> I find myself in rare but mild disagreement about your claims for
> stack-based virtual machines. Please have a look at this short paper about
> the Dis VM from Inferno: http://flint.cs.yale.edu/jvmsem/doc/inferno.ps
>
>
There is a cha
Jesper,
I find myself in rare but mild disagreement about your claims for
stack-based virtual machines. Please have a look at this short paper about
the Dis VM from Inferno: http://flint.cs.yale.edu/jvmsem/doc/inferno.ps
We found a JIT for Dis could be tiny, especially compared to Java JITs, and
On 19 February 2018 at 17:36, Michael Jones wrote:
> Matthew Juran wrote: "...but if you use maps, slices, append, make, you are
> already using generics."
>
> This seems deeply insightful to me. Perhaps a better question than the
> self-defeatingly open question of "how should Go embrace generics
Matthew Juran wrote: *"...but if you use maps, slices, append, make, you
are already using generics."*
This seems deeply insightful to me. Perhaps a better question than the
self-defeatingly open question of "how should Go embrace generics?" would
be "what change would allow maps, slices, append,
>
> I would probably never use it, like many people who comes to Go from C.
But if you use maps, slices, append, make, you are already using generics.
Maybe this is unfounded, but I'm far from convinced that generics would
> make my experience of Go better. I'm really thinking here of, are we
I disagree that generics would decrease readability at the call site.
Perhaps within the library where it is used but maybe not even there. The
only complexity is within the compiler and other internals. This is not
irrelevant by far but the carte blanche "generics is bad" is most often
hyperbole.
On Sun, Feb 18, 2018 at 4:47 AM Lars Seipel wrote:
>
> Go already has a NaCl backend which might fit the bill. See
> misc/nacl/README for how to set it up. It links to a design document
> (https://golang.org/s/go13nacl) with some background.
>
>
The sucessor of that project is WebAssembly.
WebAs
Lars,
That's nice! Yet it's a sandboxed execution context. The Safe Packages
mentioned above are just Go packages, with source code.
And when the day comes for a proper dependency manager, I would like to be
able to tell the DM fail on import any unsafe packages - except for a list
that I trus
On Sat, Feb 17, 2018 at 01:10:29AM -0800, dc0d wrote:
> There are other things too, that I would like to have in Go; like a faster
> FFI/CGO, or safe packages by restricting features so that a Go package
> cannot harm the hosting machine or application, like Safe Tcl
Go already has a NaCl backe
10 matches
Mail list logo
