philm

Yes, if you've found your distro, I also don't see a point in switching, there's more important stuff than learning how to install and setup your distro everytime you hop. I only hopped, when I wanted to have a clean install because my previous was kinda broken (dirty state over time), and/or wanted to have more control, or try a different desktop-environment. I have now found a distro (NixOS) where I can have all of that at the same time (so no point in hopping anymore for me too).

I have hopped rather rarely. I think my journey started with Debian -> (all kinds of flavors of) Ubuntu -> Arch -> NixOS.

Maybe I missed a few (started with linux at probably ~2005). I've stayed on each of these for a few years, I think I switched between Ubuntu flavors a little bit more frequently. Stayed on Arch the longest for ~7 years. And I think I have basically settled now since 3 1/2 years on NixOS without plan to hop any further distros (unless there comes a distro comparable to NixOS that has less quirks and is generally nicer to use (e.g. tooling, strong, strict static typing etc.)).

NixOS is quite different than other distros (which IMO are all very similar) but does package-management+system-configuration basically how it should be done (in hindsight). It's a rather steep learning curve in the beginning, but it only gets better over time, since your system continuously improves, compared to different distros that accumulate dirty state over time and in one way or the other break after some time. This was often the reason why I hopped on a different distro, since I wanted a clean fresh install, which I get with something like Impermanence+tmpfs on root after each reboot.

Interesting.

I have settled with NixOS+home-manager. It got quite a bit better over the last 3 1/2 years.

After learning and understanding all the quirks of NixOS, I've got a super nicely configured system, that just gets better over time, not comparable to a(ny) different distro I know of (they kinda degrade after time IME). I really like the way I can compose all my configuration via functions in modules and reuse relevant stuff on different servers and desktops I use (via flakes), always with the same up-to-date configuration.

$0.7k annually? Is it anyhow possible to live with that low salary in India? I can't even live a month with that here, even if I don't buy anything but the cheapest food and live in the smallest apartments here...

For basic usage (similar as vimtutor): hx --tutor

For the other stuff, as already said, the docs should be rather thorough, the wiki may also be a starting point

I think the crux of good software design, is having a good feeling/intuition when to abstract and compose, and when to "inline" code as it's used only once anyway (in which case "linear code" is IMHO often the better choice, since you're staying close to the logic all the time without having to jump between files etc.).

I agree the examples of the google blog are bad, they don't really show how to compose code nicely and in a logical way (whether that would be more data-oriented, imperative or OOP).

I guess you have to almost thank John Riccitiello for that, haha

Yeah it's more of a disaster of choosing Unity for new stuff.

While it was "almost" a no-brainer to use Unity in the past for student projects, this change among other negative stuff/press that happened with Unity etc. in the younger past slowly presses you towards e.g. Godot, since it can do as much as Unity can (at least in the beginning, as you're not hitting the limits of it) and is more in line with the academic way of thinking (not pressing charges for pretty much everything that is possible to press charges for...)

As I have used Unity extensively in the past, the amount of progress is dwarved by e.g. Unreal. It has not really made significant progress over the last (lets say) ~5 years, compared to Godot and Unreal (and soon Bevy when they have an editor/UI for better workflow for artists etc.).

So I don't see a long-term future for Unity, most of the "progress" of Unity was buying in technology that doesn't really feel organic in the Unity ecosystem (not just buying in, e.g. the ECS of Unity doesn't feel close as ergonomic compared to Bevys).

I think this slow and scattered progress will be the slow death sentence for Unity as other engines with less enshitification over the past will catch up, and don't have such a greedy dumbfu** of a CEO...

Yes

It could definitely use integration with a linter so it doesn’t generate subtle bugs around generative naming mismatching actual methods/variables, but it’s become remarkably good, particularly in the past few weeks.

Maybe I should try it again, I doubt thought that it really helps me, I'm a fast typer, and I don't like to be interrupted by something wrong all the time (or not really useful) when I have a creative phase (a good LSP like rust-analyzer seems to be a sweet spot I think). And something like copilot seems to just confuse me all the time, either by showing plain wrong stuff, or something like: what does it want? ahh makes sense -> why this way, that way is better (then writing instead how I would've done it), so I'll just skip that part for more complex stuff at least.

But it would be interesting how it may look like with code that's a little bit less exotic/living on the edge of the language. Like typical frontend or backend stuff.

In what context are you using it, that it provides good results?

I would actually encourage it to be extremely verbose with comments

Yeah I don't know, I'm not writing the code to feed it to an LLM, I like to write it for humans, with good function doc (for humans), I hope that an LLM is smart enough at some day to get the context. And that may be soon enough, but til then, I don't see a real benefit of LLMs for code (other than (imprecise) boilerplate generators).

Yeah my thinking as well.

Addtionally, why I think other system language competitors like Zig or Nim aren't succeeding long-term, is because of fast growth and already big ecosystem of Rust. Zig may be better though for some use-cases (when you want to avoid all the mental overhead, and the application stays simple).

On another look, though, we have to keep in mind, though that this is code-golf, so in no way representative for actual code-bases.