This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (28)
- # asami (13)
- # babashka (10)
- # beginners (170)
- # boot (1)
- # calva (35)
- # cider (21)
- # circleci (13)
- # clara (6)
- # clj-http (1)
- # clj-kondo (29)
- # cljdoc (5)
- # clojure (89)
- # clojure-czech (2)
- # clojure-europe (20)
- # clojure-france (16)
- # clojure-nl (6)
- # clojure-uk (5)
- # clojurescript (80)
- # community-development (6)
- # conjure (13)
- # cursive (18)
- # datascript (9)
- # datomic (1)
- # duct (1)
- # gratitude (2)
- # helix (7)
- # jobs (2)
- # kaocha (3)
- # lsp (22)
- # malli (5)
- # meander (1)
- # other-languages (34)
- # pathom (18)
- # polylith (24)
- # quil (10)
- # re-frame (5)
- # releases (1)
- # remote-jobs (4)
- # reveal (7)
- # shadow-cljs (8)
- # tools-deps (53)
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.
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.
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!).
Yeah, just been reading it. Good to see. Maybe I'll have another round with Go after 1.18 is released with generics 🙂
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.
And it even has some functional in the scheme sense, with proper function closures and all.
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.
Part of that is due to the lack of generics, right?
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.
I'd prefer to have well designed abstractions, but I have to say, those are hard to find in the wild.
Ya if I used it more seriously that would probably annoy me as well. Maybe that's next after generics
consider the following, with the addition of generics and dynamic linking, one could implement Clojure in Go :thinking_face:
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.
The language is limited, but one pod author has generated the Go code from Clojure :-)
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.
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
I did get an error about a missing c lib when trying to run benchmarks with go testing bench=/
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.
That's what I did, though I wondered if it would have affected in turn the performance
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