2
points
assbuttbuttass
Joined 1,314 karma
https://news.ycombinator.com/item?id=37272485
- > To "force" someone to develop on a Chromebook is like giving someone a bicycle to become a race car driver.
Lol, I use a Chromebook for development at work
- One cool thing about J (or any APL language) is that LLMs absolutely cannot write J code, so the whole thing feels like a breath of fresh air from the usual LLM slop
- Very interesting to see the ML influences like ~ for unary minus, unscoped enums, mut on specific struct fields...
It seems like over time, a lot of that was replaced with C++-style syntax and semantics. Presumably to make the language appeal more to C++ devs
- Is serde maintained by the Rust team? I thought it was basically a one-man show owned by dtolnay
- I share the same sentiment about the HN community, but there are still a lot of interesting articles posted here that are fun to read
- My website was down too, because a tree fell on my power line
- In TFA they mentioned they preallocate all the memory up front
- Yes, that fragment in particular screams LLM to me. It's the exact kind of meaningless yet overly dramatic slop that LLMs love
- I love standard ml (I'm currently writing a compiler for it), but it's far from perfect. There are weird special cases in the language definition like the ad-hoc overloading between int and real, or the annoying value restriction. Records also feel half-baked, with no support for updating fields or for partially-specified records where the full set of fields is not known
- Not in Go
- I'm sure all these layers are good engineering and provide meaningful safety guarantees, but it sure makes the code harder to understand if you want to see how things are implemented.
Another example, I was trying to see how i64::isqrt is implemented, but first you have to wade through layers of macros
- Use find?
find -exec sd before after \; - I'm not sure where you got that XDG_DATA_HOME has to be read-only, I couldn't find anything like that
> $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
And really, the difference between XDG_DATA_HOME and XDG_CONFIG_HOME is subjective anyway, each application will have its own requirements, so I'm not convinced it's even possible to define these completely precisely.
Personally, I would pick between XDG_DATA_HOME vs XDG_CONFIG_HOME based on whether the application manages the files, or whether the user is expected to manage the files themself. This isn't based on any wording in the standard, but just a pattern I've commonly seen
- The definition is perfectly consistent. append is in-place if there's enough capacity (and the programmer can check this directly with cap() if they want), and otherwise it allocates a new backing array.
- string is just an immutable []byte. It's actually one of my favorite things about Go that strings can contain invalid utf-8, so you don't end up with the Rust mess of String vs OSString vs PathBuf vs Vec<u8>. It's all just string
https://cloud.google.com/blog/products/databases/announcing-...