other-languages

2021-10-26T18:19:44.012100Z

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.

2021-10-26T18:25:17.015800Z

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.

seancorfield 2021-10-26T18:40:08.017400Z

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!).

seancorfield 2021-10-26T19:07:13.019400Z

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

2021-10-26T19:40:48.019800Z

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
2021-10-26T19:41:13.020Z

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

2021-10-26T18:43:17.019100Z

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.

seancorfield 2021-10-26T19:07:48.019600Z

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

2021-10-26T19:42:40.020200Z

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.

2021-10-26T19:43:28.020400Z

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

2021-10-26T19:47:38.020600Z

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

πŸ˜„ 3
2021-10-26T19:48:12.021Z

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

2021-10-26T19:48:46.021200Z

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

Ben Sless 2021-10-26T19:51:09.022100Z

consider the following, with the addition of generics and dynamic linking, one could implement Clojure in Go πŸ€”

2021-10-26T22:57:08.028200Z

Are they also adding dynamic linking? That's interesting

Ben Sless 2021-10-27T03:55:02.030700Z

They did some time ago

Ben Sless 2021-10-26T19:57:56.022500Z

also see https://github.com/pcostanza/slick

borkdude 2021-10-26T20:11:40.023800Z

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.

borkdude 2021-10-26T20:12:06.024500Z

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

2021-10-26T22:51:57.027700Z

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

borkdude 2021-10-27T05:45:21.032Z

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

nooga 2021-12-01T13:34:07.036800Z

let-go might be going this route

nooga 2021-12-01T13:34:33.037Z

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

phronmophobic 2021-10-26T20:30:06.026800Z

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.

phronmophobic 2021-10-26T20:55:25.027100Z

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

borkdude 2021-10-26T21:02:20.027400Z

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

1
2021-10-26T22:55:42.027900Z

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

ksd 2021-10-27T02:57:48.029600Z

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.

2021-10-27T03:08:02.029800Z

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

ksd 2021-10-27T03:14:33.030100Z

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

2021-10-27T03:15:17.030300Z

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

2021-10-27T03:15:30.030500Z

As opposed to my code

Ben Sless 2021-10-27T03:56:22.030900Z

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

πŸ‘ 1