Post B7f5L5eeW8ddvOVttg by radex@social.hackerspace.pl
 (DIR) More posts by radex@social.hackerspace.pl
 (DIR) Post #B7f5JK3fzhIM19NKd6 by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       Learning golang. Here's what I like:- it's a compiled lang - pretty fast, produces smol binaries - excellent for distribution- it's memory-safe- it's simple - easy to learn, fast to compile, no faffing about with the memory model and type checker- batteries-included stdlib- stability/conservative updates - great for things you want working for a long time without maintenance
       
 (DIR) Post #B7f5JKGnCvmqfpVo4e by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (golang thread)Given its "simple language" status, it's surprising that its authors decided that *this* is something that's important to include, but *enums* are not.Been a while since I wrote in a "modern" language where type checker can't even enforce an exhaustive enum switch.
       
 (DIR) Post #B7f5JKUGOqYvLboZ4S by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       but back to things I do like about Go:- I enabled a Go extension in my editor, and everything *just worked*. formatting, linter, import cleanup, autocompletion, fixits, jump to definition - no choices to make, it all just works out of the box- you can simply LSP-jump to definition and read the source code of the relevant stdlib part. Not just the signatures, the whole thing. (Other than a handful of builtins).
       
 (DIR) Post #B7f5JKgfeiUFy5cTPU by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       Not sure how I feel about private/public visibility being per-package (per-folder).Go-pilled people seem to like it, but like, if you have a struct that you can't express so that its zero value is useful, you kinda just have to *remember* to use an initializer function instead of constructing the struct, no?
       
 (DIR) Post #B7f5JKuUpJXuey5VxY by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       I find it somewhat amusing that *these* are the syntactic conveniences golang authors deemed worthy, but nothing for handling errors
       
 (DIR) Post #B7f5JL5UASKvD3EI5Y by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       Golang mini-project No. 1: add an aggregated events calendar for the Polish hackerspace community: https://hakerzy.info/https://code.hackerspace.pl/zhp/site/pulls/3
       
 (DIR) Post #B7f5JLIxMN6zspX35M by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (golang thread) Maybe not the most important thing, but man, it's very satisfying to have the *entire* container image at 7MB. Doesn't even need libc, just the root CAs and timezone db.The best I was able to get with Typescript (with Bun's single binary build + distroless) was 47MB
       
 (DIR) Post #B7f5JLVMcF2KVJKxQO by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (golang thread) The frequent mentions of Plan 9 in Go's stdlib docs is hilarious.[ @ol0ck entered the chat ]
       
 (DIR) Post #B7f5JLhls6xf7n8rlQ by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (golang) Seems like one of the things that makes Go great - simple syntax, type system, memory model - is also the thing that makes Go frustrating.I'm missing basic conveniences, the ability to express even simple constraints, and there's much you just have to remember to do as you can't rely on static analysis.I wonder how much of that tension is a  design flaw (i.e. a different design could be better) vs fundamental
       
 (DIR) Post #B7f5JLweyks3ry6kyG by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (golang thread)Whyyyyy does Go testing lib not have assert/expect-style testing?Testing is annoyingly verbose in any language as it is. Writing useful t.Errorf by hand for every assertion sounds awful.
       
 (DIR) Post #B7f5JMLpTB0J81srCa by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       I'm pretty sure at least some syntax-level conveniences (e.g. less noisy error handling) could be achieved without major downsides, but I don't know about type system expressivity. Seems like languages that go down that rabbit hole tend to become quite complex and slow to compile.
       
 (DIR) Post #B7f5JN0F2vKX9Mn8C0 by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       So, in Go, structs are passed by copy, but this can be unsafe - a mutex is a canonical example.There's no way to express "do not copy" in Go, so they instead added a rule to the built-in static analyzer to warn if you copy a mutex.But what about other types? You just add into it a struct that *pretends* to be mutex (implements Locker interface). lol, lmao
       
 (DIR) Post #B7f5L4E1pdkPUX37lA by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       Weekend
       
 (DIR) Post #B7f5L4pxYc5ZOAnPsm by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       Out of sheer curiosity, I checked how long it takes to build Go from source (including the bootstrap chain, starting from an older go compiler) on my (5 year old) laptop.Less than a minute!
       
 (DIR) Post #B7f5L4x38FlBkA74vw by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       I'm writing an experimental concurrent streaming parser for a toy language, in Go.Reading off disk, tokenizing, and parsing into AST happens in parallel. Furthermore, imports are signaled to the top goroutine as soon as they are encountered, so files in the build tree can begin parsing before the first file even finishes reading.
       
 (DIR) Post #B7f5L5HbtoCslvjUyu by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       What I neglected to mention is that the toy language in question is a purely functional, lazily-evaluated description language. A perfect fit for parallel execution.I didn't get to the "parallel" part yet, but I do have a working evaluator. Here's a classic fibonacci recursive call demo:
       
 (DIR) Post #B7f5L5TJCJZ3MDCqDQ by radex@social.hackerspace.pl
       1 likes, 0 repeats
       
       To the surprise of absolutely noone, my first naive attempt at parallel evaluation yielded a result 6x slower than the original non-parallel version. 4x slower with some simple improvements.On the bright side, it was easily able to saturate my computer's 10 cpu cores.Oh well. I have more ideas, so back to experimenting 😎
       
 (DIR) Post #B7f5L5eeW8ddvOVttg by radex@social.hackerspace.pl
       0 likes, 0 repeats
       
       (For the record, I doubt that this level of concurrency is useful. Processing a single file tends to be cheap, and having lots of files is enough to fill multiple cores. I'm doing this just for fun.)