> I don’t feel like a consumer, but a janitor. I don’t want this.
I think it was Jorge Castro, the creator of Universal Blue, who called it the sysadmin culture. Most Linux distros are made by sysadmins for sysadmins, and you're expected to change and configure your system. I was a sysadmin myself for a long time. I used Slackware; switched from the 2.4 kernel to 2.6; tweaked CFLAGS on Gentoo; replaced SysV init with systemd; used PipeWire from the earliest versions - you name it, I did it.
Nowadays I use https://aeondesktop.github.io/ - an immutable system with Btrfs snapshots. Everything is installed from Flathub. The major roadblock is that much of the Linux world expects you to modify the system one way or another, so your mileage may vary. I replaced my printer because I did not wanted to install binary blobs from HP/Samsung.
> Perhaps I haven’t found «the right distro»
I’d look at immutable or image-based offerings, which aims at low or no maintenance: Aeon Desktop, Universal Blue, Endless OS. There are reviews on sites like LWN.net
https://github.com/mistweaverco/kulala.nvim is an another restish (it can do gRPC to) plugin for neovim. It is intended to be compatible with a Jetbrains as much as possible.
The Varlink IPC has been around for a while, but recently we started using it heavily in systemd. In this talk I'd like to explain what Varlink IPC is, and why we are now adopting it so heavily. And I also want to explain why I think that Varlink is a good candidate as IPC of choice for any Linux software, both low-level and higher-level. We'll compare it with D-Bus in particular, and highlight where it shines (and where it doesn't shine so much).
Just last week I've implemented an iterator for my C++ type and lol to your comment. It was fucking nightmare compared to how you (will) implement an iterator in Go.
I didn't study the reason why Go chose this way over others. I do know they've considered other ways of doing it and concluded this one is best, based on complex criteria.
People who make value judgements like this typically ignore those complex consideration, of which playing well with all the past Go design decisions is the most important.
Frankly, you didn't even bother to say which language does it better or provide a concrete example of the supposedly non-ugly alternative.
Iterators and generics go against the original goals of Go - simplicity and productivity. They complicated Go language specification too much without giving back significant benefits. Iterators and generics also encourage writing unnecessarily complicated code, which makes Go less pleasant to work with. I tried explaining this at https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...
Not obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.
Go provides generic types since v1.0 - maps, slices and channels. Go also provides generic functions and operators for working with these types - append, copy, clear, delete. This allows writing clear and efficient code.
There is close to zero practical need in user-defined generic types and generic functions. Go 1.18 opened Pandora box of unnecessary complexity of Go specification and Go type system because of generics. Users started writing overcomplicated generic code instead of writing simple code solving the given concrete task.
I'm not sure I can agree about generics. In many cases Go code is already fast enough, so other things come to play, especially type safety. Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed). Generics allow to write similar code much easier and safer.
Generics also allow to write some data structures that would be useful e.g. to speed up AST parsing: writing a custom allocator that would allocate a large chunk of structs of a certain type previously required to copy this code for each type of AST node, which is a nightmare.
> Prior to generics I often had to write some quite complicated (and buggy) reflection code to do something I wanted (e.g. allow to pass functions that take a struct and return a struct+err to the web URL handlers, which would then get auto-JSONed).
This sounds like a good application for Go interfaces (non-empty interfaces). The majority of generics Go code I've seen could be simplified by using non-empty interfaces without the need of generics.
Totally agree, as far as I know Rob Pike no longer develop Go, that's why. Came corporate people instead who think they do their work, asking community (who said that it should be asked?) what new cocojamba feature should be added (like js)
But what can we do against of this? This what I think:
- stuck to use Go 1.16
- fork Go 1.16 and continue develop lang from there
- learn OCaml...
- give up and consume what these people decide to add to lang next and everytime feel disgust
I use openSUSE Aeon (former MicroOS Desktop) for about a year. It is based on rolling Tumleweed and the system is stable. It updates on a background automatically.
If you are not looking for a fine tunning your system and expects stable (yet bleeding edge) base, which just works, I can recommend it.
The biggest thing is that the model pushes one to embrace usage of a distrobox/flatpak.
That looks interesting. I've been looking for a new OS to migrate away from Fedora Silverblue recently, since I pretty much no longer trust RH.
Would you happen to know if there are any major differences between distrobox and toolbox? Does distrobox also support running graphical apps with hardware acceleration and CUDA with the official Nvidia drivers? That's pretty much my biggest concern.
I think it was Jorge Castro, the creator of Universal Blue, who called it the sysadmin culture. Most Linux distros are made by sysadmins for sysadmins, and you're expected to change and configure your system. I was a sysadmin myself for a long time. I used Slackware; switched from the 2.4 kernel to 2.6; tweaked CFLAGS on Gentoo; replaced SysV init with systemd; used PipeWire from the earliest versions - you name it, I did it.
Nowadays I use https://aeondesktop.github.io/ - an immutable system with Btrfs snapshots. Everything is installed from Flathub. The major roadblock is that much of the Linux world expects you to modify the system one way or another, so your mileage may vary. I replaced my printer because I did not wanted to install binary blobs from HP/Samsung.
> Perhaps I haven’t found «the right distro»
I’d look at immutable or image-based offerings, which aims at low or no maintenance: Aeon Desktop, Universal Blue, Endless OS. There are reviews on sites like LWN.net
reply