zelly

Seems cool but mosh already exists

Shortages lead to gluts. Get ready.

I remember celebrating when it died but looking back it wasn’t so bad. At least from a dev perspective, working with a batteries-included sdk from a single vendor is a lot nicer than this node_modules cancer.

LUKS doesn’t have this problem.

I’ve said it before and I’ll say it again, it’s a matter of time before Windows runs on the Linux kernel. It’ll just be this big monoculture like Chromium with browsers. There really isn’t any reason to duplicate all this effort in maintaining an OS. Might as well have the whole world pitch in on one strong project.

You’re joking right

Dead wrong. GPT4 is scary good. I think it will replace frontend web dev.

You’re being rational and using logic. Unfortunately that’s not how markets and valuations work.

$10M to host a listing of pdfs. lol let me do it.

This is the kind of thing you can only trust the compiler to do. And we already have goroutines.

No. Please no.

I wanted to make something like this, but using Bluetooth LE. Then I looked at the Bluetooth spec and implementations realized why Bluetooth applications are so unreliable (other than Apple device to Apple device). It’s really hard. Plus every OS has their own incompatible API, with some parts missing or inaccessible for some reason.

The practical solution to “share files in physical proximity” ends up being just use Apple everything.

No. It’s dead, Jim. (That said, it’s better than Python by miles, but it suffers from the same curse as Lisp.)

So when do we get the worldwide 0-day caused by a malicious crates package?

It seems people still have not grasped free software. You could have full control over your computing experience, limited only by your abilities.

AI in those days was completely academic, so they used the in vogue academic language. It was a tribal thing—the same way HN gets excited when they see Rust. AI in the 1980s was centered around MIT, where everyone knew Lisp (actually Scheme) from the famous SICP course.

Correct. The best use case for Web Components is to ship a bloat-free, reusable widget that doesn't care whether a consumer uses it with React, Vue, vanilla JS, Angular, etc.

If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.

RxJS aka the reason so many websites take 100MB of memory nowadays

Don't use it

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like <my-component my-attribute="[1,2,3]"/>). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't scale.

W3C standardized Web Components before React existed and took off, unfortunately. I expect the next standard to just be React itself (or a barebones version that the library can build on top of), patent licenses permitting. I'm pretty sure as a C++ precompile, it would be unstoppable and end the debate for good.

This is neat but for convenience not performance. The bottleneck is in the kernel more than anything else. Probably it has the same latency as nginx, modulo safety checks. I would also recommend uWebSockets for an easy-to-embed web server.

Nah Rust evangelism is pretty organic. I remember it having a cult 6 years ago too, before any of these companies got involved.

C++ is pretty much the opposite of moving fast and breaking things. It takes like 10+ years, lots of academic papers and debates, lots of peer review, to get a feature into the ISO standard. The reason it's so bloated is just because of age.

Rust is just a single implementation that's CI'ed with nightly releases.

Solana has done more for Rust adoption than either Amazon or Mozilla

Nah, they are by far the most honest. I would rather trust shitmex than the CME.

No one cares about the "owner" of the corporation, what matters is the registered agent. There are law firms to handle all this for you.

excellent post, sir, but shhhhh

> I don't have millions of dollars in my pocket

You need to work on your alpha then, that should be your priority

Trying to do that is a massive waste of time. It's legitimately easier to maintain separate codebases for each of the different platforms. The code that doesn't need to change can be a library. Or you use some super high level abstraction like Unity, Qt, JVM, Electron, React Native. Portability != cross-platform.

Bazel does the opposite of rebuild-the-world. That's more of a CMake thing (rm -rf build && mkdir build && cd build && cmake ..). Bazel won't even run tests if the code the tests depend on have not changed. A lot of thought went into Bazel. It caches everything it possibly can.

> I'm already getting flak from Linux distros maintainers because I use some vendored header-only libraries and not system ones so I don't see how that is even supposed to work.

That's where you use autotools. It has been around long enough that every package manager knows how to deal with it. For most C/C++ programs, autotools is all you need. You should learn it because it's not going away.

"the IDE" (like VS project files) is definitely not cross-platform (although it can be), but not everything needs to be cross platform. For game devs building on DirectX, for example, it's completely pointless to support other platforms when the runtime depends on a single platform.

CMake is legitimately the worst software I've ever used.

cargo > Bazel > autotools > "the IDE" > handwritten Makefiles >>>>>> build.sh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CMake