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 other languages.
All these things materially impact how interested I am in using and contributing to the project.
I don't get the point you're making. Yes, the popularity of technologies is impacted by the popularity of related technologies.
My argument is that Rust is certainly going to remain relevant for the next 20 years or so. When this project is no longer maintained, it probably won't be because Rust is no longer being developed, and it probably won't be because nobody writes Rust around.
If Lapce were written in something like Zig or Crystal, I wouldn't feel so certain about that. (Not a knock to Zig or Crystal.)
Just that Emacs was written almost a half century ago, and is still thriving despite being written in a language (LISP) that is basically obsolete.
> My argument is that Rust is certainly going to remain relevant for the next 20 years or so
Maybe, maybe not. Look at how quickly Perl (so promising to begin with) disappeared to be replaced by Python. Many new languages have tried, and continue to try, to replace C++ as a better alternative, and I'm sure the next 20 years will see more popup too. Is Rust the one?
If the likelihood of being around in 20 years with a still up-to-date library/tool ecosystem was the main decision making factor, then Java would probably be a safer bet.
> Just that Emacs was written almost a half century ago, and is still thriving despite being written in a language (LISP) that is basically obsolete.
Yes, this is true. I still stand by my point that the longevity of a language has implications for the longevity of most projects. It's a probabilistic statement with exceptions, and Emacs is exceptional.
It's also worth noting that Emacs is written in Emacs Lisp, a language which is regularly updated.
> Look at how quickly Perl (so promising to begin with) disappeared to be replaced by Python.
Don't get me wrong, Rust's longevity is a guess. It's in the Linux kernel now, so that gives me hope that learning Rust is paying off.
Cargo is fantastically nicer to use than most other languages tooling. If I'm wrong, then that means something even nicer than cargo is around, which would be very nice indeed.
> If the likelihood of being around in 20 years ... was the main decision making factor, then Java would probably be a safer bet.
This is true, but the premise doesn't hold. The longevity isn't the main decision making factor. No decision is even being made, and you're arguing against a point nobody is making.
Please refer to my original comment: I'm only listing reasons why I like knowing something is written in Rust.
“Has implications” is a very weak statement. Even if it is a very small effect but measurable fits that description.
“Irrelevant” is a very strong statement. It claims no effect at all. A single example does not justify the claim. You need at least some statistical evidence to support that claim.
For your last question, yes I do. I sometimes take over the abandoned project to maintain it too. Some open source users never contribute in any way, some do. I’m not sure why there’s a need to dismiss the existence of the latter kind of users. No one is claiming all users should be like that.
No, of course not, but the example does show that programming language is pretty much irrelevant.
The big lie of open source is "you have the source, so you can extend it and fix bugs yourself". Of course in theory (with enough expertise and motivation) you can do these, but in practice most open source users don't contribute to the project, so the language it is written in is entirely irrelevant.
When was the last time (if ever) you submitted a bug fix (not a report) for an open source tool you are using, let alone joined the project as a contributor?!
“Has implications” is a very weak statement. Even if it is a very small effect but measurable fits that description.
“Irrelevant” is a very strong statement. It claims no effect at all. A single example does not justify the claim. You need at least some statistical evidence to support that claim.
For your last question, yes I do. I sometimes take over the abandoned project to maintain it too. Some open source users never contribute in any way, some do. I’m not sure why there’s a need to dismiss the existence of the latter kind of users. No one is claiming all users should be like that.
- Truly open source, presumably without the caveats that VS Code has such as a few "features" (extensions) being closed source and the extension marketplace being closed to de-microsofted builds
- Designed from the beginning to support an extension API with a richness comparable to VS Code's (unlike Sublime, Jetbrains etc)
- Presumably aiming to put performance as a higher priority than is usual
If you believe that regexes are hard to debug and overly complex, you might resist a text editor written in perl because it's likely that regexes are used everywhere (even when they shouldn't be).
That said, I can totally see why it would matter to some people why language something is written in: you may want to study or contribute to an editor and you may prefer to focus on your preferred language
Exactly. I keep wanting to fall in love with Lapce or Helix because I'm very interested in Rust and like the idea of an editor that I could contribute to, but my (neo)vim muscle memory is just too strong, even minor differences drive me nuts.
For starters, it doesn't seem to use a browser engine to render its UI. Seems to aim for a VSCode look and feel. Installation on macOS is about a third of the install size of VSCode (105 MB vs 330 MB), and it's a single statically linked executable (vs a plethore of files in a VSCode installation).
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 `unwrap()` call :D
> 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,
I think few categories undersells it. Just having Optional/Maybe in a language legitimately does make bugs disappear.
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.
If the makers of a software program make a big deal about the implementation language (in Lapce’s case, they mention it in the first paragraph), then I take that as a statement that they’ve taken advantage about that language’s unique features to deliver better software.
In Rust’s case, I take it as a promise not to do anything memory-unsafe. Lapce did not keep this promise when I tried it.
FFI, performance, ownership that’s impossible to express statically, 3p dependencies, direct OS calls or HW management that aren't available with safe wrappers etc.
Sticking to safe rust is an ideal and it should be a goal but the primary use is to accomplish a task. If safe rust is getting in the way and there’s no way to do it easily otherwise, don’t feel bad about unsafe. The amount of unsafe should be minimized of course which reduces the surface area of issues greatly compared with c/C++ where every line is unsafe. Practical code is always >> ideological purity.
Hot Take: Rust Panic's are about as bad as Sig11s from the C world. I don't get good debug information in the typical case - and library authors get to decide when my program crashes (which I disagree with).
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 NaN means the code will proceed as normal, and nobody will notice anything is wrong. If it's not a noticeable bug, it might be a long time until it's spotted by someone. And when they do, who knows how much damage it will have caused.
I'd always go with NaN. In dataprocessing, it's common to encounter NaNs due to bad data - these records can be filtered out to allow the process to continue. The records which resulted in NaN can be flagged for follow-up.
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.
No necessarily. Rust doesn't do that for array indexing (though bound checking is enabled at runtime and will panic if out of bounds), division by zero, numeric overflow and probably many cases where it was deemed to be just too cumbersome.
I tried it last month and loved having Alacritty there. It built easily and ran well on both OSX and Fedora Asahi Linux.
That said, it does not seem yet ready to be a daily driver, small rough edges in the terminal behavior or the editor when using Vim mode were too distracting to do a long programming session.
Kudos to the authors, looking forward to giving it a spin again the future.
I love Rust, but I don't really care what language my editor is built in.
That said, I'll give this a shot because:
- no funky telemetry
- the stack used (wgpu etc) means this might be sufficiently low level to be much more resource efficient than alternatives
- it sounds like the plugin architecture will allow for a vibrant extension ecosystem if this gets some adoption
VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature. This thing is extremely important for embedded systems and development on the edge and only vscode really does it well enough to be useable.
> VSCode does this feature the best. No other IDE comes close. I'm a jetbrains guy and I would've given up on vscode completely if it were not for this feature.
It is really good, I'm sure a lot of people feel like they have to use VSCode because of it.
I’ve been soul searching for a new editor for about 2 years now. This checks the box for being native, modal/vim. So I’d probably adopt this like I did with alacrity when I dumped iterm.
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.
It's not the GUI itself. A console application in a window is still a gui rendering console text. It's the fact that Vscode and jetbrains use a high level language/engine that makes it slow.
For jetbrains it's java and for vscode it's an html rendering engine. An IDE built from vulkan or some other low level graphics API can likely be even faster then vim depending on the console it's running within.
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.
I was just saying that you can make the text editor as lightning fast as you want but the moment you need to do anything useful with an IDE you become dependent on the performance of your plugins.
This is why I’m a little jaded when people talk about IDE performance. Unless that IDE is using its own bespoke plugins, and the trend these days is (thankfully) moving away from that, it’s really not a good benchmark any longer.
