Carmack Doesn't Like Vim | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
original • John Carmack: Best pro...
author / @lexclips
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord

[@NoxyYT]

That's kind of weird to share keyboard with someone living hundreds or thousands miles away, but who am i to judge.

[@isaactfa]

That's why it's split down the middle, so it's easier to share.

[@user-cx6ec2kp6u]

😂

[@elemstuff]

lol

[@LordFokas]

someone please link the 2 idiots 1kb clip :p

[@RogerBarraud]

One gets the LHS, the other the RHS... then they swap on the weekends.

[@ifstatementifstatement2704]

The thing I hate in the software industry is that everyone believes there is only one way to do things and it’s their way and that their way is the best.

[@akshay-kumar-007]

exactly, likeCarmack has worked on stuff that runs on users devices like PCs, Lenses, etc. Server side code and its development is completely different and that's why log don't make sense on client side apps. Anonymous telemetry and local debugging in sandboxed environment is the answer.

[@smthngsmthngsmthngdarkside]

But your way is wrong

[@diadetediotedio6918]

@@akshay-kumar-007 "why log don't make sense there" Lol, in servers we log all fricking time, there is literally a bunch of specialized services that were made just for logging things in efficient manner and organizing logs.

[@akshay-kumar-007]

@@diadetediotedio6918 hey I meant logging on client side applications. Edited the comment. My bad, my English is crap

[@TerrenceLP]

You are the Way 🎉 because you be the way

[@PinakiGupta82Appu]

As Brian Kernighan put it: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

[@dariusduesentrieb]

That sounds nice, but it is not generally true.

[@ko-Daegu]

One those things that’s nice said but doesn’t work practically for whatever reason - u get sick - you get busy - tired and not maybe feeling 100% Or simply u didn’t write that code and u have to review it something will be the norm in next 10 years more often with AI

[@davak72]

@@dariusduesentrieb But what that statement practically means is that you should write code in such a way as is easy to read and understand, rather than finding an obscure hack that works but is really not clear

[@nicolaskeroack7860]

Just stepped upon this problem yesterday... I wrote my code to add a functionality in a way too clever way, and I wasn't able to debug it. Ended up writing it in a less clever way but it ended up working..

[@user-hk3ej4hk7m]

For whatever definition of "cleverly" better fits the quote.

[@Webfra14]

The difference is, you are a Webdev, Carmack is a real programmer...

[@zeez7777]

now that's just brutal

[@justpatrick_]

Sheesh no need to attack me like that

[@rasib101]

😂

[@atalhlla]

It’s the cloud, it’s not MY computer I’m crashing.

[@Handlebrake2]

🤣

[@ruadeil_zabelin]

2:42 that is a very webdev oriented view on it though. Carmack is from the gamedev world. In his days that was 99% client sided stuff. There was no "production" server. There was people playing the game reporting some kind of issue. Even if you implemented logging, most of the time they wont send you it. Same in my case; our application logs plenty but half the time our customers do not want to send us anything because they worry it might contain their company secrets. We've gotten log files from china where someone obviously has gone through and removed and altered lines.

[@fiesbert5677]

Dude that guy invented game hosting. wtf are you on about?

[@ruadeil_zabelin]

@@fiesbert5677 I'm not talking about Carmack. I'm talking about the "analysis" of Carmack's answer to this is very much from a point of view of the modern web. Back then the issues Carmack fased were very different. He even says so himself; its a very different world. My argument is that "being able to whats going wrong in production" doesn't really apply because in the non-web field its incredibly difficult to do that. The whole concept of something being "in production" doesn't really apply. Either its released or its not. Thats it. There's no inbetween step like with modern web devops where you have a fully simulated environment and you can try out everything up front. It just doesn't apply. The only way to solve problems is by attempting to either understand the issue and fix it by looking at only the code or by attempting to reproduce it yourself. A customer (in this case, a dos gamer) is not going give you the information you need; and even if they want to they might not be able to.

[@mikerollin4073]

It's a "very webdev oriented" response because Carmack references a bunch of web companies as "hostile to debuggers"... So Primeagen went: " well actually in web... "

[@ruadeil_zabelin]

@@mikerollin4073yea, which was completely irrelevant to what carmack was talking about. But okay

[@Youtubed-jv5oi]

You can use Vim + plugins for debuggers. Also getting good at the Unix command line and the Unix tools that do one thing really well but that's it is invaluable. Look at how efficient Primeagan or engineers at FAANG, jane street are

[@rapzid3536]

It's AMAZING how few people, in general, know how to use debuggers and profilers.

[@NathanHedglin]

Cus they're JavaScript newbs

[@ko-Daegu]

I thought everyone does I’m pretty sure majority does Using debugger is a must in security industry (especially when we Rev Eng and Malware Analysis)

[@LuisCassih]

@@NathanHedglin A junior is a junior, language doesn't matter.

[@blakasmurf]

Is it just me or Lex comes across like a poser who only codes a little?

[@sligit]

My main issue with debuggers is I don't find I need them all that often, and when I do need them I end up spending so much time getting them working properly that it's not worth it. Having said that, if I could just snap my fingers and have them work I'd probably use them more, they're super powerful.

[@kasper_573]

I loved how called out Prime felt immediately when Carmack talked about IDEs. I haven't laughed so fully in years, thanks for sharing this moment!

[@ThePrimeTimeagen]

Haha, it still hurts

[@mastermax7777]

which part

[@PaladinJenkis]

100% agree on the logging part. I am an avid debugging user and I never understood why people locally debugged with logs instead of debuggers. However since I've moved to a company that handles highly distributed systems at large scale I completely understand the sentiment that writing great logs is crutial to understand what the heck is happening on production systems. Smal anecdote from my time as a consultant in a midsized company. They actually debugged on prod systems by opening a debug port where engineers can connect to with their IDEs and therefore blocking the entire main thread if the breakpoint was reached. One "genius" once placed a breakpoint inside a high traffic API Controller and left for lunch, got the shits and signed off for the rest of the day. Customers went completely bananas on us and nobody understood why only this one endpoint constantly timed out on prod. That was a painful day.

[@edwardmitchell6581]

This was even better than the video. I understand now.

[@DMitsukirules]

The thing where he was talking about people being anti-debugger wasn't actually really a server vs local code thing. It's a linux kernel developer thing. There is a bunch of famous "debuggers are useless and don't help you" when it comes to kernel developers, partially because the very nature of debugging could eliminate race conditions and the like that were causes your errors in the first place. But I'm going to go hard with Carmack on this one. Step debugging is so useful for going into a massive engine and understanding it.

[@marcs9451]

kernel devs do debugging, and they dont have such level of influence on programming culture. I regularly use gdb or lldb and they are very useful

[@earx23]

Loads of debugger use back in my assembler days. Integrated in the IDE as well. Doing a printf in assembler is error prone and super cumbersome. The debugger owns it. At some point I kinda went deep with the linux terminal stuff, and this was printf city. I missed debuggers sometimes at that stage. Nowadays with all the multithreading and Rust's amazing safety features, and Debug traits being derived at the tip of a hat.. I don't really miss the debugger anymore.

[@amesasw]

Can listen to Carmack talk about games and dev for hours. I really miss his quake con keynotes.

[@ThePrimeTimeagen]

i LOVED his huge keynotes... so so so good

[@farqueueman]

Neither do I, Vim users are like Arch Linux users. They spend half their life configuring it and the other half re-configuring it.

[@avithedev]

🤣🤣🤣

[@gogudelagaze1585]

No, that's NixOS users. I'd know, because I'm one of them.

[@heroe1486]

Configuring Arch takes an hour or two at most these days, and you don't reinstall every single day, so yeah an hour for multiple years (my last install is 3 years old and is still fine and it only broke one time when we switched from python 3.9 to 3.10, lightdm wasn't running, just installed another login manager from the tty), in the other hand the AUR alone probably saved me days of time, as always that's people who don't know what they're talking about who like bragging. Or maybe you just wanted to talk about tiling window managers, which would confirm my point.

[@eratosthenes8246]

It's time consuming in both cases but you get what you order and that's priceless

[@zeez7777]

@Greta Yeah i was a vim nerd once but im reformed now, what you said is the literal truth. I spent like half of my time configuring and adding stuff to my setup that was supposed to help me instead just to find out it still was alot worse than what IDE's had to offer, it really is weird. And while being able to elegantly move around in text is a nice thing, i have never been in a situation where my typing speed was "holding me back" during programming. 90% of time is spent thinking in my case. The only good combo nowadays are modern IDE's with vim keybindings.

[@LuccDev]

I am a heavy user of the debugger, and I really liked your take about the fact that logging is a meaningful skill that might save your life once in production. I never thought of it this way, so I love the take ! Though, I think it's not a valid point for offline application -like games-, in the case of john carmack. And also, I think the debugger as JC says is just a really great way to go step by step through your code and inspect the way everything behaves, and catch falty stuff before actually faulty stuff even happen.

[@ThePrimeTimeagen]

Fully agree on games

[@TehKarmalizer]

A debugger is a great tool for getting a big picture view of all the values without having to print everything. You don’t always know what you’re looking for. But good logging is also essential to locating problem code.

[@EspectroMascarado]

My problem when I'm helping someone who's a heavy debugger user is that it feels incredibly slow to do anything, specially on Visual Studio. They don't realize how much it takes to start the debugger, then go to first line, then press F10 (go to next step) a bazillion times to just get to the code you need. I'm fine with "guided" debugging like setting a breakpoint and jumping straight to it with F5 (resume until next breakpoint) and setting exception settings to break on exceptions (so if you run over an exception on a try {} block it breaks imediatelly instead of going to the catch {} block) but waiting while the person goes line by line their entire stack just to get to a single relevant line makes me anxious.

[@enginerdy]

@@ThePrimeTimeagendebuggers on embedded used to be big money items that few people had, so almost all code was written with printf (or worse) debugging. But when we finally got embedded debug modules that connect to the ide, it was a total game changer for writing embedded code. Can’t express how different it is and how much time it saves. It may be that the tools have not caught up!

[@enginerdy]

@@EspectroMascaradowhat kind of noob is this you’re working with? Set a breakpoint at the end of your init code or something! Literally one click.

[@ShivamKumar-yz7ho]

ThePrimeagen aka VimExpert uses a mouse to pause and play the video rather than a keyboard, and he doesn't stop there-any regular user may pause and play a video by dragging the mouse pointer to any location on the screen, but ThePrimeagen drag the cursor to the play icon in the corner !

[@skyhappy]

He used his keyboard

[@michel92777]

Always a joy to listen to the legend speak. I've watched the whole over-5-hour podcast (I highly recommend it), but that reaction was great. Thanks, Prime.

[@TheRighteousDawn]

I am seen clips of Lex around, interviewing some interesting guests. I didn't know until now that he was also a developer. I am looking for web development podcasts to check out (I realise that he is more of a software dev by the sounds). Is it worth checking out?

[@user-tb2tc6qb3q]

Also let's not forget that there was an era in Windows where we had to interface with proprietary third-party components (and for just games, for everything). Using assembly-level debuggers was the way to go and it was a great way to understand low-level details of the underlying system (how the loader works, what the kernel does when it initializes threads, APCs etc). Then you also had to go through memory dumps from customers, which were usually compiled with a high amount of optimizations, so you had to use a debugger to figure out what was wrong (considering that quite a few bugs could smash your stack, even a stacktrace could have been unreliable) My point is, that in the Windows application development world, using a debugger was commonplace (I am sure it still is, I just rarely do this anymore), much as it was/is for game dev.

[@moonasha]

I've been making a pretty complex game for months now, and I always used logs to debug, but I finally hit this point where the complexity is so high, I finally cracked open the debugger for the first time. And my god, I don't know how I would have solved some of these bugs without it. Mind you, they weren't systemically bad bugs, they were just a wrong variable name somewhere that I missed, or the wrong method being called that I forgot to change during a refactor, etc. It would have taken ages for me to find these things without the debugger. Of course there are also bugs that are much easier to solve with logs. I think both are incredibly useful, I use them both now. Being able to see the call stack and all variables while you go line by line is so useful.

[@keithprice1950]

I played the shareware version of the original Doom on my uncle's PC just after I left high school in 93. Since then I've played every version of Doom on PC, PS1 and N64. They are easily my most played games of all time and I still play the original Doom games with mods using gzdoom. Thank you John Carmack (and your original team) for giving me so much enjoyment and value for money beyond anything else I have ever purchased. 30 years and counting playing the original games.

[@georgehelyar]

Observability (tracing, logs and metrics) are really important for running in production, but good debuggers are really useful for development. Use both. The debugger is the only reason to ever use full visual studio. It's a _really_ good debugger, if you're using one of the few languages that it supports. Web developers can just use browser debuggers, which are fine, and hot reload, and then the editor doesn't matter. Rust reduces the need for debuggers by turning a lot of bugs into compile errors.

[@HaMMeR33661]

For debuggers vs logs: I think there is a distinction of when to use logging and debugger. I feel like mixing logging into tasks where a debugger might be handy slows down iteration time tremendously and makes logs less useful because their use is not *just for* figuring out, as you said, how situations happen remotely. Watering down logs and having to manage not only the final ones but also ones from development-time is very wasteful in terms of time and friction.

[@Slashx92]

I agree. There are times where logging makes sense, and there are times where debugging makes sense. Depending on the problem at hand, having an output vs inspecting the code execution give very different results

[@peppybocan]

Visual Studio proper has the best debugging environment on this planet.

[@notuxnobux]

Valgrind and clang sanitizers (which all of dont work on windows) are superior. Traditional debuggers only catch when there is a runtime issue with your code, but clang sanitizers can catch if there is even a potential that there can be a runtime issue in some different cases when you run the code. It can detect that for undefined behavior, undefined variables, memory issues, thread issues, etc. Visual studio has something similar for some cases but it's nowhere near as good.

[@dthe3]

@@notuxnobuxI think this is a limited view of debugging. While Valgrind is an excellent tool for detecting memory issues, it's crucial to use other methods like profiling, stepping, and a variety of debugging techniques to tackle different types of issues. Profiling helps identify performance bottlenecks, while stepping through code allows for an in-depth examination of the program's execution. By employing a diverse set of debugging tools, we can ensure a comprehensive understanding and resolution of coding issues.

[@notuxnobux]

@@dthe3 I only mentioned those because those are the tools that visual studio is missing and those are the hardest to debug issues. The tools that you mentioned have existed since the 90s and haven't changed much and they exist outside visual studio.

[@dthe3]

@@notuxnobux And those tools exist outside Valgrind as well. The profiler in MSVC is unmatched IMO.

[@blenderpanzi]

I'm not on Windows myself, but RemedyBG looks awesome. Looks better than the debugger in visual studio. Did you try that out?

[@zimpoooooo]

I can somehow imagine Carmack talking that fast normally, while simultaneously typing assembly code at the same speed.

[@SimGunther]

This is totally gonna be the year of "Debugger-driven development". I can feel it in my bones!

[@NickEnchev]

I gotta say, I love the idea of using Emacs + GDB for everything and not using an IDE, but when I do vulkan/opengl/engine development and I can just debug with ease, or fire up RenderDoc or the instrumentation tools in Xcode or Visual Studio, its brilliant. When I do web-dev work (to pay the bills) and just need to edit vue components etc, whatever, emacs it is. Carmack seems like the kind of guy that just can't be bothered with nonsense, needs his tools to just work so he can be an engineer. I really appreciate that position nowadays as I've spent far too much time fiddling, tweaking and MOSTLY DEBUGGING emacs/vim config files to get proper completion, debugging, syntax highlighting, flychecking, static analysis etfuckingcetra. As a backend dev, I constantly use debuggers as well, of course I don't attach to a prod server and freeze it with breaks, but debuggers have always been a big part of my web-dev life as well.

[@almari3954]

I'm mostly in embedded and most bugs I encounter are concurrency issues. Step-by-step debugging is useless for those. They are often "Heisenbugs". Debuggers are great for sequential, imperative code. Writing sequential code is easy in comparison to concurrent code and connected, network systems are always concurrent. Debuggers are great for beginners.

I don't think most developers write multithreaded code. For the normies like myself, debuggers are a huge tool.

[@EhteshamShahzad]

Logs vs debugger. It's not one over the other. Having and utilizing both allows you to write better code.

[@sociologie4507]

"your head is a faulty interpreter", I like that!

[@animanaut]

you would be amazed how often i set a breakpoint only to find out the breakpoint breaks twice. it basically replaces assumptions you might have on how your code executes with facts

[@taragnor]

I found the debugger really useful for C/C++ (especially C++). It was a great learning tool to see what the language was doing. In Rust and Typescript, I hardly use debuggers at all. Mostly it comes down to liking to use the mouse much in my workflow. Going through the debugger setting watch variables and breakpoints just takes a bunch more time than doing a quick logging command in the code, mainly because my big problems don't tend to be functions that don't work at all, but rather functions that fail on one edge case such that I'd have to be looping through a breakpoint a bunch of times before I actually get to the case I want.

[@Hwyadylaw]

Sounds like your debugger setup is inefficient more than anything

[@rakeshravindran3147]

Exactly. Debugging edge case failures is what debuggers excel. Once you learn the art of debugging, you never go back to logs for debugging edge cases.

[@monad_tcp]

Every time I tried to use text editors like VIM I ended up installinga TMux of sorts and keeping the GDB open at the same time and a lot of information that the system creates automatically for me. I basically hate littering my code with logging, specially if its temporarily, its just stupid, so I end up creating trace breakpoints. Trace breakpoints are wonderful !

[@monad_tcp]

@@rakeshravindran3147 I once debugged live code, I attached the debugger into a copy VM (it was before containers) that had the debugger tools installed. Then I used the load balancer to divert a single TCP connection to that debugger and then I attached Visual Studio over the VPN to the VM to the C# running there. So I finally was able to find a bug, together with the guys on support talking to the customer on the line, I told the technician to tell the customer to try the action, I'm observing the system, I will catch it and see the bug and fix it for the customer ! Tools you need for that : . a staging environment in the same version, but with the debug PDBs enabled. . vpn access to the staging environment . the configuration for the specific executable from production (usually app.config XML) . a load balancer that able to do A/B testing, inclusive getting a specific connection and redirecting it to the staging environment. . debugger remote tools (in case of the C#) . visual studio obviusly Sometimes things are happening fast and you can't just log everything, that's my problem with logging, it takes ages to analyze the logs, filter it, no matter what you do, its just boring work, at best logging can enable you to create a mass of data to reproduce the problem in the staging, or you can basically just fire heavy artillery, bring up the debugger. Make the bugs cry ! The thing with logs is that they never log precisely what you needed, no matter how much you log. 100% debugger. 0% logging !!!!

[@philsburydoboy]

John Carmack is coming from the perspective of GameDev -> AI. I am a machine learning engineer, and literally none of my peers knew how to use a debugger before I showed them. For production applications (think, ML inference APIs), they'd explode a 4 line section if matrix operations into 20 lines of tiny operations plus 20 lines of logging. Once they learned they could just run the webserver locally in a debugger, the amount of cleanup we had to do to deploy prod plummeted while the reliability skyrocketed.

[@sirhenrystalwart8303]

Part of the problem with using debuggers in modern systems is that everything is based around some sort of microservice architecture, and many of the bugs arise from novel interactions between these systems. While I agree that the state of the art is good logging and instrumentation, I feel like there is a big opportunity for a distributed debugger. You could imagine this first at the single machine level, where your debugger could meld multiple processes together, and single step through all of them. You could switch between processes just like gdb can switch between threads today. Then you could imagine an even better version of this where those processes are running on different servers. Maybe gdb just needs to become gdbd with a rest api.

[@blenderpanzi]

Maybe the projects I work on are much smaller, but for me Visual Studio Code is exactly like that: takes a bit to analyze the project on startup, but then is snappy. I also like the multi file search and replace with preview. And of course features like find all references, inline type checking, and inline doc comment help. And multi line editing. I did use vim a lot before and I still use vim for single file stuff.

[@katech6020]

you can do all of that in vim as well

[@ernesto906]

​@@katech6020 not as intuitive as in vscode, I have try spectre the plugin and is good but it takes time to set-up

[@gomesiano]

@@katech6020 actually the replace thing is what is making me not chaning to neovim. i mainly do react and sometimes i need to change the name of a file that is imported in a bunch of files. in vscode you just select the word and press f2, then you change the name and it will replace it everywhere it is imported, even the paths. or if you have a function you can rename the name of a var and change in the scope of that specific function. can you do this is neo vim ?

[@katech6020]

@@ernesto906 read my other comment about the video suggestion about LazyNvim it is extremely easy to setup and use

[@javierflores09]

@@katech6020 except when you are running Windows, it isn't quite that easy then

[@sagitswag1785]

I agree that logging is still a valuable skill. When I use a debugger, I always make sure to understand were the failure happens. Having a good logging system in your codebase is key to break up your application into granular units that speed up the actual debugging.

[@mathijsfrank9268]

I have used 1 screen for a decent amount of time during my study/work whenever I was moving/travelling and in my home setup now I have 3 screens. For me it is really important to have 2/3 screen, because I feel like I lose my frame of reference whenever I alt tab out of my current environment. It always takes a minute to find my footing and for my eyes to adjust to the completely new screen. This really costs me a lot of concentration after a few hours. However with multiple screens I can quickly glance over to see whatever I need to see and go back right away without losing my frame of reference. It's like every screen has its own space at my desk in stead of multiple things sharing the same space.

[@Freshbott2]

That’s wild if I have to turn my head I lose my reference unless it’s on the middle edges of the screens. My work has hot stations with three screens and it throws me. I end up working on a single laptop screen or unplugging one and ignoring the other.

[@vaishakhgk2006]

If you are in Linux you should try tiling window manager. I open many windows at same time and i am really happy with just laptop monitor. Its because if tiling window manager.

[@8koi245]

Interesting, I have an easy time finding my way when I change workspaces

[@TopOppTy]

I've never been so entertained and informed like this. love this channel

[@fennecbesixdouze1794]

@10:00 this is exactly how I develop. And it's also how I use my debugger: when my unit test fails, I'll step through the code in my debugger. The unit test is the program that is driving my code, the debugger lets me step through and see how the production code is behaving as my unit test drives it.

[@wolfstrela]

Oh yes, logging is good for servers (it's even good for clients) and Carmack understands that perfectly, as his game engines are littered with debug logs. However, what I think he means is that in gamedev the context and the hierarchy of functions can get so vast that a simple print won't do you any good.

[@VictorRodriguez-zp2do]

The D programming langues does a good job with asserts, the asserts are removed in the release/production version and kept otherwise, there's also a whole contract programming convention where you can write a set of pre and pos conditions that have to hold true before and after your function is run

[@hansoloo98]

Java also removes assertions in normal builds. Python does it too if you enable a certain optimization flag

[@DamnedVik]

19:45 The way we do it at my department, we wrote a wrapper around standard validator from the framework we're using, and validate all incoming requests, all our responses, all our requests to external APIs and all responses from external APIs (all our code is annotated with constraints). By using custom wrapper, we can enable validation on local and on staging, but disable it in production (it will be basically replaced by no-op). This allows us to catch cases where our assumptions were incorrect or slight changes in another APIs, but without performance penalty in production.

[@3ventic]

I have attached a debugger to a running production service in k8s. I think the situation was a rarely occurring bug in a codepath that executes too often to reasonably log and only manifested in the production environment. I love the debugger, but most of the time in the HTTP/protobuf world I live in, good logging exposes the issues just as well with less effort. When I was developing a game, I was using the debugger for it all the time though.

[@m1kr0kosmos]

I’ve been waiting for you to react to this since I heard it on debut. I totally love debugging IDEs instead of just actually getting work done in a text editor.

[@gmodrules123456789]

I used CLion out of the box and it never gave me any problems

[@m1kr0kosmos]

I have seen people have use cases where the IDE all just works fine for them. I enjoyed having my GitHub repo synced, but I can also push pull and clone from a repo from a terminal. I found vsCode to take up a lot of my hardware, which I don’t have endless amount of. Being able to have most of my 32GB of ram available to ./____ my programs after chmod +x is helpful to me. If I had like a threadripper instead of an i7 I don’t think I’d care as much, but vim and the shell, spitting out my program or the error messages, helps me debug. My workplace is AWS and so everything we are all discussing doesn’t even really have any bearing, much to the sentiment our dear brethren was saying. If you’re getting a great experience I think that’s awesome, im sure people made new tools to be useful for use cases, and I’m glad people have different thought about how this world works. It would certainly be a more boring place if we all had uniformity.

[@Youtubed-jv5oi]

You can use Vim + plugins for debuggers. Also getting good at the Unix command line and the Unix tools that do one thing really well but that's it is invaluable. Look at how efficient Primeagan or engineers at FAANG, jane street are

[@vanmuscari3569]

This for me hits on the points of why I like webstorm or IntelliJ so much. They have the best support for vim motions IMO but also give the nicer features for IDEs like debugging. To me it’s the best of both worlds.

[@MaxDaten]

My best annectode with the test validation approach is: Writing an EFI (EPUB version xpath) parser in Haskell. Reading the official Spec, writing doctests before implementation. Writing the implementation against the test/spec and expierience how often your are wrong with your implementation. But this is an edge case aka you know where are you heading, most of the time developing is more discovery than expected. writing every tests upfront is just one of the tools. I love debugger for understanding and debugging legacy tests. With a good test base, debuggers are indeed a great way understanding legacy code, especially when refactoring.

[@JackDespero]

For our code, a FORTRAN debuger is fundamental, because we need to see the state of the simulation at certain point during the iteration to know what is wrong. I have used Totalview, Armforge, gdb, etc. I even use the igdb debuger for Python a lot. I like to be able to run my code line by line because sometimes the code crashes and throws a 100 lines error, absolutely useless, and then with the debuger, you click next and it says "Index is out of boundary" and you are like ahhhhhhhhhhhhhhhhh. Super simple and very effective. I wish the documentation were better for all the debugers, however. Sometimes I try to Google stuff and I am left feeling that I am the only person in the world who use them.

[@julkiewicz]

It's possible to connect to debuggers remotely, even running on say a dev server. But allowing that to work would probably require redoing large parts of the infrastructure in a web-focused company.

[@Shri]

I agree with Carmack: The debugger tools in VS is best to none. Especially if you are developing for the Windows environment and specifically if you are building games. But I am not a game dev. So yeah I love my Vim! 🤣

[@notuxnobux]

I would say that it is _only_ the case when building games, otherwise there are far superior tools (valgrind, clang sanitizers, however not all of them work on windows because windows kernel doesn't support it).

[@0xCAFEF00D]

@@notuxnobux Do you only have memory related errors? I mean of course Clang sanetizers reach beyond that with ubsan etc. But this doesn't seem like general debugging. Edit: Put more clearly: Clang and valgrind does nothing for your logic errors. Or at least they shouldn't.

[@notuxnobux]

@@0xCAFEF00D valgrind and clang sanitizers do way more than memory related errors. It detects undefined behavior, undefined variables, threading issues, etc and it does that even if there isn't a runtime error. It even detects potential issues with that, even if they dont happen right now. And valgrind reports performance per function and memory usage. But for logic errors, the tools for that haven't really changes since the 90s, and that is also true for visual studio. Logic errors are easy to debug in general, but visual studio doesn't help much when you need to debug harder things and when you want to guarantee that your code doesn't have security/stability issues or logic errors related to threaded code.

[@0xCAFEF00D]

@@notuxnobux Logic errors are not easy to debug, not for me. Maybe it's what you're doing that makes logic errors easy. I'm with you that these tools haven't changed, visual studio hasn't done anything but gotten slower and supporting more languages/tools. And that sucks, they need more improvement. Especially in visualizing complex data and what's happened to it where, for me anyway. I'd love a tool that lets me mark a number of struct instances at various addresses and just see a callstack for each place a member changed breakpoints. And ideally multiple callstack if it's mutated multiple times. Needs depth restrictions for nested struts, should handle circular refences, it should try to collect mutations so I don't get 40 copies of anonymous callstack that all point to a single simple init function, give it a color. Probably more i want just for this feature. Most programs should probably have simpler data. Doesn't mean that's always the case. Data breakpoints is probably the best feature debuggers have aside from easy inspection of program state (to contrast with logging/printing). And that's where I want improvements. Because having a list of things immediately degrades the debugging experience drastically.

[@gnagyusa]

Vim and Emacs were the two reasons my friend and I wrote our own code editor. It has a C plugin API, so you can write super-fast custom extensions.

[@JonathanSwiftUK]

Not forgetting you have to check for issues outside your code, like out of disk space. I see code which assumes there several thousand files, max, in a folder, but in some cases a thing goes wrong, those files don't get cleared out, and then there are many tens of thousands of files, and you overflow.

[@HicksBoson]

JetBrains editors with IdeaVim are great, you can get a lot of nice stuff like relative line numbers. The UI is a little bloated, but disabling everything under View -> Appearance solves that problem neatly. For anyone trying that out: Ctrl+Shift+A gives you an interactive command search, so you can get the main menu back in case you feel lost.

[@lucapet]

Already tried the New UI preview? It’s waaay less cluttered with buttons and menus out of the box.

[@TheMrKeksLp]

@@lucapet And it wastes so much space with useless padding. I'd much rather have 20 visible buttons than 1 visible button that takes the same amount of space just so that it's "modern" and "sleek". I want practical and usable please

[@JakeDuthDev]

@@TheMrKeksLp You can change to the slim version of it

[@Entropy67]

20:40 I think the number of monitors that you want to use varies depending on the task, sometimes 1 monitor is perfectly fine, but there are times where I have to alt tab between 3 different things to do this one thing, and I would much rather just look at everything side by side on other monitors. Maybe you should try it sometimes! Personally I think using one monitor is more of a skill then using multiple, because it means that you can keep things in your head for longer. I know I can't so I love my 3 monitors lol

[@mihalious]

That's why you use i3(sway) instead of alt+tab

[@Kalasklister1337]

You should look into auto tiling. Achieves the same but much more quickly and without the need to break your neck.

[@porky1118]

20:36 I totally agree on that. There's no point in having multiple screens when you have workspaces. You will only watch at once screen at a time anyway. And having to switch where you watch is much more complicated than pressing a few buttons. Especially when you have different screen sizes and rotations and placement heights and resolutions and whatnot. And often I just use my one big TV screen (43 inch, 4K) for work. Bigger screens are not better than using multiple screens. Having more than two windows open at once still doesn't feel as good, even if the screen is bigger. Especially because the more windows there are, the more difficult it is to place them properly, especially in tiling WMs. But normally there's no good reason to have more than two open windows per workspace at once anyway. Either you work in a single window, or you compare contents of two different windows, or you copy/move something from one window into another, or one is the text editor and the other one the terminal.

[@dantenotavailable]

Can't assert things in production (19:48) - I think you could argue that putting a memory limit on a kubes pod is doing almost exactly that. Actually that thought process makes me want a variant of assert which works through my logger and fires off a warning(maybe an error but i'd generally see these as being something to look at in the morning, not something to wake someone at 4am over) if the assert fires. monitors (20:30) - I default to two monitors minimum... if I have three monitors the third one devolves to "where i put my blinky shit that i might want to look at eventually but don't want it to interrupt me". However it also depends on how big your monitors are... i've seen monitors that are basically the size of two monitors in which case... yeah single monitor that shit. The point is the monitors you primarily work off should be approaching the maximum amount of desktop space that you can focus on any point without moving your head. if you need to move your head then it's too much. Rather use visual studio (25:48) - you'd recant that statement 5 minutes after starting Visual Studio... real talk. Rider is better but it's still not "blazingly fast". I feel like Fleet will be worth a look in once it's done. The idea of not paying the crunch cost until you need it isn't crazy talk.

[@headlights-go-up]

I spent my childhood playing Commander Keen. Carmack is my hero (second only to Prime, of course :P )

[@IndellableHatesHandles]

Visual Studio 2022 is a really big step ahead of 2019 in terms of speed. You really _should_ try it. It went from taking minutes to load on my machine to under 30 seconds (ballparking, but it's orders of magnitude faster) and once it's loaded, it's so much more snappy

[@marcs9451]

Still horribly buggy, but at least now it breaks faster

[@tablettablete186]

I just set up the toolchain to avoid using it, all in the command line!!!

[@zeez7777]

@@marcs9451 What bugs are you experiencing? I literally never had any issues with VS so im confused when i read people say that

[@purpasmart_4831]

Sorry not installing Windows... Ever.

[@demolazer]

I have a super slow old laptop i like to code on. It struggles with pycharm but VS code, with the language extensions, runs almost as smooth as just editing a straight file in sublime. Crawls slightly if i have a bunch of other stuff open, but very nicely useable still. The function hints come up instantly. I'm confused as to where its slow reputation comes from.

[@coleshores]

As far as debuggers, most server side stuff is interpreted anyways so dumping the output and setting breakpoints or often stepping through the code is significantly easier than using a compiler. It takes the place of a debugger because a developer can view what is being processed which provides insight in to the code. In python it can be something like print(variable) followed by an sys.exit(), in ansible it could be -debug: msg: {{variable}} followed by a -fail: and in terraform it could be using an output. In terraform's case I write a small algorithm and dump the ouputs of the parsed json within a stand alone module first and once I have something working I graft it in to my codebase using something like locals. I totally get how if using a compiler that you would need to step through the code using a debugger though. Its just the right tool for the job.

[@manoharsingh6050]

People who write/wrote code in an ide would know that how helpful it is to hit a breakpoint and just pop over a complex object and examine it and just follow the code flow to find a problem. I don't user visual studio anymore but I trutely approciate that and agree with mr. carmack 100%

[@Slashx92]

8:15 yeah 99% of the times I use the VSCode debugger is to just have some breakpoints and see variables change. Having watchers for expressions and being able to see the stack traces at glance is nice, but I almost never used them

[@Youtubed-jv5oi]

You can use Vim + plugins for debuggers. Also getting good at the Unix command line and the Unix tools that do one thing really well but that's it is invaluable. Look at how efficient Primeagan or engineers at FAANG, jane street are

[@anlumo1]

My code often is so heavily multithreaded that stopping execution alters the behavior of the program so much that the debugger doesn't really help. Also, I frequently have situations where something bad happens after hundreds of executions of the same code (maybe while iterating a list of thousands of elements). I can't use a breakpoint for that, and if I'd know what condition to use for the conditional breakpoint, I could already fix the bug in the first place.

[@Jav202x]

I’m very interested in the project that you work, what type of stack are you using?? Is it web based? Application, app?? Just curious

[@anlumo1]

@@Jav202x I wasn't talking about any particular project, just the code I've worked on over the years. However, the web ones aren't multithreaded. If you want to see heavily multithreaded complex software architectures, bevy is a good place to start. It's a game engine that automatically multithreads processing where possible.

[@scharlesworth93]

Ooh you go big guy

[@username7763]

That is a case where you cannot use breakpoints. But that doesn't mean a debugger is useless. You can use tracepoints, conditional breakpoints, debug / break statements. Yes conditional breakpoints are useful. You know something is going wrong but don't know why. Put a breakpoint on it and examine the stack. Use the REPL to run code and figure out how it got in that state. You can also run the parts of your code that are deterministic in isolation and step through in a debugger. Yes sometimes your only tool is logging. I've even worked on embedded systems where all I had was a single pin to toggle and no logging. You use what you have. But don't dismiss debuggers too quickly.

[@iamalmostanonymous]

"Lay down my musket." 😂 Subscribed!

[@heater5979]

On the rare occasions a bug was so hard to track down that I resorted to a debugger or in In Circuit Emulator it turned out the tool itself would hide the problem or even introduce new problems. Usually this is on embedded systems. I like to think of debugging code on a micro-controller as similar to debugging a fault in a server. In both cases you have no GUI or console to play in easily and it's hard to recreate the conditions that trigger the bug. Timing problems, data races, memory leaks etc can be elusive under a debugger. Similarly the new sweet tools like the address sanitizer etc have often not found these hard problems. Rust of course removes the need for debuggers to discover many of these problems, they just cannot happen.

[@Gornius]

I don't even think that 100% dynamically typed code is faster (to write) than strong typed. Every time you use a function that takes dynamically typed parameter, you either have to see what the function actually expects, either by just running the code, checking documentation or checking its implementation. That sometimes even means debugging your code line by line, and even then you're not 100% sure some random exception is going to occur.

[@hamm8934]

PREACH

[@yjlom]

to be fair that problem is gonna happen with most strong typed languages that aren't also theorem provers most type systems don't protect against out of bounds access, math overflow etc. sadly

[@heroe1486]

using i3 + lots of tabs in addition to workspaces but still use multi monitors, I feel it's useful for certain situations like for example local server logs or your browser and editor on separate screens when you still want them full screen, I tested an ultra wide but still prefer multiple monitors. But yeah most people are missing on tiling windows manager, if they're lazy configuring them they could just run them alongside a DE that supports swapping its default one like KDE Mate or Xfce. Anyway I don't understand their point about Vim in the video, Lex switched to vscode but a configured neovim is just vscode but way faster and customizable, and John Carmack is only speaking about key bindings like if he didn't know he could probably have (probably subset of) those in Visual Studio too, he probably don't know that vim/neovim have access to modern plugins. I'd also like to add that people are just used to slowness, if something trivial takes more than few ms it creates too much friction, that's why I can't use any modern launcher since I can outspeed them and it's frustrating, while rofi spawns in few milliseconds

[@tourdesource]

One Monitor to rule them all, One Monitor to find them, One Monitor to bring them all, and with keyboard shortcuts bind them

[@shinobi_313]

And it is - the best way looks for me as C .header file with types separated from code, works great with js ( external interfaces should be typed, but internals don t )

[@psyoperator]

Carmack has dropped doos that write better code than this codefluencer.

[@fyasla]

Mr Carmack is cleary speaking about the benefits of 🦀 ! He is just not pronouncing the forbidden word

[@CYXXYC]

because carmack speaking well about Rust(TM)(R)(C) (this comment is not endorsed by Rust Foundation) would be detrimental to their trademark

[@zeez7777]

​@@CYXXYC Dear Mr. CYXXYC, This letter of intent to sue shall serve as a formal notice that the Rust Foundation ™©®intends to commence a lawsuit against you due to the following: Unauthorized usage of Rust™©. Sincerely, Gracie Gregory

[@travisthompson1679]

I usually get by with print statements, but I also code Python in Spyder, which is similar to RStudio. It's almost like what Carmack was talking about where you always have the environment up so you can just modify some things and immediately run it right there to test. I don't have to recompile or reinstall to test.

[@monad_tcp]

14:01 you're right, its not an option on server-side code, but why not ? don't you have like A/B deploy that you can deploy a specific version of a container to like 1% of users ? Heck, if your staging environment is good enough ( a perfect mirror because its automated CI/CD) , you should be able to read the logs, create test data based on the logs and recreate the bug in the stating environment and then attach the debugger there. Another way to go would be to capture a single live connection for a single user and just debug it, deploy a container with the debugger version and the PDBs, you can do that in C# very easily, infrastructure used for testing is already there, you just grab a specific request running in the live system, isolate it, and debug it live. I would have crashed either way and the client-side might just fail for timeout and try again later.

[@torphedo6286]

I'm on the fence between IntelliJ's CLion and NeoVim with an LSP and debugger right now. I absolutely love the IntelliJ software, I think if I could use NeoVim plugins in CLion it'd be basically perfect. I'm already using the Vim bindings there and my NeoVim colors look like CLion's, so it's nearly the same experience.

[@Mikenight120]

I have both NeoVim setup and Intelli J and man I agree, intelli J software is just awesome. The vim support is like none other ive seen in any other editor. You get to literally control the whole editor with Vim Motions thanks to the APIs provided by the plugin. Really love it. Been even daring to consider purchasing Ultimate version. I just feel so productive in it.

[@anunaysharma2718]

The thing is my laptop isn't good enough to run jetbrains ide. It lags a lot

[@TECHN01200]

When you brought rust in, you forgot to say that the stream is not affiliated with or endorsed by rust.

[@u9vata]

This talk is really interesting: Your view on logging and his on debugging and stepping makes worthwhile to investigate! Maybe the big systems should have modes or architecture to be able to step in like that! In the real, big system. Let me tell you an example. This was somewhat (and badly!!!) possible in OSGi that I added tracing modules to live system with AOP and literally to the live call stacks and all in the middle of it. Was it nasty? Yes. But it was never designed for this. Also maybe opening the building blocks alone in debugger (not the whole system, but one live part of it) would be beneficial. But I must also say: I do not think GDB is hard to use. Actually typing out commands is faster than clicking around and you can evaluate, see memory breakpoint hits, do all kinds of magic in gdb that people think about is an "IDE debugging thing" only. Same with performance analysis tools. I do not find it a burden - more like I feel there is a learning curve to it for gdb/lldb compared to clicking around. But when there and knowing them, you do not feel less able compared to visual studio. I have no experience in debugging weird propriately stuff however. Like running a game on a game console with debugger attached is something gdb and the free things might have more issues properly doing. The closest to that was debugin code on Hololens and various headsets. So maybe db can lack this or that in some cases, but not because it is not GUI. Also debuggers that debug the GPU by definition must have GUI anyways, because you want to see texture memory at breakpoints and such kind of things. That is just not possible normally from a TUI (terminal user interface) so again by thinking the environment he works in, that makes more sense. But I do step through with GDB in my sorting algorithm or data structure whenever I write anything like that happy with gdb (in some cases more happy than with a GUI). His take on this being useful - to step through instead of trying to think through sounds good advice - just it feels more like "just use the debugger more often". I don't feel people use it less because its gdb - all people have all kinds of debugger environments and still use this kind of thinking less often than useful (likely myself included sometimes). The guy is legend and his take on "knowing exactly what big something can grow" can be really useful - for example if this is some event queue subscribtion vector... well... it would automatically catch mistakes like forever adding more and more of the same thing and such sometimes that I saw happening and really slowdowns in algorithms too: like you write a slow alg because there is 100 objects but someone makes it 10k blows all up. Btw I am also a single monitor guy: only used dual monitor setup when laptop keyboard became so shitty that I had to force external one and I positioned the laptops external screen for the keyboard without turning off the internal.... that only shows literally the clock and nothing else. Just lazy to turn off to be honest... Nowadays not using this way even and just a single screen with dwm...

[@iWillAvert]

Around @24:00 - he talks about how it takes setup and all that. Aside from extensions and color themes (I also changed the editor font) it pretty much has just been go to go for me. Extensions were required, but are extremely easy to get. Everything else is technically optional. I 1000000% agree though that changing settings is annoying af in VSCode. They give you the UI which just tells you "go fuck yourself, edit the settings config file noob!"

[@m4rt_]

19:35 if you are making a web server you could just reject requests with the correct HTTP code and a message. That is the web server equivalent to assert.

[@MichaelBabcock]

gdb is vastly underrated but it is one of those programs that benefits from a user interface. That said, his comment about 'stepping through the code' in a debugger is no different from the every-other-line log.debug("this happened: {variable}") stuff a lot of us do instead, which as you pointed out, is also much easier to use on large server systems where 'run it in a debugger' isn't so easy when its a huge multi-process system running in containers.

[@Mateus.007]

Debugger is more powerful than you what say.

[@Mateus.007]

But you have vimspector with is a good gui for vim.

[@MichaelBabcock]

@@Mateus.007 I was replying *specifically* to his comment about stepping through code and seeing what's happening.

[@MichaelBabcock]

@Barret Wallace I'm certainly not talking webdev either, I'm talking about long-running services running in VMs on big servers out in the world. Testing those in a debugger on a local machine is just not representative of real-world testing and when running in the real world, attaching a debugger is very difficult which again, I said explicitly in my comment.

[@TreeLuvBurdpu]

One of the great things about computers is that teach us to NOT treat numbers like mathematicians do. An integer, in computers, does not mean every whole number up to infinity -1. Infinity is bullshit. All numbers exist within a range. Everything that exists, exists in a quantity.

[@evandroprogram]

If your vision is still fine, like mine, with a single 4K monitor (without scaling), you actually get 4 1080p monitors. It's being working very well for me. For the other peripherals I use the MX series of Logitech (MX Keys and MX Master 3).

[@Waffle4569]

I understand the "logging has its place" sentiment for servers, but at the same time you gotta ask yourself, is that just because server lack good debug tools beyond logs.

[@jim0_o]

24:27 I wonder if he is talking about Sean Barrett (he made/makes the STB libraries)

[@VACatholic]

Probably.

[@bitwisedevs469]

Lint tools are the best, they may sometimes raise false positive but it will always help you to write a better code based on studies such as cognitive complexity. I realized how so much defensive programming I put on my codebase that it is getting more hard to read and sometimes will never really occurred, having a static analysis tool forced me to refactor it and make it more readable and optimize. Sometimes you may feel it is premature optimization but realizing you are writing a bad complex code is really helpful and will drastically improve your coding skill.

[@user-vi4zw6zu4c]

I like getting the GDD’s error message that looks like it was written by aliens

[@callysibben416]

I write microservices at work and games at home and I absolutely understand John's take because I can't imagine not doing game development from a debugger, but it really isn't that useful in the microservice world. I think the difference is in whether code can be run in isolation or not. I can run a single endpoint, see the output, and read the logs, but with a game it's not really helpful to run the different systems in isolation.

[@brainsniffer]

The thing for me is I need extra monitor space because I maintain servers and I need alerts popping, and to know the state of the servers. I’d love to be a pure dev where I wouldn’t need a monitoring app on the other monitor. Also, not having to answer emails and messages straight away and stuff.

[@8koi245]

damm that sounds so stressing bro, sending strength ~

[@ianbrierley3233]

I'd say it's not all or nothing. I do programming and also look after servers. I'd say, try to find a middle ground. Eg, find an old android tablet, install slack or something to it, create a separate channel, and send api updates to it when errors happen or thresholds are hit, or just have a custom page on your admin site with a graph refreshing. I.e the idea is you can see what's happening when you request it, or glance, but it doesn't dominate or distract too much.

[@elobiretv]

Sounds like you just need a better way to receive alerts. I have to maintain our infrastructure but you don't see me staring at monitoring charts on my second monitor all day long.

[@ElArboool]

dude summarized my general experience of trying vs code through the years. thing just never stopped feeling sluggish while also a huge memory/cpu hog

[@randomlegend631]

If you want to reference notes, wouldn’t a second monitor be good for that? How do you look at or keep notes when you are using one monitor?

[@Iceman259]

Carmack sounds like 1.5x at 1.25x lol

[@MrHaggyy]

I would love to see the three of you working on the same project from your natural environment. Lex is academia he need to think so much for basically every line of code. John works on hardcore performance stuff. So still a lot of thinking, but he shouldn't be limited by his typing like ever, because of the nature of the problems he works on. Prime's still needs to think a lot but in web stuff you usually have all the space you need. So writing enough code to frame your idea is infact a limiting factor. Gosh you three would be interesting, Lex even tho he moved to VSC still has EMAC in his blood, John is VS/VSC main, Prime is VIM king ... also each one of you gave every Editor a fair chance but it's usually down to not knowing your tool.

[@marcempunkt9737]

My second monitor is only for presentation stuff so I can see the chat or all the participants on one screen and have the main screen for work.

[@alpheusmadsen8485]

"I think it's really hard [to recreate prod on a local machine]". This reminds me of a bug that drove me nuts -- something was working on my machine, but was broken in Prod. I had to go to Prod to trace things, and eventually found that the bug was a syntax error in PHP -- for the version on Prod -- but I had a *slightly* *older* version of PHP, where it *was* *not* a syntax error! As I think about things like this, I cannot help but reflect on my hair loss over the years, and suspect there's a little cause and effect thing going on here ....

[@musdevfrog]

Prime should be on Lex's podcast.

[@johnyewtube2286]

Lex is boring, very overrated.

[@tokiomutex4148]

Lock that guy I should

[@ThePrimeTimeagen]

I think you just need to unlock his heart

[@tokiomutex4148]

@@ThePrimeTimeagen That sounds like a good plan

[@PantsManUK]

"What did he work on?"

[@luv2stack]

At first when Carmack started speaking, I thought it was on 2x speed

[@johnychinese]

Bro we need a Lex and Prime colab

[@Jeru3]

I don't believe any single screen developers, probably lizards you all.

[@ThePrimeTimeagen]

Just because I'm a lizard doesn't mean I'm not a person too

[@ksk31337]

lul, didnt know this type of content existed. hooked :D

[@nightshade427]

We log our assertions in production and monitor them with alerts. The app keeps running but we see if things are progressing in a way that is cause for concern.

[@karaMcg1122]

"using vim is like civil war reenactment"😂😂im dead

[@asdqwe4427]

I do prefer NeoVim but plug-ins are better in vs code. By better I mean that there are more of them, but more importantly, way easier to find and install for most people. Most people will never bother to figure out neovim

[@PimpofChaos]

And they shouldn't to be honest. Anything niche is interesting at first but people do not like dragging themselves through the mud to make something work after too much effort, and the end result is not better than mainstream ones.

[@badopcode]

As an old dog developer who was beaten to death with TUI based systems because that was all there was. If TUI is even a term now days. BUT I appreciate the GUI based editors because I can "quickly" have more monitored stuff on the screen then the TUI systems. I'm not knocking all the TUI based IDE's. I've used them all and I can still get stuff done in them today. But I really enjoy having more of the stuff displayed for a glance and willing to sacrifice other performance areas for it. But like Carmack... stepping through code debugger is one of my processes... and the memory monitors are so much easier for me to look at stuff in the GUI based IDE. Yes, I know how and have done this in TUI. I just don't want to. VSC is a weirdo. It's like TUI editor with all the setup required before it's useful... but it's GUI-ish. I use it as my primary editor for work, because I have to touch so many different technologies and languages. It's alright. But if you were already partial to VIM or Emacs, it would definitely seem like a pointless waste of time, just to have the extra weight of a GUI that doesn't give you much more. It all really depends on your workflow. I pretty much change tools as I need to because how well they work with the flow of the job. Honestly I think the worst mindset for any developer is to get in a love affair with a developer tool that even when it's holding you back, you still go with it.

[@shyshka_]

logging properly is crucial when you work in a microservice architecture which is becoming more and more popular. You can't just locally debug a whole bunch of interconnected microservices that are talking to each other and different databases very easily

[@Hwyadylaw]

I've been using nvim regularly for a year (and vim sporadically for 10+ years), and I'm still not as productive as in VSCode. I only use it because I enjoy being able to build ridiculous configurations and minimum effort plug-ins.