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.
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.
@@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.
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.
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.
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 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.
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... "
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
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.
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.
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.
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.
@@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!
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.
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.
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.”
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
@@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
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..
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.
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 !
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.
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.
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?
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.
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.
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.
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
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.
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
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.
@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.
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.
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
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
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.
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.
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 !
@@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 !!!!
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.
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.
@@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.
@@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.
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.
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.
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.
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.
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
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 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 ?
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.
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.
Рік тому+2
I don't think most developers write multithreaded code. For the normies like myself, debuggers are a huge tool.
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.
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.
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
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! 🤣
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).
@@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.
@@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.
@@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.
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.
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
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.
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.
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
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.
It's actually nice to hear somebody who is not just so notoriously good but also notoriously *intuitively a step beyond* most programmers saying straight up that he's fucking things up non stop and knows his intuition isn't good enough. It really is kind of freeing to hear John Carmack of all people say "I entered the machine dimension and talked to the beings there and they told me use the debugger idiot your code is unsafe"
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.
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%
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 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
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 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.
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.
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
Don't assert in code unless you can remove them in production via compile flags or your pipeline. I HATE seeing asserts sneaking into production code. may as well put panic!("dees nutz") in all your rust and ship it.
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.
@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.
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.
@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.
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.
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.
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.
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.
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.
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.
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.
multiple monitors, prime you dont have to touch your keyboard to see something on different display. you just have to move your eye ball or head, which is very good for posture as no one knows for how long we haven't moved our heads while starting the display.
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.
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.
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.
The term "user friendly" is deceptive. It can mean "friendly for someone who's never seen this before", but it can also mean "really efficient for an expert to use". A piano has a very user friendly interface for a piano expert, but not so much for someone who plays the bongos. A bongo, on the other hand, is very user friendly for everyone. GDB is very user friendly for expert users. It just has something of a learning curve, perhaps more steep than something more graphical. So whether it's "beginner" or "learner" friendly is a different issue than "user" friendly.
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.
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
Trying to make vscode act like vim is the same as painting you whole life with a paint brush, but then switching to pencils and trying to make the pencils work like that paint brush. It just makes no sense
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.
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.
The best thing about good logging is that the customer, support, or operation often can figure out the problem and fix it themself without disturbing you.
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!"
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.
I don't agree with all the people who say VS Code "just works". Like maybe as a basic text editor, but as somebody who uses JetBrains (primarily Goland), stock VS Code is just fancy notepad in comparison. If you want to do anything substantial, you have to install a bunch of plugins and do a ton of config and hunt options as you put it. And even after you install and tweak everything, it still doesn't do a bunch of the QoL things that JetBrains does right out of the box. For me, JetBrains tools are the IDEs that *just work*. I'd be curious to see Prime give Goland a try for either Go or TS development. I can't suggest CLion for Rust though because the proprietary Rust analyzer they ship is kind of awful compared to the community rust-analyzer. Edit: should have waited to the end, he used IntelliJ for years, and I didn't already know that lol
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.
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
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.
honestly I think it is a triangle. Thinking about your code and trying to understand it is sometimes the best way to find a bug, and trying to do it improves your mental model of the compiler and the machine semantics leading you to write better code. Knowing when and where to augment the logging and when and where to jump into a debugger are in my mind equally useful. If you rely on only one method for bug forensics then some problem will inevitably arise where you are entirely out of your element. There is always going to be a scenario where you forgot to log something or it is not reproducible and not visible in the log dump because of the wrong log level. There is always going to be a scenario where even in the debugger for whatever reason you can't find the right breakpoints to locate the problem effectively, or where using a debugger is not feasible. And then you HAVE to be able to rely on your ability to generate theories about how the code can produce the observed symptoms. It's a tripod people. People arguing about is X better than Y usually are missing the point that you should probably be good at both. I would generally take a well rounded generalist any day over an expert in one specific thing if I could only choose one of them. Get good at as many things as you can, and get really good at one or two specific things you really like.
John Carmacks interview with Lex was great - but this idea that Vim users are just old-fashioned hold outs that haven't experienced the 'modern' IDE is so backwards to anyone who actually uses Vim. It just makes me laugh, but horses for courses, I guess
@@hansu7474 Besides, you could get VIM key bindings in a "modern IDE" as a plugin so you get the best of both worlds in big project development. If you're just doing quick flip projects, I can see why people go for emacs/vim/neovim.
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
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.
I'm 95% Python, a bit of C++, and I really don't like VSCode. I feel like Pycharm is just way easier to use, you just install it and it pretty much just works. And the debugger in it is just so good. I feel bad for the beginners who think that VSCode is the be all end all, and it's really an uphill battle. VSCode is in itself like a language you have to learn.
I've never used pycharm but i would bet it is superior to vscode for python just because it is a jetbrains product, and in my experience jetbrains ides are superior. but they also (usually) cost money, and vscode doesn't. you can get support for any language via the marketplace and you're rolling. it isn't like a language you have to learn, maybe writing launch targets and stuff is annoying but you can get by without that stuff
Hey love your show btw, going back to your context there is a compromise called instrumentation bpf for production.. so hookup with Mr. Gregg and see how the community can push the probes-rs and or rust-usdt.
He doesn't like vim, he doesn't like rust but hey he's John fkn Carmack the guy who created doom in ASM 😂 but c'mon man I was using pacman just now and saw emacs has like 100+ dependencies vs Nvim/Vim where the former only has 3 deps the last I checked 😂 I personally use vscodium right now tho coz im lazy, but setting up clangd isn't too bad and the modern languages like rust, go & zig work well with vscodium & basically out of the box, I literally have only 4 plugins on my set up
I've never enjoyed Fridman's interviewing style. Leading questions, and soapboxing a lot of his own thoughts while I'd rather hear the guest talk more.
So basically your whole channel is only you getting annoyed at people for not loving Vim and rust. Here's a good one for ya, who the hell uses either vim or friggin rust 🤣
@@flflflflflfl People who know what they're doing use Rust? Gonna have to hard disagree with that. Definitely people who follow fads, but the percentage of people who "know what they're doing" (as measured by: shipped a ton of high quality, highly performant code), is vanishingly small, and I challenge you to prove me wrong.
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.
That's kind of weird to share keyboard with someone living hundreds or thousands miles away, but who am i to judge.
That's why it's split down the middle, so it's easier to share.
😂
lol
someone please link the 2 idiots 1kb clip :p
One gets the LHS, the other the RHS... then they swap on the weekends.
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.
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.
But your way is wrong
@@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.
@@diadetediotedio6918 hey I meant logging on client side applications. Edited the comment. My bad, my English is crap
You are the Way 🎉 because you be the way
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.
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
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.
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.
Dude that guy invented game hosting. wtf are you on about?
@@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.
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... "
@@mikerollin4073yea, which was completely irrelevant to what carmack was talking about. But okay
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
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!
Haha, it still hurts
which part
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.
This was even better than the video. I understand now.
The difference is, you are a Webdev, Carmack is a real programmer...
now that's just brutal
Sheesh no need to attack me like that
😂
It’s the cloud, it’s not MY computer I’m crashing.
🤣
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.
Fully agree on games
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.
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.
@@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!
@@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.
It's AMAZING how few people, in general, know how to use debuggers and profilers.
Cus they're JavaScript newbs
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)
@@NathanHedglin A junior is a junior, language doesn't matter.
Is it just me or Lex comes across like a poser who only codes a little?
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.
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.
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.”
That sounds nice, but it is not generally true.
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
@@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
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..
For whatever definition of "cleverly" better fits the quote.
I can somehow imagine Carmack talking that fast normally, while simultaneously typing assembly code at the same speed.
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.
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 !
He used his keyboard
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.
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.
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?
Can listen to Carmack talk about games and dev for hours. I really miss his quake con keynotes.
i LOVED his huge keynotes... so so so good
This is totally gonna be the year of "Debugger-driven development". I can feel it in my bones!
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.
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.
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.
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
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.
"your head is a faulty interpreter", I like that!
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
Neither do I, Vim users are like Arch Linux users. They spend half their life configuring it and the other half re-configuring it.
🤣🤣🤣
No, that's NixOS users. I'd know, because I'm one of them.
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.
It's time consuming in both cases but you get what you order and that's priceless
@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.
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.
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
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
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.
Sounds like your debugger setup is inefficient more than anything
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.
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 !
@@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 !!!!
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.
Visual Studio proper has the best debugging environment on this planet.
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.
@@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.
@@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.
@@notuxnobux And those tools exist outside Valgrind as well. The profiler in MSVC is unmatched IMO.
I'm not on Windows myself, but RemedyBG looks awesome. Looks better than the debugger in visual studio. Did you try that out?
Logs vs debugger. It's not one over the other. Having and utilizing both allows you to write better code.
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.
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.
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.
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.
Interesting, I have an easy time finding my way when I change workspaces
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
Java also removes assertions in normal builds. Python does it too if you enable a certain optimization flag
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.
you can do all of that in vim as well
@@katech6020 not as intuitive as in vscode, I have try spectre the plugin and is good but it takes time to set-up
@@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 ?
@@ernesto906 read my other comment about the video suggestion about LazyNvim it is extremely easy to setup and use
@@katech6020 except when you are running Windows, it isn't quite that easy then
I spent my childhood playing Commander Keen. Carmack is my hero (second only to Prime, of course :P )
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.
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.
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.
I used CLion out of the box and it never gave me any problems
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.
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
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! 🤣
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).
@@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.
@@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.
@@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.
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.
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
That's why you use i3(sway) instead of alt+tab
You should look into auto tiling. Achieves the same but much more quickly and without the need to break your neck.
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.
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.
One Monitor to rule them all, One Monitor to find them, One Monitor to bring them all, and with keyboard shortcuts bind them
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
Still horribly buggy, but at least now it breaks faster
I just set up the toolchain to avoid using it, all in the command line!!!
@@marcs9451 What bugs are you experiencing? I literally never had any issues with VS so im confused when i read people say that
Sorry not installing Windows... Ever.
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.
It's actually nice to hear somebody who is not just so notoriously good but also notoriously *intuitively a step beyond* most programmers saying straight up that he's fucking things up non stop and knows his intuition isn't good enough. It really is kind of freeing to hear John Carmack of all people say "I entered the machine dimension and talked to the beings there and they told me use the debugger idiot your code is unsafe"
All the “skill issue” espousing C programmers probably feel attacked lol
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.
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%
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.
Already tried the New UI preview? It’s waaay less cluttered with buttons and menus out of the box.
@@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
@@TheMrKeksLp You can change to the slim version of it
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.
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
@@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.
Ooh you go big guy
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.
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
Don't assert in code unless you can remove them in production via compile flags or your pipeline. I HATE seeing asserts sneaking into production code. may as well put panic!("dees nutz") in all your rust and ship it.
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.
@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.
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.
Debugger is more powerful than you what say.
But you have vimspector with is a good gui for vim.
@@Mateus.007 I was replying *specifically* to his comment about stepping through code and seeing what's happening.
@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.
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.
Carmack has dropped doos that write better code than this codefluencer.
Great reaction, I discovered that I'm a single monitor. Camaron is a guy who mastered your tools, and it's ok!
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.
damm that sounds so stressing bro, sending strength ~
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.
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.
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.
When you brought rust in, you forgot to say that the stream is not affiliated with or endorsed by rust.
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.
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.
multiple monitors, prime you dont have to touch your keyboard to see something on different display. you just have to move your eye ball or head, which is very good for posture as no one knows for how long we haven't moved our heads while starting the display.
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.
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.
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.
The term "user friendly" is deceptive. It can mean "friendly for someone who's never seen this before", but it can also mean "really efficient for an expert to use". A piano has a very user friendly interface for a piano expert, but not so much for someone who plays the bongos. A bongo, on the other hand, is very user friendly for everyone. GDB is very user friendly for expert users. It just has something of a learning curve, perhaps more steep than something more graphical. So whether it's "beginner" or "learner" friendly is a different issue than "user" friendly.
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.
PREACH
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
Trying to make vscode act like vim is the same as painting you whole life with a paint brush, but then switching to pencils and trying to make the pencils work like that paint brush. It just makes no sense
24:27 I wonder if he is talking about Sean Barrett (he made/makes the STB libraries)
Probably.
It's always so wild listening to carmack. He's so eloquent and thoughtful on these topics.
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.
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.
The thing is my laptop isn't good enough to run jetbrains ide. It lags a lot
The best thing about good logging is that the customer, support, or operation often can figure out the problem and fix it themself without disturbing you.
If that's the case, can you have your code figure out the problem and fix it without disturbing them?
Bro we need a Lex and Prime colab
0:35 I thought someone spiked Carmack's drink with Red Bull for several seconds before seeing that Lex was definitely fast forwarded.
Mr Carmack is cleary speaking about the benefits of 🦀 !
He is just not pronouncing the forbidden word
because carmack speaking well about Rust(TM)(R)(C) (this comment is not endorsed by Rust Foundation) would be detrimental to their trademark
@@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
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!"
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.
I don't agree with all the people who say VS Code "just works". Like maybe as a basic text editor, but as somebody who uses JetBrains (primarily Goland), stock VS Code is just fancy notepad in comparison. If you want to do anything substantial, you have to install a bunch of plugins and do a ton of config and hunt options as you put it. And even after you install and tweak everything, it still doesn't do a bunch of the QoL things that JetBrains does right out of the box. For me, JetBrains tools are the IDEs that *just work*. I'd be curious to see Prime give Goland a try for either Go or TS development. I can't suggest CLion for Rust though because the proprietary Rust analyzer they ship is kind of awful compared to the community rust-analyzer.
Edit: should have waited to the end, he used IntelliJ for years, and I didn't already know that lol
Prime should be on Lex's podcast.
Lex is boring, very overrated.
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.
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
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.
honestly I think it is a triangle. Thinking about your code and trying to understand it is sometimes the best way to find a bug, and trying to do it improves your mental model of the compiler and the machine semantics leading you to write better code.
Knowing when and where to augment the logging and when and where to jump into a debugger are in my mind equally useful.
If you rely on only one method for bug forensics then some problem will inevitably arise where you are entirely out of your element.
There is always going to be a scenario where you forgot to log something or it is not reproducible and not visible in the log dump because of the wrong log level. There is always going to be a scenario where even in the debugger for whatever reason you can't find the right breakpoints to locate the problem effectively, or where using a debugger is not feasible.
And then you HAVE to be able to rely on your ability to generate theories about how the code can produce the observed symptoms.
It's a tripod people. People arguing about is X better than Y usually are missing the point that you should probably be good at both. I would generally take a well rounded generalist any day over an expert in one specific thing if I could only choose one of them.
Get good at as many things as you can, and get really good at one or two specific things you really like.
John Carmacks interview with Lex was great - but this idea that Vim users are just old-fashioned hold outs that haven't experienced the 'modern' IDE is so backwards to anyone who actually uses Vim. It just makes me laugh, but horses for courses, I guess
NVChad for the win
@@hansu7474 Besides, you could get VIM key bindings in a "modern IDE" as a plugin so you get the best of both worlds in big project development.
If you're just doing quick flip projects, I can see why people go for emacs/vim/neovim.
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
"Im gonna leave this...earth. both fleet fly thru space and they're gonna land betwixt your shoulders" was poetic af
Lock that guy I should
I think you just need to unlock his heart
@@ThePrimeTimeagen That sounds
like a good plan
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.
Carmack sounds like 1.5x at 1.25x lol
"Lay down my musket." 😂 Subscribed!
I'm 95% Python, a bit of C++, and I really don't like VSCode. I feel like Pycharm is just way easier to use, you just install it and it pretty much just works. And the debugger in it is just so good. I feel bad for the beginners who think that VSCode is the be all end all, and it's really an uphill battle. VSCode is in itself like a language you have to learn.
I've never used pycharm but i would bet it is superior to vscode for python just because it is a jetbrains product, and in my experience jetbrains ides are superior. but they also (usually) cost money, and vscode doesn't. you can get support for any language via the marketplace and you're rolling. it isn't like a language you have to learn, maybe writing launch targets and stuff is annoying but you can get by without that stuff
I 100% agree
Hey love your show btw, going back to your context there is a compromise called instrumentation bpf for production.. so hookup with Mr. Gregg and see how the community can push the probes-rs and or rust-usdt.
He doesn't like vim, he doesn't like rust but hey he's John fkn Carmack the guy who created doom in ASM 😂 but c'mon man I was using pacman just now and saw emacs has like 100+ dependencies vs Nvim/Vim where the former only has 3 deps the last I checked 😂
I personally use vscodium right now tho coz im lazy, but setting up clangd isn't too bad and the modern languages like rust, go & zig work well with vscodium & basically out of the box, I literally have only 4 plugins on my set up
What do you mean? John Carmack worked at Meta and was CEO of ID software. I think he knows what he is talking about 😂
I don't believe any single screen developers, probably lizards you all.
Just because I'm a lizard doesn't mean I'm not a person too
I've never enjoyed Fridman's interviewing style. Leading questions, and soapboxing a lot of his own thoughts while I'd rather hear the guest talk more.
So basically your whole channel is only you getting annoyed at people for not loving Vim and rust. Here's a good one for ya, who the hell uses either vim or friggin rust 🤣
Just a bunch of people who know and love what they're doing. You wouldn't get it.
@@flflflflflfl probably true bro. I literally couldn't care less what the language or ide is, I just learn what pays most
@@flflflflflfl People who know what they're doing use Rust? Gonna have to hard disagree with that. Definitely people who follow fads, but the percentage of people who "know what they're doing" (as measured by: shipped a ton of high quality, highly performant code), is vanishingly small, and I challenge you to prove me wrong.
@@VACatholic Well said
@@VACatholic Of course that percentage is vanishingly small, why would I even want to prove you wrong on that?
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.
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.