at times i want to kill the gopher that go has because go is statically typed and I have to write more code sometimes but then you have node packages like is-number and I praise our lord and saviors :go: :ken: :pike:

@kirby
The only thing that irked me about Go is having to describe all the JSON data structures beforehand — to be able to parse them. Maybe there is a way around it or tools that facilitate this, but I didn't find it. Rust's serde_json for example doesn't make you do any of this.
But when you compare it to dynamically-typed languages' "true=false" type of situations, I think I'm fine even with this 🤣

@romin @m0xee I swear I read something about "unmarshal to a struct, to have type safety" on reddit

???
Follow

@kirby @romin
No, it's fine. I mean, of course it's recommended against — of course it's best to define the structures than to not define them — so if you feed it some weird input instead of what you expect, you'd realise it sooner than later.
I've never tried it, probably should work — why should it not, having reflection, it's trivial to implement.
In any case, I think I'm done with Go — I really like the language, but I don't like the direction it's heading under this governance.

@kirby @romin
They are deprecating old architectures just like that! Look at this for example: github.com/golang/go/issues/19
It's literally:
— But PowerMac G5 is the most widely available ppc64 hardware, we can't deprecate that!
— Tehe, just ask IBM for newer hardware 😘
This isn't user's perspective, this is corporation's perspective — they don't give two fucks about the users.
Rust having much less resources has PowerPC support, community-driven Zig and Nim do, albeit a bit buggy. Go does not!

@kirby @romin
Then they are adding shit no one asks for — that doesn't enable you to do new things, but allows you to do the same things differently — and they are adding them for the sake of being different.
Look at the typical Go dev here: dolthub.com/blog/2024-07-12-go
OMG, there is a new way to do iterators, let me update my library to use that right now!
WTF?! I'm not playing this game!

@kirby @m0xee @romin
Yeah, Rob Pike should restrain Cox sometimes, I thought the language was done before generics, now he's talking about coroutines, Go was simple and is becoming less so. I do fucking hate how you need a newer compiler version to compiler the compiler, Rust does that and it's stupid.
@kirby @m0xee @romin
If they start fucking Plan 9 then I will, as P said, go back to writing C forever.

@sysrq @kirby @romin
Yeah, exactly! They should've left the language alone in the state it was described in the Go Programming Language book — it was perfect!
They are introducing breaking changes that do not really bring anything new to the table — but community seems fine with it: when you try to build a more or less active project with gccgo, turns out things are already broken and you have to "backport" things.

@sysrq @kirby @romin
Even Rust isn't that bad, its standard library is very limited and popular crates often get changes for changes' sake, the most recent one that pissed me off being clap, the popular crate for working with command line arguments — I'm reading a book that was published a few years ago and the examples do not work in the newest version already! The changes are trivial: they have renamed a couple of classes (e.g. App to Command), a few functions here and there…

@sysrq @kirby @romin
Yeah, the new names reflect what's happening kinda better, but still, what the fuck for?
And all that being said, I can roll rust-std and rustc five minor versions or even more back and everything still builds fine.

@sysrq @kirby @m0xee
>Starting in Go 1.23, the Go toolchain can collect usage and breakage statistics that help the Go team understand how the Go toolchain is used and how well it is working. We refer to these statistics as Go telemetry.
uh oh, also heard they wanted to require pyth*n to build the compiler in a future release
@romin @kirby @sysrq @m0xee > an entire software ecosystem has become infested with spyware

who could've seen g*ogle doing this?

@VD15 @kirby @sysrq @romin
The true scale of Google's penetration is yet to be assessed — there are all those tiny things like brotli or protobuf that you don't even expect to be in the software you use, but it's there!
And it isn't immediate spyware, yet our reliance on this company for technology still poses a major threat IMO — you can't just take it and use it: sooner or later they start pushing shit you might not want with the thing that is essential to your project.

@kirby @romin
And Python is turning into the same kind of shite BTW: new ways to do old things, deprecating things in one release, and not deprecating that again in the newer one, which is only month apart.
Same architecture support shenanigans, look at this: mail.python.org/archives/list/
"OMG, my machine broke, so we're lowering the architecture to Tier 3"
Python used to work everywhere, soon they will end up with Darwin on Apple silly cone, and x86_64 on Windows in Linux GLibC.

@kirby @romin
Nah, but I don't think we should be playing along with this "move fast and break things" and in the long run, I think it doesn't seem to work.
It was bad enough with libraries, but with programming languages it's just sickening, but ultimately it depends on governance — Go was prone to this from the get go (a pun, hehe), Python fell the victim of being used everywhere, little by little they have transitioned into catering to this crowd without even realising it.

@kirby @romin
But even Rust isn't as bad as that: having limited resources is understandable, closing the issues with "this is deprecated", just to not invest any effort into solving — isn't.
There are Zig and Nim — which are mostly out of corporate control and are fine languages.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml