Lapce: Fast and Powerful Code Editor Written in Rust • Hacker News Board

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#41

Post by vlovich123 » Thu, Dec 28, 2023, 9:59 PM UTC

n8henrie wrote: post #40

brabel wrote: post #4

Earlier quoted context omitted.

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…

Certainly not all bugs, but in theory a segfault should be entirely avoided in safe rust, right?

Segfaults in safe rust cannot happen modulo compiler bugs. A true segfault (vs panic) would require unsafe Rust somewhere.

But there’s bound to be unsafe code somewhere in a complex enough project.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#42

Post by hnlmorg » Thu, Dec 28, 2023, 10:14 PM UTC

schemescape wrote: post #37

hnlmorg wrote: post #33

Earlier quoted context omitted.

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.

Right, I just meant it wouldn’t hang the UI (as the parent comment seemed to imply).

That wasn’t what I was implying.

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.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#43

Post by n8henrie » Fri, Dec 29, 2023, 1:48 AM UTC

ithkuil wrote: post #18

KolmogorovComp wrote: post #12

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 agree with your sentiment. 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.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#44

Post by n8henrie » Fri, Dec 29, 2023, 1:49 AM UTC

vlovich123 wrote: post #41

n8henrie wrote: post #40

Earlier quoted context omitted.

Certainly not all bugs, but in theory a segfault should be entirely avoided in safe rust, right?

Segfaults in safe rust cannot happen modulo compiler bugs. A true segfault (vs panic) would require unsafe Rust somewhere. But there’s bound to be unsafe code somewhere in a complex enough project.

Outside of FFI, is that mostly just for performance optimization?

EDIT: IOW, why don't projects just eschew unsafe in order to truly leverage one of Rust's primary claims to fame?

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#45

Post by KolenCh » Fri, Dec 29, 2023, 2:12 AM UTC

HarHarVeryFunny wrote: post #39

lynndotpy wrote: post #24

Earlier quoted context omitted.

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…

> the staying power of a language has implications for the staying power of the project So Emacs' staying power is due to being written in LISP ?!

A affects B, doesn’t mean B only depends on A.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#46

Post by nocsi » Fri, Dec 29, 2023, 3:28 AM UTC

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.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#47

Post by sspiff » Fri, Dec 29, 2023, 7:09 AM UTC

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

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#48

Post by vlovich123 » Fri, Dec 29, 2023, 9:29 AM UTC

n8henrie wrote: post #44

vlovich123 wrote: post #41

Earlier quoted context omitted.

Segfaults in safe rust cannot happen modulo compiler bugs. A true segfault (vs panic) would require unsafe Rust somewhere. But there’s bound to be unsafe code somewhere in a complex enough project.

Outside of FFI, is that mostly just for performance optimization? EDIT: IOW, why don't projects just eschew unsafe in order to truly leverage one of Rust's primary claims to fame?

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.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#49

Post by truculent » Fri, Dec 29, 2023, 10:42 AM UTC

zokier wrote: post #21

truculent wrote: post #10

Earlier quoted context omitted.

If the operation can fail, that should really be represented in the type, right?

One of my random thoughts is that floats could be represented as enums in type system, e.g. in rust-like syntax: #[repr(f32)] enum Float32 { PositiveInfinity, NegativeInfinity, Nan(NanPayload32), Finite(FiniteFloat32), } You could also then define NonNanFloat32 etc which could be used for certain operations. Of course on machine level its all the same

Yeah, I think something like this would make sense. I get why people might not like it, but this is what we’re dealing with whether we like it or not.

Re: Lapce: Fast and Powerful Code Editor Written in Rust

#50

Post by brabel » Fri, Dec 29, 2023, 11:36 AM UTC

truculent wrote: post #10

threatofrain wrote: post #7

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.

If the operation can fail, that should really be represented in the type, right?

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.