To all the comments who expressed doubts on how this would work in practice: please read the FAQ, it answers a lot of questions and gives concrete examples.
1,047 karma · joined April 23, 2016
For servers that's even more relevant: I usually logged into my home raspberry pi every once in a while because I needed to fix something and I didn't even know what services were running on it!
With NixOS it's all comparatively simple: I switched my gaming PC to NixOS a few months ago and while I had to reconfigure some things like display settings, everything else just immediately worked exactly the same as on my laptop after installing.
I set up nix-darwin on my work macbook and share all my dev environment's configuration with my other computers. Now if I change some Helix settings on the macbook, I just have to commit them to my flake (which is just a git repo) and to get those changes on my desktop as well I just have to pull and rebuild.
If I want to install some new service on my home server I just open the relevant configuration.nix file in my config, enable an option, build it locally to check that everything's working, and push the changes to my server.
I don't ever feel the need to do a clean reinstall of my system because everything is already as clean as can be, and if I really wanted to it'd just be a matter of backing up /var and /home, putting the nixos installer on a usb stick, and running nixos-rebuild from there.
I think the benefits of NixOS come into play months down the line, when a problem comes up and all the specific knowledge about what you did with your setup has faded from memory, but all the operational knowledge on how to use Nix is still there.
Edit: I'd recommend trying out NixOS a server or VPS and installing Nix with home-manager on your usual distro for a while. That might give you a taste of what you can do with NixOS without having to fully commit to having it as your main OS and doing everything the "nix way".
That and the colon-colons (::), probably. Those can add a lot of noise.
https://dune.readthedocs.io/en/stable/reference/dune-project...
From what I could gather, the main factor that led the community to this point is Anduril's involvement in the community. Anduril is a miltech company and a contractor of the USA DoD. It looks like they use Nix extensively to train ML models and deploy combat drones, and several of their employees have very close ties to the Nix community; Jon Ringer (an Anduril employee, who is mentioned several times in this document) has recently been a release manager for three versions of NixOS, and was nominated to become a release manager for the upcoming 24.05 release.
Anduril wanted to sponsor NixCon last year because of this deep involvement in the community. I was not there to see it, but from what I've seen lately, many members of the community were not happy about it. The sponsorship was eventually pulled, because the on-site video team for the conference (https://c3voc.de/) threatened to pull out on their own over this sponsorship.
From my understanding there has been no official decision taken over Anduril's sponsorship since last year's debacle. Many people in the community think that this is because Eelco Dolstra, the creator and de-facto BDFL of Nix, is currently employed by Determinate Systems, which is rumored to have a contract with Anduril.
Edit: I just want to make it clear that I don't agree with what is presented in this document. I just wanted to present an overview of what, from my perspective, happened up to this point.
https://rumble.com/v4kuyhr-youtube-removes-video-and-locks-c...
Make of it what you will.
By my experience, younger programmers are more likely to want to do this. I fell into this trap myself with a similar library for TypeScript, and discovered the hard way that code written this way was much less readable and debuggable.
Less readable because you're essentially reimplementing variable assignment and control flow with lambdas and bespoke syntax that looks out of place. Less debuggable because the stack traces from these things blow up exponentially, and make it very hard to understand where an error came from.
So yeah, it's not satire, just misguided. If you have to use Python you're much better off sticking to the usual patterns and apply more static analysis on top rather than trying to reinvent the language this way.
That's actually a feature in Ur/Web, which is a (very niche) language explicitly built for making web servers. It's sort of a domain-specific language though, so maybe it doesn't count.
> making a function public when it should be private
Nothing's gonna stop a programming mistake like that, but in languages with capabilities[0] you can restrict some functions to only be called when you have certain capabilities, and these capabilities can only be made to be acquired after authenticating a user, for example.
Let's start with the first example about IEF: first of all, I think that the security advisory was mostly referring to web APIs that allow users without the necessary permissions to perform actions they shouldn't be able to. If you can already call Java APIs you already have access to the machine so it matters little what visibility the method was declared with. And as somebody else mentioned, the default visibility for Java methods is package-private.
Second example about the URL interception: first of all, you could have `match`ed on the result of `strip_prefix` instead of checking `starts_with` and then `unwrap`ping the result of the former. Second, why not use a URI parsing library? And third: that is not what checking the source of the URL means in this context! I'm assuming there's a way to tell what is the URL currently shown on the webview, and that you should check that before doing an RPC.
The Rust code example shown in the post is functionally identical to the Java version. Also, `&str` doesn't mean the string size is known at compile time, the bounds checks are all performed at runtime.
Third example about path traversal: again, that's functionally the same code as the Java version. What is missing in both is a check that the path is relative to a well-known list of paths and doesn't contain any `..` which could possibly lead to, well, a path traversal vulnerability!
I appreciate the effort that went into the post and I agree that Rust is still better than many other languages out there (because of its API design in many important areas), but man, this ain't it.
The compiler, and its error messages, are somewhat inscrutable if you don't fully understand some of the more advanced features of the language, and some stuff I felt I was honestly not smart enough to figure out after a while. There was a point for me where most of it clicked together, but it took a long while to get there.
Ultimately what made me stop using it after that project was the features of the server itself. You can compile it to a self-contained HTTP server, but some issues that I don't remember right now made it unfit to use outside of development, so you're left with CGI and FastCGI. Like another comment mentioned, there's some stuff you can only do using the C/JS FFI, and Ur/Web's transactional nature sometimes makes it hard to tie these additions into the rest of the language. There's also some things (such as submitting a form with multiple files, IIRC) that are not supported by the compiler, and even after submitting a patch to fix some issues with the SQLite backend I didn't feel comfortable enough with the big pile of terse SML to patch those in.
I definitely had to play with powertop a bit and remove some programs that consumed a lot of battery (for example, the blueman tray applet had to go). I'd recommend setting powerManagement.enable = true and powerManagement.powertop.enable = true, and letting powertop run in the background while on battery for a few hours to identify the worst offenders.
This is my configuration: https://kirarin.hootr.club/git/steinuil/flakes/src/branch/ma...
The only time I find I have to "fight the compiler" is when I write concurrent code, and you can sidestep a lot of issues by starting with immutable data and message passing through channels as a primitive. It's a style you have to get used to, but once you build up a mental library of patterns you can reasonably be as fast in Rust as you are in Python.
Right before the application form they say "We are proud to foster a workplace free from discrimination." Not everybody had the luck to be able to perform at their best in high school, so that looks like a pretty big discriminant right away! And for most people applying to that kind of job that was more than 10 years ago, so I fail to see how it is relevant to a job application.
I used to use vim but lately I switched to Helix, which is basically vim but with all the good features and plugins built into it and without a configuration/extension language. Almost all of the features are easily discoverable by just pressing spacebar, and the rest by browsing the (small) documentation, and I can think of a way to do all the things Bram talks about from within Helix, often better (because it's relying on the language server).
Still, the main point about learning your tools by detecting inefficiencies and searching for a better way is always valid, and I'm sure that all these things Vim was already doing at the time helped pave the way for modern editors. RIP.
I'm not particularly attached to order of definitions within a module, but I definitely like the linear ordering of modules. Without the compiler enforcing that you always end up with cross dependencies between modules, which I think makes it much harder for humans to read the code.
I've had similar conversations about variable shadowing. I find it natural and it bothers me when I can't do it, especially in functional languages, but I have a friend who really doesn't like it and finds it jarring. I think his dislike stems from having learned Erlang before any language that has shadowing, because in Erlang when you reuse a variable name it'll be checking for equality with the value you're "assigning" it to.
Again, I'm not a shell script person and I never liked sh/bash so I don't have any 1000 line shell scripts that I'll be porting over to nu, and if I need to do something that would take more than a couple lines of code I'll switch to a proper programming language. I definitely wouldn't ship nushell scripts in production or for anything that isn't my local configuration because the commands and the language itself are far from having a stable API.
I mostly agree with this, but the rest of your comment reads to me as "everybody else does it so it's fine", which is exactly the mindset that leads to this conversation not being had. A sensationalist story might lean the narrative one way and might be "out of touch with reality" but it's a much better starting point than nothing.