I would add that Go strives to be a language that is easy to understand.
Any instance where you have to
a) read the spec or be intimately familiar with the language and
b) reason out the behavior instead of understanding it at a glance
is a case where that goal has failed. Of course, there
On Mon, Apr 10, 2023 at 7:23 PM xi ool wrote:
> Little late but I have to say the rational seems foolish :
>
>
>1. Currently 25% of gophers who didn't read the language spec
>experienced a 'bug' and got unexpected behavior..
>
> This premise is a bit suspect.
The current loop-variable be
Little late but I have to say the rational seems foolish :
1. Currently 25% of gophers who didn't read the language spec
experienced a 'bug' and got unexpected behavior..
2. Solution is to change the language spec and behavior (despite
breaking go back compat promise)
3. ...
Not sure if you haven't tried them yet, but here:
- https://github.com/tetratelabs/wazero
- https://github.com/knqyf263/go-plugin
- https://github.com/tetratelabs/wazero
- https://github.com/ebitengine/purego
I need some IPC too for a experiment, and was going to try them.
On Sun, Apr 9, 2023
Thanks
在2023年4月5日星期三 UTC+8 03:38:21 写道：
> On Tue, Apr 4, 2023 at 12:05 PM fliter wrote:
> >
> > There are many private methods with identical code in several different
> packages, which is clearly not elegant; But adding a public method that can
> be accessed by other packages (a proposal need
Thanks
在2023年4月5日星期三 UTC+8 03:32:02 写道：
> If you're trying to share code among related packages within a module but
> not external to the module, "internal" packages[1][2] are one common way to
> accomplish that. It's a convention that's enforced by the "go" command.
> This solution is used wi
