alexvitkov

WSL is not Windows. Unless you can work entirely in WSL (and if I could I'd just use Linux) having to juggle fake filesystems, incompatible symlinks, two PATHs, three shells is a bit much.

I'll take a rust tmux if it runs on Windows. I'm currently kind of stuck on Windows and I didn't realize how much tmux means to me until Bill took it away :(

The react snippet is one uppercase letter away from being vanilla js, it's definitely less magic.

I've found the Cursor autocomplete to be nice, but I've learned to only accept a completion if it's byte for byte what I would've written. With the context of surrounding code it guesses that often enough to be worth the money for me.

The chatbot portion of the software is useless.

  A: ChatGPT exists
  B: Entry-level jobs are down

Apply some propositional logic or something:

  A&B => A->B

Therefore ChatGPT took the entry level jobs.

This is not even worth thinking about, just type " = {}" on every struct/class member and every variable declaration, and forget about all this nonsense.

Watching a guy type at 30 WPM in a chatbox reminds me of those old YouTube tutorials where some dude is typing into into a notepad window, and showing you how to make a shortcut to "shutdown -s -t 0" on your school computer and give it the Internet Explorer icon. It's only missing Linkin Park blasting in the background.

If you're debugging from a crash dump you probably have a large, real world program, that actual people have reviewed, deemed correct and released in the wild.

Current LLMs can't produce a sane program over 500 lines, the idea that they can understand a correct looking program several orders of magnitude larger, well enough to diagnose and fix a subtle issue that the people who wrote the it missed, is absurd.

This is a very bold statement, you should consider substantiating it at least a little, maybe give just one example on what those absurdities collee students have to endure are, that prove they're good corporate drones?

From what I remember it was 4 years of learning stuff I signed up to learn, occasionally being quizzed on said stuff, and then they gave me a paper that claims I know the stuff.

Maybe people would forget about them less often if they were allowed to talk about them

The Windows API uses this scheme for one of its 50 string types [1].

I"m not very fond of this design as it's easy to pass a "normal" C string, which compiles because BSTR is just a typedef to it.

You can allocate the exact same data structure, but store a pointer to the size prefix, instead of the first byte - you avoid that issue, and can still pass the data field to anything expecting a zero-terminated string:

  struct WeirdString { int size; char data[0]; };
  struct WeirdString* ws = ...;
  fopen(ws->data);

[1] BSTR - https://learn.microsoft.com/en-us/previous-versions/windows/...

C++ for one - it has atomics with well defined memory barriers, and guarentees for what happens around them.

The real answer is obviously Assembly - pick a random instruction from any random modern CPU and I'd wager there's a 95% chance it's something you can't express in C at all. If the goal is to model hardware (it's not), it's doing a terrible job.

None, but that'a not what computers are. C assumes that in a few places, e.g. variadic functions, and those are the worst parts of the language.

Please just use a pointer. Use metaprogramming when it makes sense, not to obfuscate something that was figured out 60 years ago.

Too much typing, and Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying - you have to type out the whole http://mything.internal.

This can be addressed by hijacking an existing TLD for private use, e.g. mything.bb :^)

Computers do what you tell them to, not what you want them to. This is naturally infuriating, as when a computer doesn't do what you want, it means you've failed to express your vague idea in concrete terms.

LLMs in the most general case do neither what you tell them, nor what you want them to. This, surprisingly, can be less infuriating, as now it feels like you have another actor to blame - even though an LLM is still mostly deterministic, and you can get a pretty good idea of what quality of response you can expect for a given prompt.

You don't have to replicate all the insanity that goes on in a modern OS.

Lock threads to a particular core on creation, every core does a Round-robin over all threads. You're 50% there.

Have the core detect congestion, and move yeet threads to another random core when it's congested. You're 75% there.

Use three lists for priorities instead of one. You're 90% there.

Make up for the other 10% with sane design in other subsystems.

> This is very much a win-win situation, because the alternative is that every manufacturer has their own proprietary system.

No, it's a lose-lose situation. If we have 100 different mobile OS's it's a matter of time until a "good one" appears, and we get some sort of innovation in the space - be it from a technical perspective, from an UX perspective, or whatever.

Now we're all stuck with Android, where manufacturers can't really do anything interesting with their phones, users get an incredibly bloated, technically incompetent system, and all parties have to abide by Google's every whim.

This has nothing to do with ipv4/ipv6 and the "ridiculous hacks" we do to keep ipv4 going. Those work just fine. This is a cultural problem, not a technological one.

There's 3 boolean modifiers and they're used all the time, just learn the shortcuts.

If LLM chatbots are making you vastly more productive in a field, you are in the bottom 20% of that field.

They're still useful tools for exploring new disciplines, but if you're say a programmer and you think ChatGPT or DeepSeek is good at programming, that's a good sign you need to start improving.

Keyboard shortcuts are a feature for advanced users, not pictures.

  > It's an extremely successful model organizationally and technically.

There are technically impressive open source projects - e.g. Linux, and most of them have people paid to work on them full time. Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time. Hobbyists solve problems they find interesting, and often ignore a lot of the "gruntwork" required to make a technically sound package.

  > Anyway, are we short of programming jobs?

Yes. Especially good ones.

  > Efficiencies create new, higher-value possibilities than, for example, JPEG decoders.

I don't see it - a large portion of programming jobs have devolved to gluing together a bunch of open-source libraries, doing the boring gruntwork to actually make them work, and dealing with the inevitable hell, caused by using 500 components that were never designed to work together.

Your second paragraph is explaining perfectly why open source doesn't work and how its economics don't add up.

I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg. Nobody is ever get paid to write a new kernel as everyone can just use Linux. Very few people are going to get paid to work on a new database as you can just use Postgres...

Once there's a good enough open source solution in a field, in the long run it will out-compete commercial offerings, even it's overall a worse package, as it's some guy's free time project and is created on a $0 budget.

Programmers work for free, end users get a worse product, companies make trillions.

Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".

Probably the best argument for tabs I've seen so far.

I don't buy the static linking part - we already generate a single function in the linked binary that calls all static constructors from all translation units, the same thing can be done for TLS constructors (what I called construct_thread_locals() in parent), and force the user to call that manually on thread creation, or call it as part of std::thread.

Dynamic linking is a whole other beast, and maybe for thread_local's in a DLL it's acceptable (or the only possible way?) to do construct them lazily - if you're using DLL+TLS+global constructors you deserve the pain.

Creating a thread is already very expensive, in a sane program your ten TLS constructors shouldn't come even close to the amount of bookkeeping that the kernel has to do to spin up a new thread.

Also creating a thread, doing little work and exiting immediately is a bad use of threads -- I don't think that everyone using thread_local should be punished to better support poorly written programs. Most threads are long-running and most programs spin up a bunch of worker threads at initialization time, I'd argue variable access time is way more important than thread startup time.

Why aren't thread-local constructors called when the thread is created rather than doing a test on every variable access? Perhaps they wanted to have the OS-native pthread_create/CreateThread "work out of the box" without having to manually call `construct_thread_locals()` or whatever? That would be an insane tradeoff, especially considering `construct_thread_locals()` can be called automatically when using std::thread.

because you don't want your server's ip to change.

If your goal is to replace one unreliable source of information (Google first page) with another, sure - we may be there. I'd argue the GPT 3.5 already outperformed Google for a significant number of queries. The only difference between then and now is that now the context window is large enough that we can afford to paste into the prompt what we hope are a few relevant files.

Yet what's essentially "cat [62 random files we googled] > prompt.txt" is now being confidently presented with academic language as "62 sources". This rubs me the wrong way. Maybe this time the new AI really is so much better than the old AI that it justifies using that sort of language, but I've seen this pattern enough times that I can be confident that's not the case.