41–50 of 305 posts
Very insightful. Re: the generics point — As a Go programmer I always thought the generics complaint was kind of silly in practice — complicated code should be simplified and made more concrete, not more generic. I’m glad generics were implemented, if only to silence the chorus of people who didn’t even use Go but whined about the lack of them. Their inclusion has simplified the stdlib and led to some cool new functi…
> power What power?
My first reaction when seeing Go is that it smelled of "old fart". It looked straightforward and unexciting. I'm an old fart. I like straightforward and unexciting. It tends to lead to code that I can still read 6 months from now.
I want to make stuff and not endure people boring me with this weeks clever language hack they came up with that expresses in one unreadable line what could have been expressed clearly in 3 lines.
The simplicity of the language and the stdlib is shockingly well thought out -- things like io.Reader are so obvious and yet not part of many other languages. The language has made me a better programmer. And the cross-compilation story is chefs kiss.
Working on a cross-platform project where in Go, I write code and it just builds. In Java, I fight with Gradle. In Swift, I fight the type system and the way everything's constantly deprecated.
It's not all perfect. I wish the generated binaries were smaller. I wish the protobuf library wasn't awful. And better Cgo/FFI would be nice.
But overall, I've never been so productive.
I learned Go on and off in recent years on the side(daily job does not need Go), I like its battery included stdlib and cross platform support. I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot. On the desktop side, I…
Impeller is the Skia replacement and is in full c++ that supports all platforms.
It will be great if Go team can work with them(both are in Google) and make Impeller a render engine for Go.
With this no more bloated electron.js and no more Java/Swing or Qt, what a dream for the day.
Go has turned into an Awesome language. I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures. Now it has Generics, soft RT GC, and it might even get official Arena Allocation. I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.
> the DX of Algorithms and Data Structures sorry, what does this phrase mean?
This rubs me the wrong way. Even back when Go first came out, anyone who knew anything about programming languages rolled their eyes at pretty much everything about Go's type system, including the inference. Just because Sun couldn't figure out how to do it in the 90s doesn't mean that type inference wasn't mostly solved in the 70s. Well before many people were using it or lived any real length of time, Go's always been a language people have - rightly - complained about.
That said...nothing in the original post says anything along the lines of "Go's type inference [is] an advance in the state of the art", so I might be misunderstanding the author here.
I learned Go on and off in recent years on the side(daily job does not need Go), I like its battery included stdlib and cross platform support. I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot. On the desktop side, I…
Also having a single binary is good in lots of cases because then you don't have the install runtime/separately install shared library
Go has turned into an Awesome language. I'm one of those that cannot use a PL that has no generics... It kills the DX of Algorithms and Data Structures. Now it has Generics, soft RT GC, and it might even get official Arena Allocation. I /LOVED/ the Matklad comment of |error handling converging|, indeed -- it seems that PL community evolved to "any-error" + annotation-at-call-site.
> the DX of Algorithms and Data Structures sorry, what does this phrase mean?
I learned Go on and off in recent years on the side(daily job does not need Go), I like its battery included stdlib and cross platform support. I do feel its binary size is large comparing to c and c++, and multiple Go executable can not share libraries as easily as how c/c++ uses the shared lib, when I have a few Go binaries they add up, and I do storage constrained embedded development a lot. On the desktop side, I…
https://pkg.go.dev/cmd/go#hdr-Build_modes
you can actually build with shared libraries :)
I think most people I've seen use go, only use a single application, or have it turned into a docker container; so for them this is pointless but just fyi.
I personally dislike static linking but I see why it was used so heavily with go.
Earlier quoted context omitted.
The typical answer is that Go doesn't allow you to not address values returned from a function. So, to ignore an error, you'd typically have to write: result, _ := myfunc() That being said, I most certainly prefer the approach that Rust takes to this problem.
a, err := f() if err != nil { return } a, err = f() This will compile.
Yeah, it might be nice if it were integrated into the language but on the overall cost/benefits analysis of my actual costs & benefits rather than merely aesthetic ones, this one doesn't actually factor very high for me because using errcheck is easy. And I supplement all languages I use seriously with aftermarket checkers so it isn't like this is special pleading for Go, either. I don't trust any language out of the box any more.