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.

Torterra is a tortoise. Totally different thing.

You can always use your own code however you want. However, if your project starts to get contributions from other people, that’s where it can start to become more muddy.

tbf, I don’t know how feasible it is to remove asbestos without employing 4 year olds.

Focus on lessons instead of slacking, eh?

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

I have a blog! Usually, it’s photos from traveling or “how I made this” or “how I do this” kinds of posts. Basically, if I get tired of people asking me about something, I turn it into a blog post 😂

https://bpev.me/

Probably the most interesting thing from it is the long-ass series of posts describing how I made my music album:

https://bpev.me/notes/vx1-session-the-problem

Is their app big? fwiw on desktop, I just use their config with wireguard app, and that works quite well for me.

deleted by creator

Mmm it sounds like you’re using it in a very different way to me; by the time I’m using an LLM, I generally have way more than a general feel for what I’m looking for. People rag on ai for being a “fancy autocomplete”, but that’s literally what I like to use it for. I’ll feed it a detailed spec for what I need, give it a skeleton function with type definitions, and tell the ai to fill it in. It generally fills in basic functions pretty well with that level of definition (ymmv depending on the scope of the function).

This lets me focus more on the code design/structure and validation, while the ai handles a decent amount of grunt work. And if it does a bad job, I would have written the spec and skeleton anyways, so it’s more like bonus if it works. It’s also very good at imitation, so it can help to avoid double-work with similar functionalities.

Kind of shortened/naive example of how I use:

/* Example of another db update function within the app */
/* UnifiedEventUpdate and UnifiedEvent type definitions */

Help me fill in this function

/// Updates event properties, and children:
///   - If `event.updated` is newer than existing, update as normal
///   - If `event.updated` is older than existing, error
///   - If no `event.updated` is provided, assume updated to be now()
/// For updating Content(s):
///   - If `content.id` exists, update the existing content
///   - If `content.id` does not exist, create a new content
///   - If an existing content isn't present, delete the content
pub fn update_event(
    conn: &mut Conn,
    event: UnifiedEventUpdate,
) -> Result<UnifiedEvent, Error> {

100%. As a solo dev who used to work corporate, I compare it to having a jr engineer who completes every task instantly. If you give it something well-documented and not too complex, it’ll be perfect. If you give it something more complex or newer tech, it could work, but may have some mistakes or unadvised shortcuts.

I’ve also found it pretty good for when a dependency I’m evaluating has shit documentation. Not always correct, but sometimes it’ll spit out some apis I didn’t notice.

Edit: Oh also I should mention, I’ve found TDD is pretty good with ai. Since I’m building the tests anyways, it can often give the ai a good description of what you’re looking for, and save some time.

Mmmm kind of? I wouldn’t categorize most comments as describing “extremely weird” reasons, though. Code will generally explain the “how”, while comments can describe the “why”. For example, think of an enum with ViewSize “mini” and “full”. It might be nice to have a comment to briefly summarize what ViewSize is meant to represent, and maybe link to a spec. Basically, a comment here will connect the intention with the implementation.

A more inline-comment example of this might be if there’s a slightly nuanced case that you want to be very clear about, ala maybe a Javascript true/false/null case, where you might be checking === false, and specifically don’t want someone to refactor it into a falsy check. Kind of contrived example , but that sort of thing. This is probably more the “extremely weird” comment you’re talking about; almost just a warning that this might not be what you think it is.

The other common use-case I find good for comments is for summarizing the goals/purpose of a complex function. This is mostly for future people who might utilize this function, and don’t want to read through a bunch of code, just to remember the nuances of what it’s supposed to do. For example, a “sortEvents” function, you may want to summarize the business requirements of the sort at the top. Although, this kind of thing may be different depending on how documentation is stored.

Anyone got store recs for non-english books? Or that mostly just gonna vary a ton by language?