TinyGo VS go

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-based WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee.

Go's WASM tooling isn't as good since it doesn't use LLVM and I've found it very difficult to even get parity with vanilla JS performance. There is a way to use a subset of go with llvm for faster wasm ([tinygo](https://tinygo.org/)).

I'm hoping that Microsoft might use some of their wasm chops to improve GO's native wasm compiler. Their .NET wasm compiler is pretty darn good, especially if you enable AOT.

Built a platform flibbert.com where you can run code on ESP32 microcontrollers in AssemblyScript and TinyGo. It’s great for trying things out or learning without the usual setup hassle. Would love for people to try it and share feedback! (The project is on early stage, tested only on esp32-cam)

So, I chose another way. In other words, the approach is to convert it into WASM using TinyGo.

“The language is simple on purpose. If you want cleverness, write LISP.” Go issue tracker discussion

> To convert the Stream.Reader to an std.Io.Reader, we need to call its interface() method. To get a std.io.Writer from an Stream.Writer, we need the address of its &interface field. This doesn't seem particularly consistent.

That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoid mistakes and reach a consistent solution (or as close as possible).

This has been my favorite for a while: https://github.com/golang/go/issues/45624

4 years to decide on something relatively minor, that right now can be done with a bit of a one-liner extra work. But things need to be well thoguth out. Inconsistencies are pointed out. Design concerns are raised. Actual code usage in the real world are taken into account... too slow for some people, but I think it's just as slow as it needs* to be. The final decision is shaping out to be very nice.

It is rare to encounter this in practice, and it does get picked up by the race detector. But the language designers chose not to address it, so I think it's a valid criticism. [1]

Once you know about it, though, it's easy to avoid. I do think, especially given that the CSP features of Go are downplayed nowadays, this should be addressed more prominently in the docs, with the more realistic solutions presented (atomics, mutexes).

I also think Go should add 128-bit atomic operations, which could cover strings and interfaces at least (unfortunately, slices are three words in size). It's on their radar at least [2] and there exists an external package [3].

[1]: https://research.swtch.com/gorace

[2]: https://github.com/golang/go/issues/61236

[3]: https://pkg.go.dev/github.com/CAFxX/atomic128

Sorry. Was at dinner. It's Russ Cox. Being hungry and in a hurry doesn't help with remembering names.

The GitHub discussion is there: https://github.com/golang/go/discussions/58409

but the words I of Russ I cited is here: https://groups.google.com/g/golang-dev/c/73vJrjQTU1M/m/WKj7p...

Copying verbatim:

It's good to know that's what it looks like. I can tell you that the shouting did not really influence the decision. Long-time Go contributors and supporters commenting quietly or emailing me privately had far greater influence.

A few more links that I collected recently on the topic

https://github.com/golang/go/issues/73626

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

https://web.dev/articles/fetch-metadata

https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/

So now there is at least a workaround to preserve the order when processing JSON. Great!

[1] https://github.com/golang/go/issues/27179#issuecomment-22899...

Anonymous functions aren't the same as lambda functions. People in the Go community keep asking for lambda functions and never get them. There should be no need for func/fn and explicit return. Because the arrow would break stuff is one of the reasons.

See

https://github.com/golang/go/issues/59122

https://github.com/golang/go/issues/21498

I'd say it's fair to call this a footgun, though not a bug. The context is really only intended to apply to the goroutines. And Wait has to cancel the context to prevent a resource leak.

I suggest in general using function scoping to drive the lifetime of contexts, etc. This works also for defers and tracing spans in addition to the canonically shadowed `ctx` variable.

There is an old issue in the tracker proposing changes to alleviate this: https://github.com/golang/go/issues/34510. The original author (bcmills) of the errgroup package shared insight into the design choices/tradeoffs he made.

You can check the language out here!