Carmack Doesn't Like Vim | Prime Reacts
ฝัง
- เผยแพร่เมื่อ 26 ก.ย. 2024
- Recorded live on twitch, GET IN
/ theprimeagen
original • John Carmack: Best pro...
author / @lexclips
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
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
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.
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
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.
🤣
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 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.
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
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.
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
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?
I can somehow imagine Carmack talking that fast normally, while simultaneously typing assembly code at the same speed.
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.
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.
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.
This is totally gonna be the year of "Debugger-driven development". I can feel it in my bones!
"your head is a faulty interpreter", I like that!
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
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?
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.
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
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.
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.
Logs vs debugger. It's not one over the other. Having and utilizing both allows you to write better code.
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.
One Monitor to rule them all, One Monitor to find them, One Monitor to bring them all, and with keyboard shortcuts bind them
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.
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.
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.
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
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
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
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.
When you brought rust in, you forgot to say that the stream is not affiliated with or endorsed by rust.
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
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.
I spent my childhood playing Commander Keen. Carmack is my hero (second only to Prime, of course :P )
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.
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
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.
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
If a production bug is reproducible, there is a lot of value in remote debugging. It allows you to attach a debugger to a remote process so it eliminates the need to recreate the bug locally.
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
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.
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.
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
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.
John Carmarck: use the tools, they are there for something.
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.
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%
You share the same keyboard? It's a good thing it splits in two.
Carmack sounds like 1.5x at 1.25x lol
One of the great things about computers is that teach us to NOT treat numbers like mathematicians do. An integer, in computers, does not mean every whole number up to infinity -1. Infinity is bullshit. All numbers exist within a range. Everything that exists, exists in a quantity.
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.
The part about keeping constraints instead of going generic can be applied to web dev in for example scaling. Instead of designing to always keep your systems running and scaling until it all explodes, why not just put limits on it? Limit bandwidth, limit connections, limit processing time, ... So what if you have 1mil users and an extra 100k can't use your website. That's better than having 1.1mil enter and take it down for everyone.
And a 2nd monitor is nice when you are debugging no matter which method. One screen is your debugger in the code or just your code while the other screen has your app running and log output. And then a 3rd screen becomes an extra to put your watch list, your app and system diagnostics, extra output streams, external tools, ...
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
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?
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.
"What did he work on?"
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.
Prime should be on Lex's podcast.
Lex is boring, very overrated.
I've never understood why debuggers are considered magical and advanced these days. I used them in college and as a junior dev. I still use them. I was blown away a couple years ago when a younger coworker told me he just does print statements and it made me wonder if I time travelled to 1985.
Carmack makes an excellent point of logging being real shit on compiled languages.
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.
At first when Carmack started speaking, I thought it was on 2x speed
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.
0:35 I thought someone spiked Carmack's drink with Red Bull for several seconds before seeing that Lex was definitely fast forwarded.
Carmack has dropped doos that write better code than this codefluencer.
@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.
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
Vim and Emacs were the two reasons my friend and I wrote our own code editor. It has a C plugin API, so you can write super-fast custom extensions.
24:27 I wonder if he is talking about Sean Barrett (he made/makes the STB libraries)
Probably.
logging properly is crucial when you work in a microservice architecture which is becoming more and more popular. You can't just locally debug a whole bunch of interconnected microservices that are talking to each other and different databases very easily
Lock that guy I should
I think you just need to unlock his heart
@@ThePrimeTimeagen That sounds
like a good plan
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.
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.
As a rider user, I just cannot use VS Code, it's too lightweight, where it just doesn't seem to be as useful as a full IDE. I'd probably prefer VIM looking at it if I could only use something like Code.
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
"Im gonna leave this...earth. both fleet fly thru space and they're gonna land betwixt your shoulders" was poetic af
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'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.
The way he sped up Lex to 1.5 while saying "to be fair to Lex" LMAO
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.
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 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.
The reason I like three monitors for work is so I can have a monitor dedicated to emails, one for vim / coding and one for a browser.
Great reaction, I discovered that I'm a single monitor. Camaron is a guy who mastered your tools, and it's ok!
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
I'm a horsesh*t man myself. That's probably the only time in my life I'll use that sentence.
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
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'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
But how long did setting up VSCode take compared to setting up Vim? 🤔🧐
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
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.
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?
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 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.
As an old dog developer who was beaten to death with TUI based systems because that was all there was. If TUI is even a term now days. BUT I appreciate the GUI based editors because I can "quickly" have more monitored stuff on the screen then the TUI systems. I'm not knocking all the TUI based IDE's. I've used them all and I can still get stuff done in them today. But I really enjoy having more of the stuff displayed for a glance and willing to sacrifice other performance areas for it. But like Carmack... stepping through code debugger is one of my processes... and the memory monitors are so much easier for me to look at stuff in the GUI based IDE. Yes, I know how and have done this in TUI. I just don't want to.
VSC is a weirdo. It's like TUI editor with all the setup required before it's useful... but it's GUI-ish. I use it as my primary editor for work, because I have to touch so many different technologies and languages. It's alright. But if you were already partial to VIM or Emacs, it would definitely seem like a pointless waste of time, just to have the extra weight of a GUI that doesn't give you much more.
It all really depends on your workflow. I pretty much change tools as I need to because how well they work with the flow of the job. Honestly I think the worst mindset for any developer is to get in a love affair with a developer tool that even when it's holding you back, you still go with it.