0xjnml

$ mkdir foo

$ cd foo

$ go mod init example.com/foo

$ touch foo.go

tl;dr: Looking forward future Pinner.Pinn performance improvements.

The Go code shown now is both syntactically valid and semantically correct: https://go.dev/play/p/GDki9v78jMM

I can't check how it looked 15 hours ago.

Makes me wonder if it was manually corrected and is thus a fake example now.

C is a very common letter. That's why people search for it using the word clang. Oh wait.

openbsd/amd64 is not a supported target. Here's the list: https://pkg.go.dev/modernc.org/sqlite#hdr-Supported_platform...

modernc.org/regexp @v1.2.0, relative to the stdlib regexp package:

- performance sec/op, geomean -14.51%

- throughput B/s, geomean +25.99%

- regexredux-dna, wall time: -63.4%

> The gist is Go ignores all research in programming languages.

This is an assumption and it's IMHO false. Go creators watched all the research, probably closely, lived with its results and were not happy with what they get. Their experience reminded them that less features in a PL make it arguably less expressive, sure, but in the same time it makes it faster to learn and master, easier to read and debug. Writing tools is simpler if a parser for your language can be hacked over the weekend from scratch, etc.

At the end of the day its a matter of personal preferences, but it has, IMO, nothing to do with "ignoring all research in programming languages", quite the opposite.

From the language specification: "The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next."

There's a long shot between "not specified" and "uniformly random".

All commits to the Go repository must be approved by two Google employees: https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/3mg1O...

Thanks for the feedback, I tried to add a paragraph explaining it a bit more.

Please let me know if it did not help, thanks.

How can a precise garbage collector work when it does not know if a value is or is not a pointer?

> I think if Golang would have been invented a couple of years later it def would have had sum types.

How to combine sum types and a precise garbage collector?

> it seems bogus that maps don't; this doesn't compile in Go if m is a map:

It does not seem bogus to me. Values in a map are not addressable for a good reasons. It allows more freedom in implementing a map. Arrays, on the other hand, are specified to be continuous in memory, hence the implementation is set in stone.

Also, non-existent items of a map return the zero value as specified. Now assume the map items are addressable. What exactly should happen if you refer to a field of a map item that is not in the map? Is there a possibility that is not surprising?

> ... especially in Golang where cleanup deferrment is encouraged and touted in lots of example code

Go's os.File is not a plain file descriptor. It can be safely closed more than once and will close the underlying FD only the first time the .Close() method is called.

No, a simple conversion can create an interface containing a typed nil. No need for the reflect package, neither messing with internal representation: https://go.dev/play/p/HGVNzf8gL-m

FTR: I'm not affiliated with nic.cz, even though I worked there 10+ years ago.

The release adds a newly supported target - freebsd/amd64.

> ... Java-derived languages (C#, Swift, Golang, Kotlin) ...

Swift and Go do not belong to that list.

Goroutines are asynchronously preemptible since Go 1.14, released February 25th, 2020.

https://blog.golang.org/go1.14

1) Go string type is specified as a sequence of bytes. Full stop. Any encoding, binary blob, string does not care. Particular stdlib string functions _do_ care, expect UTF-8 encoding and document the fact. Other stdlib string function work with the sequence as a sequence.

3) Go specification requires UTF-8 in only one place: the encoding of Go source files string literals.

2) Pure ASCII is a subset of UTF-8, ie. pure ASCII _is_ valid UTF-8. There is _no_ more work and there are _no_ security problems when working with pure ASCII as UTF-8, because that's what it is.

> Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer.

CGo-free SQLite for Linux: https://godoc.org/modernc.org/sqlite

Yes it is. The driver uses the original sqlite3.c code mechanically translated to Go.

FTR: The go/parser package was _never_ used by the Go compiler. It used to be a yacc generated one when the compiler itself was in C. Then it was all mechanically translated to Go. And finally, a hand written lexer and parser were adopted, but different from the ones in the stdlib.

Go strings are just a sequence of bytes in no particular encoding, i.e they can contain arbitrary data. Converting strings to byte slices and vice versa works always without ever changing a single bit.