Comments URL: https://news.ycombinator.com/item?id=47699086

Points: 65

# Comments: 74

- Excellent for short-lived programs that transform input A to output B

- Clunky for long-lived programs that maintain large complex object graphs

- Really impressive ecosystem

- Toxic community

https://x.com/awesomekling/status/1822241531501162806

Are there any good Linux distros left with 32-bit x86 support? Do I have to switch to NetBSD?

Oklab is perceptually uniform and addresses issues such as unexpected hue and lightness changes in blue colors present in the CIELAB color space. https://en.wikipedia.org/wiki/Oklab_color_space

Oklab is used in CSS because it creates smoother gradients and better gamut mapping of out-of-gamut colors than Lab. Here's a picture how Oklch (on the left) creates smoother gamut mapping than CIE Lch (on the right) ("Explore OKLab gamut mapping in oklch"): https://github.com/w3c/csswg-drafts/issues/9449#issuecomment...

Generally, I try to avoid buying anything with rubber. It is usually the first part that goes bad. Either it gets sticky and starts melting or it gets hard and dry and breaks up. Also, I avoid using rubber bands. They usually end up damaging objects they hold together.

Here's a good page about conservation of rubbers and plastics for those who like to preserve their vintage stuff for a long time. https://www.canada.ca/en/conservation-institute/services/con...

"An error occurred whilst preparing device for development -- Failed to prepare the device for development. Domain: com.apple.dtdevicekit Code: 806 Recovery Suggestion: Please unlock and reconnect the device. The device is locked. Domain: com.apple.dt.MobileDeviceErrorDomain"

But how can the caller know what is "a truly invalid input"? The article has an example: "we unfortunately cannot rely on panic annotations in API documentation to determine a priori whether some Rust code is no-panic or not."

It means that calling a function is like a lottery: some input values may panic and some may not panic. The only way to ensure that it doesn't panic is to test it with all possible input values, but that is impossible for complex functions.

It would be better to always return an error and let the caller decide how to handle it. Many Rust libraries have a policy that if the library panics, then it is a bug in the library. It's sad that the Rust standard library doesn't take the same approach. For println!(), it would mean returning an error instead of panicking.

I have been following the Rust Boa project, but I think that it isn't production ready, yet. https://github.com/boa-dev/boa

https://phys.org/news/2023-10-china-tiny-farm-moon.html

Shake was acquired in 2002 and killed 7 years later.

Raspberry Pi RP2350 already ships with ARM and RISC-V cores. https://www.raspberrypi.com/products/rp2350/

It seems that the RISC-V cores don't take much space on the chip: https://news.ycombinator.com/item?id=41192341

Of course, microcontrollers are a different from mobile CPUs, but it's doable.