dthul

Telling someone they got fired for performance reasons when that's not actually true is outright evil. (Of course we don't know for certain whether that's what happened here, but it sure does look like it)

I was thinking that the "power extraction" might attenuate the signal too much, and it would probably lower the power output since you need to modulate the light to transmit data, instead of having it on full brightness all the time. But maybe it would work for certain applications!

I wonder if you could send power at one wavelength, and data at another wavelength, over the same fibre.

That's trying to put words in my mouth. We were talking about creative expression being taken away by AI, and I argued that artists can still retain creative expression, and that these AI tools make it possible for more people to express themselves creatively. I never said that artists should have no reason to feel unhappy about that. That's criticising a position I didn't argue.

> which you would know if you ever tried to draw anything

I know exactly how hard it is to draw anything because I tried a bunch of times, and failed. I for one am happy that I can now express my creative ideas, which I couldn't do before due to missing talent / practice.

That sounds like a very Luddite view. Why wouldn't artists be able to use AI selectively to automate "boring" tasks (such as filling the sky of an image with clouds) while still retaining overall artistic control?

I suppose the vendor could sell a home server device, which runs some kind of Tailscale-like technology to make it available from the internet, and the app talks to that locally hosted server.

My teacher made me do a full force brake during my training. It was more intense than I had anticipated, and my teacher forgot that he still had his sunglasses on his head, which promptly smashed into the windshield :D

Defining "normal" code as "not having UB" is quite disingenuous though, isn't it? Iterating over a vector while adding elements for example looks normal, but isn't generally safe, unless you know to pre-allocate enough memory.

I work with both, having started with C++ about 17 years ago, and agree that Rust feels like a relatively simple language compared to C++. Rust might feel harder to learn initially because the borrow checker won't let you compile certain programs, but once you are over this initial hump, the rest is quite straightforward.

Quite a few parts of Servo were actually integrated into Firefox/Gecko (such as Stylo).

Ever since I learned of sum types, they have ruined my enjoyment of programming languages which don't have them. I sorely miss them in C++ for example (and std::variant is not a worthy alternative). I don't understand why any new language wouldn't have them.

That depends on the type you use to represent errors. A more "fancy" error type will allow you to add context / backtraces / whatever you want, while a simpler error type, for example just an error code, does not. (The error type is the E in Result<T, E>).

There is an interesting approach to this in Rust: if a potentially breaking change (e.g. a soundness fix) is being proposed, they usually test it against all publicly available Rust code.