4 ms·

> Built in remote development support (inspired by VSCode Remote Development) Well... This has me intrigued. This is basically the only thing that keeps me on

> Built in remote development support (inspired by VSCode Remote Development) Well... This has me intrigued. This is basically the only thing that keeps me on vscode.

carlmr 5y ago
Same, + remote containers.
mikeyjk 5y ago
Jetbrains is trying to catch up on this, and in some cases has.
- stormbrew 5y ago
  If I escape vscode I'd rather it be to something lighter rather than heavier. I used sublime before vscode and I'm tired of my editor using up half my ram.
  - akmittal 5y ago
    I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
    - lordofgibbons 5y ago
      I have yet to use a JVM based GUI that felt snappy. JVM based language benchmarks are always really good, but somehow that never translates well to GUIs
      - akmittal 5y ago
        They have made a custom UI framework based on skia rendering engine. Skia is used by flutter, Chrome and firefox for rendering and known for great performance. https://github.com/jetbrains/compose-jb https://github.com/jetbrains/compose-jb
      - jodrellblank 5y ago
        There is a culture of gaslighting about it (JVM and similar); point out that you observe something being slow and it will be dismissed with "first, run the code several times to warm up the JIT, then carefully select the points where you time to make it look faster". For example this "Dijkstra path finding in C# is 15x slower than C++ version"[1], the question says "the C# algorithm takes 38ms to find a path. The C++ version takes just 2ms" and the accepted and much upvoted answer begins "First of all, you should run the FindPath method a couple of times before measuring, to give the C# runtime a chance to optimize the code. [...] Doing this gets the time down to about 17ms on my machine (from 38ms initially)." So maybe if you want a keypress that responds quickly you should press that key a few times, wait for the editor to respond, delete it, then press it again and you'll see how fast it really is. Seems to me this is tied in with the "lightning fast" claims here and the sneering dismissals in the comments "that doesn't mean ANYTHING"; it's a secret message which means "not heavyweight laggy Java". It's the Python-to-Java's-boilerplate, the Agile-to-Big-Design-Up-Front, the Go-single-binary-to-Python-virtualenv, a calling card rather than a specific performance claim. [1] https://codereview.stackexchange.com/questions/152733/dijkstra-path-finding-in-c-is-15x-slower-than-c-version https://codereview.stackexchange.com/questions/152733/dijkst... (the answer is otherwise very detailed and interesting)
  - Aeolun 5y ago
    I don't mind it using half my ram, but it needs to respond in less than 16ms in all instances. I don't want to type one letter only to find my editor frozen for 5 seconds.
  - jcranberry 5y ago
    I'm pretty happy with spacemacs with lsp-ccls for c++ development now. vscode had all kinds of weird bugs with its intellisense for me but lsp-ccls has been working great.
stormbrew 5y ago
Sadly can't get it to run on linux :( Lot of garbage about loading font config from /etc/fonts/conf.d/... and then: memory allocation of 18446744073709551615 bytes failed Aborted (core dumped)
- w-m 5y ago
  Trying to allocate memory the size of an underflowed uint64 does not seem safe. Is this possible in safe Rust code? Is there a Rust build flag that would catch this behavior?
  - Ar-Curunir 5y ago
    It doesn’t violate memory safety, so it’s perfectly valid to do this in safe rust
  - Ygg2 5y ago
    It's not underflowing int. Actually it's a divide by 0 bug, because font handling returns 0 sometimes. See my sibling comment.
  - MaulingMonkey 5y ago
    > Is this possible in safe Rust code? Yes. > Is there a Rust build flag that would catch this behavior? Runtime overflow checks (resulting in panics on over/underflow) are enabled by default in debug builds, but can also be enabled for release builds, or disabled for debug builds: https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks https://doc.rust-lang.org/cargo/reference/profiles.html#over... Additionally, you can use `Wrapping<T>` or `wrapping_sub` when wrapping is intentional, or `checked_sub` and explicit edge case handling when you want checks regardless of general build settings. EDIT: that said, that's for integer overflow. Sibling comment references https://github.com/lapce/lapce/issues/9#issuecomment-993500498 https://github.com/lapce/lapce/issues/9#issuecomment-9935004... which appears to: 1. Have a floating point div by zero. 2. Truncate when casting +inf floating point to integer. Standard library & language checks won't catch either, although it'd be easy enough to roll your own checked math floating point type wrappers / conversion methods that would, or use an existing crate (e.g. using https://docs.rs/az/latest/az/fn.checked_cast.html https://docs.rs/az/latest/az/fn.checked_cast.html to go from f64 -> usize instead of the `as` keyword would've caught #2. Since `as` is truncation-bait, some people prefer using the From/Into traits (infalliable, nontruncating) or TryFrom/TryInto traits (falliable, checked) as a matter of habit, avoiding the `as` keyword. However, neither of those traits cover f32 -> usize.

> Built in remote development support (inspired by VSCode Remote Development) Well... This has me intrigued. This is basically the only thing that keeps me on vscode.

carlmr 5y ago

Same, + remote containers.

mikeyjk 5y ago

Jetbrains is trying to catch up on this, and in some cases has.

stormbrew 5y ago
If I escape vscode I'd rather it be to something lighter rather than heavier. I used sublime before vscode and I'm tired of my editor using up half my ram.
- akmittal 5y ago
  I think above comment is about jetBrains fleet. VSCode alternative written in kotlin
  - lordofgibbons 5y ago
    I have yet to use a JVM based GUI that felt snappy. JVM based language benchmarks are always really good, but somehow that never translates well to GUIs
    - akmittal 5y ago
      They have made a custom UI framework based on skia rendering engine. Skia is used by flutter, Chrome and firefox for rendering and known for great performance. https://github.com/jetbrains/compose-jb https://github.com/jetbrains/compose-jb
    - jodrellblank 5y ago
      There is a culture of gaslighting about it (JVM and similar); point out that you observe something being slow and it will be dismissed with "first, run the code several times to warm up the JIT, then carefully select the points where you time to make it look faster". For example this "Dijkstra path finding in C# is 15x slower than C++ version"[1], the question says "the C# algorithm takes 38ms to find a path. The C++ version takes just 2ms" and the accepted and much upvoted answer begins "First of all, you should run the FindPath method a couple of times before measuring, to give the C# runtime a chance to optimize the code. [...] Doing this gets the time down to about 17ms on my machine (from 38ms initially)." So maybe if you want a keypress that responds quickly you should press that key a few times, wait for the editor to respond, delete it, then press it again and you'll see how fast it really is. Seems to me this is tied in with the "lightning fast" claims here and the sneering dismissals in the comments "that doesn't mean ANYTHING"; it's a secret message which means "not heavyweight laggy Java". It's the Python-to-Java's-boilerplate, the Agile-to-Big-Design-Up-Front, the Go-single-binary-to-Python-virtualenv, a calling card rather than a specific performance claim. [1] https://codereview.stackexchange.com/questions/152733/dijkstra-path-finding-in-c-is-15x-slower-than-c-version https://codereview.stackexchange.com/questions/152733/dijkst... (the answer is otherwise very detailed and interesting)
- Aeolun 5y ago
  I don't mind it using half my ram, but it needs to respond in less than 16ms in all instances. I don't want to type one letter only to find my editor frozen for 5 seconds.
- jcranberry 5y ago
  I'm pretty happy with spacemacs with lsp-ccls for c++ development now. vscode had all kinds of weird bugs with its intellisense for me but lsp-ccls has been working great.

stormbrew 5y ago

Sadly can't get it to run on linux :( Lot of garbage about loading font config from /etc/fonts/conf.d/... and then: memory allocation of 18446744073709551615 bytes failed Aborted (core dumped)

w-m 5y ago
Trying to allocate memory the size of an underflowed uint64 does not seem safe. Is this possible in safe Rust code? Is there a Rust build flag that would catch this behavior?
- Ar-Curunir 5y ago
  It doesn’t violate memory safety, so it’s perfectly valid to do this in safe rust
- Ygg2 5y ago
  It's not underflowing int. Actually it's a divide by 0 bug, because font handling returns 0 sometimes. See my sibling comment.
- MaulingMonkey 5y ago
  > Is this possible in safe Rust code? Yes. > Is there a Rust build flag that would catch this behavior? Runtime overflow checks (resulting in panics on over/underflow) are enabled by default in debug builds, but can also be enabled for release builds, or disabled for debug builds: https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks https://doc.rust-lang.org/cargo/reference/profiles.html#over... Additionally, you can use `Wrapping<T>` or `wrapping_sub` when wrapping is intentional, or `checked_sub` and explicit edge case handling when you want checks regardless of general build settings. EDIT: that said, that's for integer overflow. Sibling comment references https://github.com/lapce/lapce/issues/9#issuecomment-993500498 https://github.com/lapce/lapce/issues/9#issuecomment-9935004... which appears to: 1. Have a floating point div by zero. 2. Truncate when casting +inf floating point to integer. Standard library & language checks won't catch either, although it'd be easy enough to roll your own checked math floating point type wrappers / conversion methods that would, or use an existing crate (e.g. using https://docs.rs/az/latest/az/fn.checked_cast.html https://docs.rs/az/latest/az/fn.checked_cast.html to go from f64 -> usize instead of the `as` keyword would've caught #2. Since `as` is truncation-bait, some people prefer using the From/Into traits (infalliable, nontruncating) or TryFrom/TryInto traits (falliable, checked) as a matter of habit, avoiding the `as` keyword. However, neither of those traits cover f32 -> usize.