Ach, well, a known method to create a nice discussion
sukhmel
joined 2 years ago
I just wanted to advice you against thinking that if there's something in all cases you've tried, there's something every time. When you put something in an optional and then unwrap, it's okay because you can see that the value is there, but even then there are usually better ways to express that. When you expect that since you've run the code thousands of times and it didn't break [in a way that you would notice, e.g. panic in another thread will only affect that thread] means that everything is fine, you may get weird bugs seemingly out of nowhere and will also need to test much more than strictly necessary.
Regarding the borrow checker, it has limitations and there are improvements that I hope will some day find way into upstream, but most of the time it may be better to change the code flow to allow borrow checker to help with bugs, instead of throwing it away completely. The same goes for unsafe, as in most cases it's better to not uphold invariants manually.
I second @hellofriend, I learnt C++ as practical courses in the University.
I could somewhat understand teaching Java as professional education (although it creates positive feedback loop that doesn't do much good), but not exclusively teaching Java as part of CS degree.
I want to add that getting a degree likely will create a social network and provide experience of working in a team. These days that may be replaced by contributing to open source and going to free conferences (although these seem rare 😢).
So even though I am pro getting at least one first year of CS degree (because it's the most useful one because teaches to think rather than specifics), I agree that it can be fully replaced by a well though out self-education, and from purely CS standpoint self-education might even be of a better quality.
But yeah, I must disclose that I am a European rubbing free education, and I studied in university not college. So my opinion may be influenced by that and I don't know if first year in college would've been as useful as it was in university.
I'm not familiar with slackware but why is specific kernel called generic, while generic one is not called generic? I'm puzzled
The main issue is that it tries to fix government trust issues with private actors trust issues. It's still trust issues
Maybe you and I just don't see that there is always an equivalent solution in rust macros even if it's going to be unconventional/unidiomatic use
Maybe so, but large part of where it will be impossible is reproducing bugs introduced by unsanitized macros in C /half joking
You may take a look yourself at the repo while I will try to describe it below.
I use nix-darwin on top of nix installation to manage most of system settings and build.
I am not quite sure now, but I think, I remember having to do xcode-select --install, can't quite remember if that was part of workaround for issues or part of normal process. Oh, and there were some discoverability issues with bin directories, I had to work around them by adding extraInit to zsh that includes binaries into PATH. This might be based on my poor skills in configuring everything, though.
Some of the packages needed are installed from nixpkgs, but some are installed by brew based on configuration.nix so these have to be upgraded in brew and don't get upgraded upon rebuild (it looks like the intended way would be to wipe them on each rebuild, but that would take longer)
I develop in Rust, so I also use rust-overlay instead of rustup to manage Rust and nixpkgs-cross-overlay for cross-platform builds. Build scripts also create docker containers descripted with nix in our case.
There were regular issues with Nix installation upon macOS updates, requiring me to either add back Nix to zshrc or completely reinstall it (the latter was not necessary, likely), but those seem to be fixed, as of now.
I think you will have less trouble managing reproducible machines with Nix, but I also think that it will require a bit more than just copying config and running Nix. There will also be issues of installing some software and packages locally, that will allow the developers to break builds across the machines when one have something locally that other doesn't, but this can be mitigated by processes and getting them acquainted with Nix, at least it did it with me 🌚
Nix is so good when it works, when I read such posts I feel strongly compelled to use it. I also use it and maintaining build and system with Nix, especially on macOS is sometimes huge pain, unfortunately
You're right, but:
- Rust goes out of the way to make macro safer and less error-prone, which means it will not be able to cover exactly the same especially in some fringe hacky cases
- I was commenting along the lines of automatically converting one into another, I find it will either be very difficult or outright impossible without human rewriting the macro from ground up (that is, if we know what problem it solved in the very beginning, otherwise it quickly would become guessing game)
I see now, that you were misunderstood in some parts.
This may be problematic for several reasons: it may be hard to reproduce, the more complicated the state, the harder; bug may rely on some race condition that may be much rarer in Debug because of speed difference; UB is notorious for causing things that should (seemingly) never happen, like returning from infinite loops, proving false statements true, and such, so it may be hard to understand what at all happened and why.
Regarding optimisations, it might still be better to try to profile the code (I will be honest, I don't do that until the moment when I can't go further without optimisation, and I haven't reached that with Rust) and see what are the real hot spots that require optimisations. I hope that someday you will be able to upgrade your machine, and hope that your game will be a good example of something that really runs anywhere