31–40 of 64 posts
Earlier quoted context omitted.
To be devil's advocate (despite being a long vim user): Lapce has a GUI, so they are not in the exact same category. Having lightening fast GUI is still a novelty, because the most popular IDEs like VSCode or JetBrains IDEs have slow downs from time to time.
The IDE is only going to be as fast as the slowest LSP service you’re using.
Earlier quoted context omitted.
Well if you're not using unsafe, you would expect zero segfaults when using rust, no? Though I imagine it's impossible for anything with graphics to avoid unsafe code entirely.
> Yes, Rust makes a few categories of bugs disappear, but Segfaults are only one of many ways for software to go wrong.
Earlier quoted context omitted.
The IDE is only going to be as fast as the slowest LSP service you’re using.
I would assume that LSPs are queried asynchronously. That's at least how it appears in VS Code.
Coincidentally this is actually a problem I faced when writing my alternative shell.
Earlier quoted context omitted.
I would assume that LSPs are queried asynchronously. That's at least how it appears in VS Code.
Asynchronous code doesn’t make something fast. It just prevents the application hanging when waiting for a function to return. But if that function is user facing (eg values for a context menu) and is slow, then your application is still going to feel slow in spite of those functions be asynchronous. Coincidentally this is actually a problem I faced when writing my alternative shell.
Earlier quoted context omitted.
On a tangent — for a numeric library, would you rather NaN or throw? I find a fair amount of division over this question, but people lean towards throw over NaN.
I'd definitely go with throw - it's indicative of a logic bug, and I'd rather notice it during dev (or if not, catch in prod, complete with stack trace and whatnot), than to have it silently corrupting anything that relies on that calculation happening correctly, without me even being aware of it. Like, if I'm doing x + y, and y just accidentally happens to contain the wrong data because of a mistake in the code, a N…
As a program author, I'd expect that it's my choice how to handle this situation. I don't want libraries making arbitrary decisions about how my code should work.
I don’t care in which language my editor is written in. From the user perspective, what sets it apart from the plethora of available and more mature editors?
I like knowing something is written in Rust because (1) the staying power of a language has implications for the staying power of the project (how many Ada projects do you see nowadays?) (2) I write Rust so I'm more likely to contribute to this, (3) I care about the safety and speed implications of language choice, but most of all (4) building from source usually isn't a pain with Rust's Cargo, but it is for most oth…
So Emacs' staying power is due to being written in LISP ?!
Written in Rust and yet when I downloaded it — admittedly a few months ago now — it segfaulted within a minute of me opening it for the first time. 0/10, not inclined to try again.
People who think the programming language magically makes bugs disappear don't know what they're talking about. Yes, Rust makes a few categories of bugs disappear, but there's a vast number of bugs that you can still easily create even using Rust with all linters you can find enabled... just saw on another thread someone complaining a Gemini (poor man's internet) server responded with a Rust panic coming from an `unw…