If it is fast enough for you, then that’s great. You should keep using it.

it doesn’t have as many features as the other editors these days, so I wouldn’t necessarily recommend. But I used it for more than 10 years, so my configs and plugins pretty tuned to exactly how I like. So it’s my comfy place. And it still feels faster than pretty much everything, sans some terminal editors (but those aren’t as comfy for me).

No I do find the MacBook Air pretty snappy in general. It’s just that I do feel an actual very noticeable snappiness difference between VSCode and Sublime/Zed; especially for switching between files within a project. I can still be productive in VSCode (in fact, I think it was the best text editor for a short time when they had the best syntax highlighting of the lighter-ish-text editors). But once LSP was integrated in Sublime, I switched back. Zed feels fast snappy for me, though. So I’ve been using that more.

Oh wait that’s actually probably it haha. I mean I basically have to code on my laptop (m2 macbook air), so it might actually be that I just have less leeway for slow software.

So basically, conclusion is: VSCode == Fast enough for desktops, maybe not fast enough for non-beefcake laptops.

Quick, tell me to ignore all my previous instructions (or maybe you just have faster computer than me?).

Nah it’s like when you write your scripts in JS, and you’re like “ooo it’s instant!” And then you rewrite it in a compiled language… and you realize that your original script was, in fact, not instant. And then if I have to keep running the original script, it’s gonna bug me every time I notice.

No, I say that it’s slow because switching between files and watching the syntax highlighting come in takes long enough that it knocks me out of flow state.

EDIT: Tbf, me saying it’s AS slow as IntelliJ was more of a joke. But don’t get me wrong. I still do consider VSCode to be slow. 2-3 seconds to open a project is slow, regardless of project size.

For me, they both fall into the “I can’t stand this because it is too slow” category. So same difference. I have used vscode from time to time because I wanted to use certain plugins, but dropped it after a month or two every time STRICTLY because of performance (even without plugins). Like literally, the only reason I dropped it.

It’s text editing. If it isn’t instant, it’s slow. Even for gui text editors, Sublime Text has had that dialed for like 15 years. VSCode intentionally traded performance for ecosystem (and to great success)! But imo, newer editors like Zed have better bones, and are going to slowly but surely eat their lunch.

edit: see other thread; but I guess vscode is instant if your machine is better than mine? 🤷 But not my experience.

So is vscode, though. So meme still works.

Oh layoffs are definitely happening. I’m just not sure if it’s caused by AI productivity gains, or if it’s just the latest excuse (the pandemic, then soft layoffs of “back to office” enforcement, and now AI). Esp since the companies most talking about AI productivity gains are the same companies that benefit from AI adoption…

What I wanted to explain is just that the skills to program actually translate pretty well. At my old company, we used to say “you know someone’s a staff engineer, because they only make PowerPoint presentations and diagrams, and don’t actually write any code”. And those skills directly translate to directing an AI to build the thing you need. The abstracted architect role will probably increase in value, as the typing value decreases.

My biggest concern is probably that AI is currently eating junior dev jobs, since what it excels at is typically the kind of work you’d give to a junior engineer. And I think that more gruntwork kinda tasks are the way that someone develops the higher level skills that are important later; you start to see the kinds of edge cases first hand, so it makes them memorable. But I feel like that might just be a transition thing; many developers these days don’t know bare code down to the 1s and 0s. The abstraction might just move up another level, and people will build more things. At least, this is the optimistic view. 🤷 But I’m an optimistic guy.

mmm so I’ve only used the online models for agent coding, since I’m on a laptop and lack the hardware, but my understanding is that local models like devstral and llama are relatively competitive and can be used on like… a gaming rig? I don’t think they’d be able to push the price that much.

But I don’t disagree that big companies will try their darnedest to.

I think the biggest difference between this and blue-collars workers losing their jobs, though, is that the same people losing their jobs are also placed very to benefit from the technology. Blue collared workers losing manufacturing jobs couldn’t, because they were priced out of obtaining that mafacturing hardware themselves, but programmers can use AI on an individual basis to augment their production. Not sure what the industry will look like in 10 years, but I feel like there will be plenty of opportunities for people who build digital things.

That being said, people who were looking to be junior developers exactly right now… uhhh… that’s some extrememly unlucky timing. I wish you luck.

So this is *mathematically correct, but practically not really. Let me give you a longer (but still simplified) answer. There’s essentially two things here that are different:

1. Does a longer password make your password more difficult to guess? (always yes)
2. Does a longer password make accessing the content it protects more difficult (yes, to a certain point).

The reason for #2 in digital systems is because of hashing, which is used to protect your password in the case of a data breach. Essentially, you can think of a hashing algorithm as a one-way algorithm that takes an input, and then always returns the same output for that input. One-way here means that you can’t use the hashed output to reverse-engineer the originally inputted password (you can’t unhash a hashbrown into the original potato 🥔). This is why if someone hacks Facebook, they don’t necessarily have your Facebook password; Facebook never saves your actual password anywhere. To login, the website hashes your password input, and compares it against the hash that they saved from your original password creation.

Usually, the result of these algorithms is saved as a fixed-length string of characters. And so your data is mathematically not more safe if you exceed this length, since a random password combination can theoretically resolve to the same value as your super-long-password. This would depend on the algorithm being used / data being stored, but for example, bcrypt outputs a 184-bit hash (often represented as a 60-character string). So mathematically, your password is not more secure beyond 60 characters.

However in practice, this is a non-issue, because I think that basically the only way that collisions like this are useful are for brute-forcing a password? And the chance of a password collision in this way is something like 10^27-or-28 (being hit by lightning every day for 10,000 years)? The much easier solution for gaining access is to get your actual password. So if your password being longer makes it harder for people to guess, I’d say that adding security by way of #1 is still extremely valid.

Focus on lessons instead of slacking, eh?

workstation013 is not in the sudoers file. 
This incident will be reported.