“Please don’t do it like a 4x4 truck, do it proper, like a bicycle” — there is some overlap between those things, but for people who are actually making full use of the former, the latter is not a useful suggestion
I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
More generally, targeting another project's complete featureset is often a great way to get mired down in the wrong details. Unless you can afford to do a proper cleanroom -- then, you'll be able to at least match the performance and useful abstractions used in the original.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
Remote SSH + Dev Containers and their seamless integration (even stacking one on the other) are the only features that keep me using VS Code. I would love to see the full implementation of these in an editor as fast and light weight as Zed.
How exactly are these features present in your workflow? I honestly struggle to think of when I'd ever use this.
Fwiw, I do a lot of infrastructure-as-code, full stack, and systems programming.
I usually have a split screen (editor | terminal) or two terminals on the side, and exec into a container, or use devenv.sh.
If I _really_ need to modify files in the container as I dev and a "make" doesn't cut it, I usually just run podman with a -v mount. Similarly for remote machines w/ sshfs, though I try not to.
Devcontainers are amazing for getting a consistent environment set up on multiple computers on multiple operating systems. I was in this situation recently with a new colleague who was using a very locked-down Windows computer, and it was really convenient for the "you must install" list to be Docker and VSCode only. It's definitely not ideal - it adds overhead on Windows and Mac, there's occasional networking issues, and I don't have all the creature comforts of my usual shell - but it's very convenient for what it is.
Similarly, editing code in-place over SSH rather than rsyncing back and forwards is very useful for certain types of embedded development. I worked for a while on sensor systems where a lot of the logic was handled by a Python webserver that couldn't really run without access to the sensor data it was using. Developing entirely locally was therefore difficult, but developing on the machine was also painful because it didn't have the right tools. So we'd work locally, and then copy the Python files over every so often and restart the server. At the time, I don't think VSCode's remote stuff was working as well, but I believe now it's a lot better and could have handled that situation well - edit everything in-place, run it immediately, but still have the power of you local development machine available to you.
> I'd suggest that the people who make "full use" of vsc-over-ssh are satisfied with vscode, so it would be unwise to target the full featureset.
Wha...? This is a killer feature. I'll put up with a lot of crap to use it. That doesn't mean I wouldn't switch to something nicer in other ways if it also offered this killer feature.
It's hard for me to understand why there are IDEs under active development not trying to offer this feature. It is so much better an experience to have the network split into the proper place: between the UI and the heavy computation. Having the UI too far away undoes whatever responsiveness work has been done and more. Having the heavy computation too near means it's hard to develop and test the far environment, take advantage of its compute, etc.
> the people who make "full use" of vsc-over-ssh are satisfied with vscode,
almost all my coding these days is over vsc-ssh. if zed supported sshing into a remote host and into a docker container as seamlessly as I can in vscode, Id switch immediately. The performance of the ui in zed is so much better. I'm a bit sad I can't switch with its current feature set.
The former is bad design, it has no gradual fallback and works in a terrifying way. It pulls binaries from MS servers and runs a headless vscode instance on the remote machine.
You are dead in the water if you target a machine/architecture it doesnt support.
You want to target FreeBSD? Linux on POWER or RISC-V? An old (ARMV6-TDMI) Raspberry Pi? Sorry, no remote work for you.
I'd very much prefer something that works seamlessly in 95% of the use cases and makes me do some work or look for an alternative for the remaining 5%, than something that makes me do work in 100% of the cases.
Bikes likewise have advantages that 4x4s lack. If you mean to imply everyone ought to be satisfied with the 4x4, and not ask for a bicycle: no. We can have both.
This is fun, I stumbled upon his youtube channel recently after he trash talked a lecture by Jan M. Rabaey calling his book the biggest piece of garbage ever written.
Impressive stuff nonetheless.
If you expect perfect factual accuracy from your teachers, yeah. On the flip side, they don't have the curse of knowledge yet i.e. it's still fresh in their mind what was difficult in the beginning, so they can probably explain very well. Just keep in mind who's teaching you, and it's just like if a co-student teaches you.
And if you feel you have to take what you hear with a grain of salt, that's probably good for your learning too.
I just mean in terms of experience. If you deviate from textbook accuracy and go into providing practical advice for real-life scenarios, someone with only a bachelor's and no work history is someone who can only give you canned anecdotes from others. Looking at his resume, it looks like he's had some internships so he has a bit of experience, and that's probably worth something
I went to CMU and was in AEPI fraternity with Brandon Wu. Brandon Wu is exceptional when it comes to functional programming. He was head TA of 15150 for a year, I have 100% confidence in him.
He took a break from TAing for some time, and when he returned he decided to have some fun with his application. He wrote a transpiler from a C like syntax to SML the day before his interview, and used it to joke that they should transition to teaching functional programming in C.
Yeah idk anything about him in particular. I just mean that, on paper, someone who goes straight from bachelor's to teaching is someone who doesn't really have any experience. I notice that a lot of the people who extol the virtues of FP to me are a lot of people straight out of college and have little real-world reference for why FP is useful in a prod environment
Are you talking bjt or cmos now?
Theyre not stuck at 40nm due to technical constraints.
If they were using memristors sure, but theyre not really available yet.
I have tinkered on cars both with and without torx.
Torx sucks, its also not uncommon for dimensions to differ on included torx tools so when you use a size 3 on another products "torx 3" it will strip away.
