Fork me on GitHub
#other-languages
<
2021-10-26
>
didibus18:10:44

Started learning Go, and I definitely enjoyed some of the decisions they made. But oh boy that compiler is strict. Can't even comment out a line without it complaining.

didibus18:10:17

In a weird way, once they add generics, I think it'll be a pretty great language. It makes very different trade offs to Clojure which just gives it another feel. Where I feel Clojure is like a midi keyboard, Go is like a Recorder Flute. It kind of makes the language something you can't really have any fun with, which would change the focus on the actual program outcome I guess. And I can see that being good for a code base worked on by many people over time. That has its own charm as well.

seancorfield18:10:08

Are they now planning to add proper generics to Go? I was very disappointed with it, as a language, when I learned it several years ago. I was sort of hoping it would be more like Rust (which I can say now with hindsight, because I didn't learn Rust until a year or two after learning Go!).

seancorfield19:10:13

Yeah, just been reading it. Good to see. Maybe I'll have another round with Go after 1.18 is released with generics 🙂

didibus19:10:48

It's still gonna be very different than Rust. But I think the lack of generics was a cause of some verbosity with having to have one function per type. With the generics, that is resolved. And while it is still a bit verbose in only having a for-loop for example, I think for an imperative concurrent language with a GC, it does a really good job.

👍 1
didibus19:10:13

And it even has some functional in the scheme sense, with proper function closures and all.

Stuart18:10:17

I despise Golang. We have started to use it a bit at work, it's miserable. Everything is such hard work and so much code. You can't offload any of the complexity of the problem you are working on to the language.

seancorfield19:10:48

Part of that is due to the lack of generics, right?

didibus19:10:40

That's the appeal of it too though. There are no abstractions to learn beyond a few basic ones. I think it bypasses the problem of having badly designed abstractions by just not having any 😛 Though I have not really done anything serious with it.

didibus19:10:28

I'd prefer to have well designed abstractions, but I have to say, those are hard to find in the wild.

Stuart19:10:38

The lack of generics certainly doesn't help! But this also drives me batty

😄 3
didibus19:10:12

Oh HAHA, ya I forgot about that, the error handling is crap lol

didibus19:10:46

Ya if I used it more seriously that would probably annoy me as well. Maybe that's next after generics

Ben Sless19:10:09

consider the following, with the addition of generics and dynamic linking, one could implement Clojure in Go :thinking_face:

didibus22:10:08

Are they also adding dynamic linking? That's interesting

Ben Sless03:10:02

They did some time ago

borkdude20:10:40

Go lang is a very nice language to implement babashka pods in since they yield small binaries and go can cross-compile (although it has limits). Several pods are written in golang here: https://github.com/babashka/pod-registry Also some in Rust, most of them in Clojure. But if you ask me, Go is a very solid choice for that use case.

borkdude20:10:06

The language is limited, but one pod author has generated the Go code from Clojure :-)

didibus22:10:57

Wow, a kind of subset of Clojure to GO transpiler?

borkdude05:10:21

Not really, just boilerplate reduction by generating specific go code fragments

nooga13:12:07

let-go might be going this route

nooga13:12:33

I have already done some experiments to build Go programs from the bytecode

phronmophobic20:10:06

Now that the go compiler is in go, how do they handle emitting the architecture specific assembly? When the compiler was still based on c, I can imagine how they would farm that work off to gcc or clang, but I'm having trouble imagining how they would do that without clang/llvm or gcc. Anyone know how that works or having references? I'm having trouble googling that question.

phronmophobic20:10:25

nvmd, found a good resource https://golang.org/doc/asm go has its own machine-independent assembly and its own assembler with support for various architectures

borkdude21:10:20

yeah, they don't rely on C or glibc etc at all

notbad 1
didibus22:10:42

I did get an error about a missing c lib when trying to run benchmarks with go testing bench=/

ksd02:10:48

try building your benchmarks with CGO_ENABLED=0 in your env. I think this removes all builtin dependencies of Go on C (`net` package, etc.). this won’t work if your benchmarks or your dependencies depend on C though.

didibus03:10:02

That's what I did, though I wondered if it would have affected in turn the performance

ksd03:10:33

I would guess yes, but you’d have to measure to be sure and to know how much

didibus03:10:17

What's weird is I didn't get the error when just running, its only when using go testing bench, so I wondered if its the benchmark package that needs the c lib

didibus03:10:30

As opposed to my code

Ben Sless03:10:22

There's also a very interesting talk by Rob Pike on the assembler. It's the best part about golang, imho

👍 1