✧✦Catherine✦✧
y'know... from a language design perspective, i think rather little of go. i think its primary redeeming quality is that it is a sort of harm reduction outlet for C programmers
however, now that i've learned to be efficient with it, i don't actually mind writing go code. sure, the language is an atrocity, but so is cmake and i don't mind being effective with that either
✧✦Catherine✦✧
@xgranade well yes but if i wanted usable data structures i would be writing rust. i'm writing go because i get to bang two rocks together and an API comes out the other end and it's mostly not horrifically memory-unsafe
Cassandra is only carbon now
@whitequark The lack of generics for so long really lands it pretty firmly in the "what if C but" category for me. It's really, really hard to make any kind of usable data structures without generic functions and/or types of some kind.
✧✦Catherine✦✧
@xgranade i've only wrote a generic function once so far (well into >80% completion territory for this project) and it was because i had no choice
✧✦Catherine✦✧
@xgranade re: banging two rocks together: the library is called `otter`, it's a very relevant activity
✧✦Catherine✦✧
on the flipside, the module system is so bad i genuinely think it needs to be a case study, in the sense that chernobyl is a case study
✧✦Catherine✦✧
@xgranade i absolutely agree
Cassandra is only carbon now
@whitequark That makes a lot of sense, yeah. My point was that Go is a C-alike in my understanding, given that it kind of repels more sophisticated data structures — there's definitely applications that works for, as you say!
✧✦Catherine✦✧
the libraries have so far been a pleasant surprise. i read source code of my dependencies (there's only one direct dependency in this project that i haven't done a deep dive into, and it's google/protobuf) so i get exposed to hidden warts early and often. i expected a lot more hidden warts
maybe it's a consequence of having many fewer degrees of freedom in the langauge design? sort of like how it is with erlang
✧✦Catherine✦✧
@pry hm... it's been a while that i've actively looked for a language for its design choices, which isn't directly relevant to what you said but an interesting reminder to myself
💜 pry 💜
@whitequark Yeah I really dislike Go... I prefer it to C for most things because I really dislike C as well.
The primary thing I look for in a new programming language tbh is a type system and Go just does not deliver.
✧✦Catherine✦✧
@q3k i don't think these are incompatible views; we are talking about different part of the project. my beef with the module system is that the user experience is among the worst, certainly the worst of any language with this level of popularity
every time i need to do something to go.mod or to install a binary it's a fucking coin flip between like four different invocations and whether any of them will work
q3k :blobcatcoffee:
@whitequark Interesting, mind elaborating? I have the exact opposite opinion, I think Go has solved packaging/modules much better than other languages I've used (eg. no central registry with a flat namespace, a stable version selection algorithm).
✧✦Catherine✦✧
@pry i'm extremely in the same boat language deisgn wise; Amaranth for example is incredibly boring from a structural standpoint but wins a lot of hearts because it's actually pleasant to use and not actively filling your life with suffering
💜 pry 💜
@whitequark I've been looking mostly because I'm really interested in programming language design from a usability stand point and also for how we make guardrails and better systems languages that are still easy to use.
Rust is a big inspiration for me, and I'm really interesting in how one could design a language that helps programmers even more.
One of the main tools when it comes to helping programmers is describing their data in more concrete terms
✧✦Catherine✦✧
@q3k i don't know that i entirely agree with your statement on the registry (the go package registry appears to be "github.com" for any practical purpose, e.g. see below) but it's just not something i feel qualified to comment on yet
✧✦Catherine✦✧
subjectively and with a lot of handwaving, there are certain qualities i look for when i'm on a hunt for a good rust library, and i feel like a randomly chosen go library gets closer on average to these qualities than a randomly chosen rust library
rust has many exceptionally well done, unambiguously industry leading projects, but also enough code that i look at and go "hmm no i think i would rather just rewrite this". i experience this with go a lot less so far
✧✦Catherine✦✧
@q3k i can see that but also wouldn't using git URLs with Cargo give you more or less the same capability?
q3k :blobcatcoffee:
@whitequark I think it's super useful regardless of what people actually distribute over, as the decentralization is not even of primary importance here.
It's that you can actually easily integrate projects that only live in private Git repositories or local filesystems, in multiple packages, without having to deal with a flat namespace of packages. It makes it super easy to maintain codebases and packages that are internal to an organization.
mcc
@whitequark I don't exactly like this conclusion but I've come to suspect that a great deal of good language design is hiding in Kernighan's quote about, it's twice as hard to debug a piece of software as it is to write it, most coders write as cleverly as they can, therefore by definition they're not clever enough to debug that code. I think some languages get wins by forcing coders to code less cleverly
✧✦Catherine✦✧
@mcc yeah
✧✦Catherine✦✧
@crawshaw yeah, I can see that and it tracks with my own conclusions as an outsider watching the space for years
David Crawshaw
@whitequark solving a smaller set of problems is a powerful tradeoff, it lets you focus on other things.
David Crawshaw
@whitequark I suspect I could replace many of my remaining uses of C/C++ with Rust, but old dog, etc. I will the day the big dependency I need is written in rust.
David Crawshaw
@whitequark I think a lot of people programming in Go broadly agree. I use it because it’s the best tool to solve many problems quickly. Definitely not all problems. And Go libraries set out to solve many, but not all problems. I still reach for C (and C++) sometimes.
✧✦Catherine✦✧
@ignaloidas i actually found that there are surprisingly few choices in good serialization libraries
json? slow, bulky
bson? the library i found can't marshal maps deterministically
flatbuffers? no support for maps
protobuf? can do deterministic marshalling, but working with protoc is somewhat painful and the opaque API migration is a mess
Ignas Kiela
@whitequark@mastodon.social re not diving into protobuf - probably a good choice, I haven't seen a non-cursed protobuf library from google
✧✦Catherine✦✧
now that i've done my share of criticism today, feel free to criticize my go code: https://codeberg.org/whitequark/git-pages/src/branch/main/src
✧✦Catherine✦✧
@sabik @ignaloidas for a while i unironically considered using the toml library i use for configuration parsing for general purpose serialization
sabik
@whitequark @ignaloidas
yaml? xml? gd&r
✧✦Catherine✦✧
codebases that i quite like: go-git (and go-billy), maypok86/otter, caddyserver, tailscale.
i don't know if i feel affectionate about it it but i'm at least extremely amused by the cursed amalgamation of caddy and tailscale within a single binary
✧✦Catherine✦✧
@pry 100%
💜 pry 💜
@whitequark honestly thats all i can ask for.
also im of the opinion that like theres a "cool flashy new feature budget" and if you introduce too many things in a language, it becomes super hard to adopt.
cliffordheath
@whitequark What kind of determinism do you expect from a map? They're not sorted by keys, unless you have a sorted map implementation - but sorting is not a standard property of maps.
Christian Huitema
@whitequark @sabik @ignaloidas Have you tried CBOR? Essentially a binary version of JSON. Specified in RFC8949, used in several IETF specified protocols. https://www.rfc-editor.org/rfc/rfc8949.html
✧✦Catherine✦✧
@huitema @sabik @ignaloidas someone else suggested it in this thread and from what i can tell CBOR is the correct answer here
✧✦Catherine✦✧
@cliffordheath sorting can be a property of maps/dictionaries, but i realize that it isn't in go. however, this has no bearing on how maps are serialized, as serialization libraries can and do make choices that narrow down core langauge semantics
cliffordheath
@whitequark Right. So you do require sorting for determinacy. Anything else?
✧✦Catherine✦✧
@cliffordheath
- reasonably compact binary format with backwards compatibility (i persist data long term)
- deserialization that costs more like a memcpy than like a parser
- if there's an associated in-memory data structure, i need it to represent embedded `bytes` values efficiently
- either a pure-Go code generator, no code generator, or generated code i can check into the repo and forget
✧✦Catherine✦✧
@huitema @sabik @ignaloidas i could deffo manage that (i wrote some protobuf tooling for example) but https://github.com/fxamacker/cbor seems like i can include it and forget, which is very nice indeed
Christian Huitema
@whitequark @sabik @ignaloidas I had to use CBOR in a project that was parsing DNS traffic logs written per RFC 8618 (Compact DNS archives in CBOR). I ended up writing a parser in C++. Was not very hard: https://github.com/private-octopus/cdnsrdr
cliffordheath
@whitequark These are excellent goals, closely aligned to my goals for <https://github.com/cjheath/adl>. ADL is primarily a text-based language, and (unlike most similar languages) it is strongly lexically typed, supporting an extensible type system which allows new value syntaxes to be defined by (non-)regular expressions. The implementation of these expressions is currently being upgraded to support binary storage types. I welcome collaboration on Golang and other implementations
✧✦Catherine✦✧
@cliffordheath oh this is definitely up my alley, i'll try to find some time to look at it in detail!
nelhage
@whitequark caddy and tailscale together into a single binary...
🦋 is this a unikernel?
✧✦Catherine✦✧
@ppxl literally anything goes; it's only fair, given my rambling thread about golang
Pxl Phile
@whitequark how do you like your code critique best? As pull request for discussion or as issue or here as thread or... 😅
Edit: and which level of discussion do you prefer (f.i logic over technicality, docs, everything found, etc)
✧✦Catherine✦✧
@david_chisnall I was fascinated for a long time by a perceived inconsistency: the Go people talk a *lot* about how important CSP is and how fundamental are the principles (which I don't disagree with!) But then you turn around to actually use the concurrency primitives and you find out that, far from the claims of the language buit with and around concurrency, it feels more like someone's awkward PhD thesis attached to an otherwise very boring language than a core, inalienable part of it.
David Chisnall (*Now with 50% more sarcasm!*)
When I wrote a book about Go 1.0, my conclusion was that it included every good idea Rob Pike ever had (and that’s good, because he’s a smart person) but zero good ideas anyone who is not Rob Pike ever had (and that’s bad, because there are a lot more smart people who are not Rob Pike). I think it’s improved since then, but not fundamentally. A language that encourages concurrency but has nothing in the type system to make accidental aliasing hard (and whose memory safety guarantees depend on data race freedom) is far from ideal.
Then I talked to a bunch of Go programmers and found that they mostly don’t use the concurrency, they use it because it’s an alternative to Python that produces statically linked binaries.
✧✦Catherine✦✧
@david_chisnall It's hilariously incomplete! you can't even send multiple values through a channel to get a function's return value back to the caller!! I understand that Go lacks tuples but it has special cases galore, surely if Go was serious about concurrency they could've made channels accept a product type or something.
✧✦Catherine✦✧
@david_chisnall (I did my best to stay up to date on Go news and design over the years and eventually came to the conclusion that quite a few of the people who make Go what it is engage with the field of PL design on a very superficial level. Go concurrency feels to me as a result of the same; a long chasm between "let's put this cool and useful concept into the language" and "here's how the tool we built is uniquely suited to aid the goals of the people who use it".
✧✦Catherine✦✧
@david_chisnall my point, to be clear, isn't "Go didn't need channels". they're an essential building block, I mean the carbon copy of these basic primitives is essential to Rust's concurrency today. it is rather "okay, and when do we get to the part where the whole becomes more than the sum of its parts?"
✧✦Catherine✦✧
@chozu i had to spend half a hour with the docs but i don't mind that
chozu
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.