go VS TinyGo

Have you looked for any evidence? There is plenty.

Sum types have been discussed since before the initial open source release of the language, at least according to some of the issue threads such as https://github.com/golang/go/issues/19412

If they're laughably simple, then please contribute a proposal for how to add them to the language. You'll find no one is really fighting against the concept of sum types.

I agree that there are no objective measure. I guess it's just different expectations.

I would not say it's obvious what the machine is doing in the Go example though. For example it wasn't clear to me that append() mostly doesn't copy the full vector, but does a copy of the slice pointer. I had to look it up from a blog post, because the source for append() is gnarly

https://github.com/golang/go/blob/go1.16.7/src/cmd/compile/i...

jaredpar on the C# team offered the very first comment on the Github issue for this proposal: https://github.com/golang/go/discussions/56010

I think it played a large part in helping get past the default-deny that any language change proposal should have. The other big one for me was the scan done over the open source code base and the balance of bugs fixed versus created.

Most commonly no impact. It can require an additional heap allocation per iteration if taking the address or capturing in a closure, but even in those cases escape analysis may be able to determine that the value can remain on the stack because it will not remain referenced longer than the current loop iteration. If that happens then this change has no impact.

I'm not sure how thorough Go's escape analysis is, but nearly all programs that capture the loop variable in a closure and are not buggy right now could be shown to have that closure not escape by a sufficient thorough escape analysis. On the other hand for existing buggy programs, then perf hit is the same as assigning a variable and capturing that (the normal fix for the bug).

Google saw no statistically significant change in their benchmarks or internal applications.

https://github.com/golang/go/wiki/LoopvarExperiment#will-the...

This will crash if `foo()` returns nil, because it's checking if `x == interface{}(nil)`, which is false. What you wanted to check was whether `x == *bar{nil}` or one of the other nil types that implements the interface; which must be done with `reflect.ValueOf(x).IsNil()`.

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

I’m referring to this guideline:

> Variable names in Go should be short rather than long. This is especially true for local variables with limited scope. Prefer c to lineCount. Prefer i to sliceIndex.

https://github.com/golang/go/wiki/CodeReviewComments#variabl...

> Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable.

uh-huh

but, in all seriousness: I wonder why that is? I struggle to think of a technical reason that go would be unable to load and invoke a .dll even if one had to name it .so https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin...

You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’

You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0

There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900

Threads are Phase 3

https://github.com/WebAssembly/proposals

You can also check out:

https://webassembly.org/roadmap/

And for Go, the proposal project on Github has many interesting conversations from the devs.

And as a reminder to anyone interested in using Go WASM, it’s experimental and does not come with the same compatibility promise as Go itself:

https://github.com/golang/go/wiki/WebAssembly

You should also consider TinyGo. It can compile Go for the Pico, and is starting to get good device support.

Thankfully some folks completly ignored whatever the rest of the world thinks system programming is all about and created:

- TinyGo (https://tinygo.org/), which is acknowledged by people in the industry[0][1]

- TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-...)

And then there is the question if writing compilers, assemblers, linkers is systems programming or not.

[0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f...

[1]-https://twitter.com/ArmSoftwareDev/status/131680481331796787...

Have you seen TinyGo? In the case of embedded system I would probably still chose C over Rust if the system didn't support dynamic memory allocation, and most embedded systems do not.

Gist link fixed, thanks. Compared to TinyGo, Go with GOOS=wasip1 will probably generate larger artifacts (at least, for now). This is because it bundles the entire Go runtime. The benefit is that it fully supports goroutine scheduling and non-blocking I/O. TinyGo (I believe) still uses a custom asyncify pass and does not support non-blocking I/O nor basic WASI networking (e.g. https://github.com/tinygo-org/tinygo/pull/2748 never landed, but GOOS=wasip1 supports it).

Look into Go(lang), which runs on ARM boards (including via tinygo on the low end like the RPi Pico) or Embedded Rust. C++ is optimized for creating buffer overflows.

Great article. See also: TinyGo.

https://tinygo.org is an alternate compiler for embedded or wasm use cases.

> If Go got LLVM frontend yeah, maybe

While Go probably wont get an official LLVM frontend, the TinyGo project [1] is trying to bring Go to embedded systems and it does use LLVM. Unfortunately I couldn't find any use for it in a project since it lacks so many features from mainline Go. Maybe I'll check back in a few years.

[1] https://tinygo.org/

This is a demo of custom firmware I wrote for the Uncertainty module using TinyGo. The script is using the TinyGo tone package to create 3 configurable digital square wave oscillators. Each oscillator can be quantized to a melodic scale and can set a root note for stacking chords or creating sub oscillators.