cherryblossom00

‘No server is currently available to service your request. Sorry about that. Please try refreshing and contact us if the problem persists.’

I use VPNs to access region-restricted content (mostly to pretend I’m in the USA) and not for the privacy aspects, so VPNs aren’t really a ‘scam’.

I don't understand what's wrong with the Nix language. Sure, the space-delimited lists can get a little annoying, but other than that it's minimalistic enough to use a configuration language but complex enough to do more complicated things like overriding derivations. Maybe it's because I learnt Haskell before Nix so the syntax is very familiar to me, whereas I see how it could be a learning curve for other users.

What I find the most annoying is the lack of documentation of some of the nixpkgs functions. Some of the functions provided by import <nixpkgs> {}.lib appear to be the same as the ones builtin to the Nix language and there doesn't seem to be any clear guidance on when to use which version. I've also had to look at the source code to find out the difference between writeTextFile, writeText, writeTextDir, writeScript, and writeScriptBin. [The docs][1] explain writeTextFile, but the only documentation for the rest is ‘Many more commands wrap writeTextFile including writeText, writeTextDir, writeScript, and writeScriptBin. These are convenience functions over writeTextFile.’.

Additionally, it's a bit frustrating for me how all the documentation for nixpkgs — the lib functions, how to make a derivation, specific details for building packages in certain languages, how to contribute to nixpkgs, overriding packages/overlays etc — are in [one gigantic web page][2] that's quite slow to load and even slower to search for things in.

[1]: https://nixos.org/manual/nixpkgs/stable/#trivial-builder-wri...

[2]: https://nixos.org/manual/nixpkgs/stable/

(copied from my Lobsters comment https://lobste.rs/s/psfsfo/curse_nixos#c_y83hvy)

More discussion on r/rust: https://www.reddit.com/r/rust/comments/s9az4y/you_canturn_of...

This reminds me of Swift/Xcode's documentation comments:

  /// Does something.
  ///
  /// - Parameters:
  ///   - bar: A description for bar.
  ///   - baz: A description for baz.
  ///
  /// - Returns: Something fancy.
  /// - Throws: Throws `SomeErrorType` if `bar` is invalid.
  func foo(bar: String, baz: Int) throws -> Bool { /* ... */ }

I find string enums useful when I want nominal typing. However, I do think that it is a little confusing when most of the type system is structural, except for string enums. What complicates things further is that any number can be assigned to a number enum without casting, which I understand is so enums can represent bitfields (e.g. so Permissions.Read | Permissions.Write is still of type Permissions instead of number), but I wish numeric enums worked the same as string enums and doing bitwise operations on these enums would return the enum type and not a type-erased `number`.

I mostly agree with the rest of the article’s recommendations, but don’t fully agree with their reasoning.

- Yes, namespaces should be avoided, but not because they generate extra code. Namespaces are not recommended anymore and modules (actual JS modules not TS’ `module`) is the recommended approach now.

- Yep, private fields are better for ensuring a field is truly private.

- I think decorators are fine to use if you’re prepared for your code to potentially break in the future if they’re standardised. Developers use new/unstable features all the time (e.g. stage 0/1 JS proposals via Babel, nightly Rust toolchain). And I don’t believe the lack of standardisation of decorators should be a factor in deciding whether to use a library that requires these.