261–270 of 703 posts
Earlier quoted context omitted.
Debian packages are often old. Hence people found a way around. > You just described how the script is less convenient to meet the preferences of the commenter you replied to. Well… no. The person I reply to doesn’t say anything about preferences. They want to know how to update the software, the script is the best reference.
> Debian packages are often old. What about AUR or Fedora packages? ;D
Earlier quoted context omitted.
Sublime's focused/minimalist UI is nice. VS Code sometimes feels like it tries to do too much. My ideal editor would probably be something like a variation on Sublime Text that's modeled more closely after TextMate while keeping the bits that make Sublime better (like the command palette).
Sublime is the better Textmate. What would you do to subl to make it more like mate? I used textmate for years and years before switching to ST and it was a drop-in replacement.
I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…
VSCode is very fast for me, when I open it in the morning and just starting my day.
But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce scenario while changing code on the fly, then the test conditions are really set up where differences between slow/heavy and fast/lightweight software can be noticed.
Things like slowness in syntax highlighting, or jankyness when opening different files. Not to mention what happened when I wanted to show the step-by-step debugging of the software to my colleagues.
In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.
I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but: 1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most. 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down e…
Microsoft's latest embrace-extend-extinguish strategy is keeping just enough special sauce in (frequently closed-source) vscode extensions and out of the language servers. They do the same thing with Pyright/Pylance.
Sadly I can't run it in WSL. thread 'main' panicked at crates/gpui/src/platform/linux/wayland/client.rs:143:51: called `Result::unwrap()` on an `Err` value: UnsupportedVersion note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Man, what kinda of QA do they have that they miss something like this? WSL can be considered the second largest Linux "distro". Of course, zed has always felt like an osx first project with linux/windows being second class citizen.
Earlier quoted context omitted.
It isn't 1860 anymore, "the freedom to take freedom away" no longer counts.
In what way is VSCode comparable to enslaving human beings?
Sadly I can't run it in WSL. thread 'main' panicked at crates/gpui/src/platform/linux/wayland/client.rs:143:51: called `Result::unwrap()` on an `Err` value: UnsupportedVersion note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Man, what kinda of QA do they have that they miss something like this? WSL can be considered the second largest Linux "distro". Of course, zed has always felt like an osx first project with linux/windows being second class citizen.
You are lucky if there's some automated unit testing, but that's as far as these things go. Programmers don't like, don't know and don't want to know how to QA. Also, they generally look at QA with contempt... so, unless forced to, they won't do it.
Earlier quoted context omitted.
There are two schools of thought. One strives for correctness, even if that requires extra effort. Another is "anything goes as long as it somehow kind of works more than it doesn't." (Actually it's most probably a spectrum rather than a binary division, but I'm no philosopher or sociologist, so for example's sake I'll operate with this simplified model here.) The world en masse is generally preferring the latter (pi…
| among the engineers there are a significant number of people who believe that's how things should be There are close to zero people who tend to think like that among actual engineers . That's why we have reliable transportation and bridges and skyscrapers that work for (soon to be) centuries. On the other hand, we have lots of them among self-professed "engineers" who have changed many monikers over the past couple…
Oops. My apologies - I meant exactly that, that a significant number of engineers believe in correctness and sound approaches, but I had a brain fart writing that comment. It should've been "believe in the former".
No idea about how many non-software engineers take various shortcuts, though. But I think there's a non-negligible number of electronics engineers who do so - I'm not an expert in that field, but it's not unheard of skipping coupling capacitors or using a resistor divider instead of a voltage regulator to cut down the costs (because that still works... until it doesn't, of course).
I found the zed website unhelpful, but if wikipedia is to be believed, it's a successor to the Atom text editor