If you like sci-fi, check out my hopepunk podcast, Lost Terminal, at www.lostterminal.com If you like urban fantasy, I produce a wonderful podcast called Modem Prometheus: www.modemprometheus.com
Although the compiler does a lot of checks in Rust, this does not mean that unit testing is completely meaningless. We still need to test the correctness of the logic and whether the results are consistent with expectations.
I’ve concluded that “agile”, as implemented at every company I’ve worked for, is not really about software development at all. It’s about keeping developer’s noses to the grindstone every minute of every day. Sprint meetings are generally a waste of time, as I rarely have any reason to care what others are reporting, nor do they have a reason to care about my report. Estimates are not as much about planning as they are a means to earn demerits.
Hi there, this honestly sounds like a great thing I want to try out. My only concern is the flexibility of this time-schedule. Let's say I have to move my 20min timeslot by an hour, because of something important. Or if I want to / have to stay up really late (party, travelling, deadline, whatever). My complete core-sleep-time would be gone on that day (whereas with an 8-hour sleep time, I at least get some sleep). Is this rythm flexible at such scenarios? How do you manage situations like this?
Your explanations are so fantastic. I echo the request for a video with html templates with HTMX for interactivity (look mom, no JavaScript). Just exploring Rust, but it seems like the front end story would be greatly helped with a "just return html templates, with tailwind css and htmx for get / post behavior," similar to Jinja, Chameleon in Python.
what has made it most obvious to me how impossible perfection is, is simply looking back at old pieces of writing I worked on for weeks to bring to a state where I could no longer figure out how to improve it. in the moment, i could view it, read it, digest it, and feel, *it's done.* I could *know* there was nothing more to do for it. did I think it was perfect? in a way, yes, in that I knew there was no more work for me to do in that moment. but as I looked back on it weeks, months, years later, I pick out mistakes. I rewrite words without thinking, rephrase sentences to improve the flow, adjust the language to clarify an idea. I know nobody will ever read it again, but in that moment, *I'm* reading it, and I know it's imperfect, and I want to make minor changes while I'm re-reading it. the fact that I could come back to something so much time later and be able to instantly pick apart the mistakes and imperfections and improve it teaches me that perfection is nothing but a projection of the mind's satisfaction with a piece of work. if one can practice being satisfied with something that is simply *done,* one can find perfection in their projects today, and still recognize the imperfections tomorrow.
Consider compiler as a sort of assistant AI. Which never hallucinates, always correct, catches all of your mistakes, sometimes even suggests improvements.
Does someone know if there is a good alternative to the examples in the vid that don't use sucralose as a sweetener (any other sweetener is okay I just particulaely don't like the taste of sucralose)
Tbh I prefer using "Type driven development". In mathematic logic, a type is the equivalent of a proposition/theorem and a member of this type is a proof. Like an image is equivalent to 1000 words, a type is equivalent to 1000 tests👌
"So, at what time do you live? I'm alive past midnight in the clubs" "I live at compile time." "Oh? And how many did you 'compile'? Heheh" "Well, there was this beauty last night..." "And?" "Well... when I compiled I got an error not found..."
Maybe I just need a better example to help me visualize generically how this could be applied because that link which talks about HTTP requests seems convoluted and full of too much boilerplate, which kind of seems like a natural negative consequence of how Rust implements enums. For instance, if I were implementing a mechanism to handle requests, I'd put everything in that one class, and there would be no need to return different structs or whatever. This also kind of strikes me as one of the quirky flaws of method chaining because then you have to return different types to allow the chain to continue. Of course, since we're talking about HTTP requests, I'd probably just fill in default details and have functions to let the user replace the defaults or not if they shouldn't care. Certain things would obviously be an error, like a lack of target IP and so on, but there are things which the user might not want to care about, or shouldn't have to manually handle. For instance, one of the things about the example that strikes me as wrong is the status codes being passed as magic numbers/strings instead of having a set of enumerated names so the user doesn't need to know the actual status code, such as just STATUS_OK instead of passing (200, "OK"). And on top of that the content length being set by the user passing anything at all. That's one of those things that would never be explicit in such a library were I writing it because the user could pass the wrong value and that's a huge flaw, where instead the library should calculate it for you and set it automatically. The two examples he gives of where such things go wrong in C++ I agree with, but they're also kind of irrelevant. Sure, move semantics should probably be implemented better and more at the compiler level, but things like closing files really is better with RAII and it's just a matter of slightly modifying those classes. Of course, I don't agree that Rust actually makes these things easier or ergonomic as that code looks disgusting and makes me want to barf worse than reading STL code in C++.
I don't like writing unit tests, because they go out of date, models change we needed to get 100% coverage for the build pipeline, so it was some stupid tests that didn't test what they needed to. But man, I love the compiler and errors in there, I am all for CDD
To be clear, I said, "The compiler is faster than all these methods, but to be fair, and balanced, it's because it's doing less." I've written production lisp at a bank, I LOVE repl-driven development, but compiler-driven is SO much faster!
@@NoBoilerplate I'm not sure why you'd believe that given how slow Rust compiles, even when working incrementally. Every REPL that I know of can use the full width and breadth of the language, even down to importing modules, and thus iteration is nearly instantaneous because it's a simple matter of :w from the other window and the up arrow key followed by enter to rerun the import line again.
Thanks! But yeah. I've described this as "locking in" logical pathways, so that you can make a determination and conversion in one place which truncates the semantic space which is even possible to describe at later points. This approach is literally part of how I sleep at night!
10:34 First time I implemented typestate pattern was before I knew what it was called. I was generating C++ builders with a bitmask template parameter for required fields so that build() would only compile when all required fields are set. Most examples in Rust taught that this could be vastly simplified if I enforced the order of required fields.
1:50 We actually do run servers with debug symbols in production and, in case of Rust, with RUST_BACKTRACE=1 (although, I think it's been about a year since I last saw a stacktrace in production).
You're welcome to do what you like there, of course! There's quite a bit of granularity, not just debug/release - make sure you're getting the right mix of fast execution and debugability. I'd also prefer instrumentation (perhaps with tracing) to relying on stacktraces.
I think I've seen this typestate pattern used in some of the more elegantly crafted C++ libraries I've seen! and tbh I've seen it in some places in the standard library too, but that monstrousity has nothing more going for it in this regard
TDD kinda reminds me of generative adversarial NN's, where you have a generator and a discriminator each having the goal of catching out the other, self adversarial programing if you will.
The only laptops you should even consider buying are a 300$ chromebook if you just need light tier software or a 3000$ macbook if you need professional grade hardware. Like in my work meetings I am expected to actually show off my code, I dont have stable office space so I need to move around alot, at school I am moving every semester and frequently need to take my work to the library or a cafe to get peace and quiet, and also need to do code demos and such in class. By the time the 5 year apple planned obsolescence kicks in fedora should be good on m3 macbooks so Ill have a power efficient and solidly built laptop for portability and a proper desktop by then for computationally intensive tasks.
As always I appreciate the new views you give on “other sides” of programming I dont usually encounter in daily work. However I seem to be missing the point where CDD is asserting actual behaviour and outcome of code, instead of testing wether or not your program compiles and handles every possible case (also a good thing, but different entirely). Im sure if you want to *test and record the behaviour of your code*, you will have to end up writing tests still… or am I missing something? Thx to anyone to answer or discuss. Cheers!
Quite right, CDD is the first step - quickly sketching out the core model of your code. One should RELUCTANTLY move on to TDD and so on only after exhausting CDD!
Extremely unhealthy and not a good idea for anyone to try out. Sleep evolved the way it did for a reason, and you can fool yourself into thinking you can ' hack' nature but you will lose that battle. Unfortunately once you start developing Alzheimer's or cardiovascular disease and you think 'boy I should've just gotten a healthy sleeping pattern and a solid 7 hours a night' you're probably too late. I know this sounds appealing to many young people who have sleeping problems and think this might somehow help solve it or trick them into thinking it's totally okay to go on like 5 hours a day. You can' t cut out parts of your sleep cycle because they're less important , you need both REM and non-REM sleep. Please read up on sleep and what it actually does for you, and what not having good sleep does to you, before you start fiddling around with one of life's most vital functions.
While we agree about extreme polyphasic sleep, the data suggests that a siesta schedule, ie E1, is healthier for you than one big chunk of monophasic. Reality, as ever, resists simplicity!
That's silly to wait for more than 1 sec. If you have strong password you don't need the crutch of key stretching and if you don't have strong password in your password manager you shoud rethink your life prioruties
Thank you so much, that's really nice of you to say! There's not SO much left I want to say about Rust, but I'll certainly keep raving about features I love as I find them!
Not quite. There are type systems and there are type systems. Certainly, you can do the basics of the typestate pattern in any language, and it's a good idea. But there are powerful parts of the ML-inspired Rust type system that lend themselves to compiler-driven development. Here's one of my videos talking about some of the magic that the Rust compiler can do, I'd love to know what you think: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-voRBS0r4EyI.html
I wonder, how reliable this is for serious production use cases, how to figure out which pathes/cases are not safe/covered? Cuz if I cannot figure that out it means that all guarantees are void.
Using the type system, in any language, is 100% reliable, if it's not, it's a compiler bug. Rust's type system can encode far more information than other popular languages (such as, say, Java or Go), and so you can extend these 100% guarantees to much more of your code, leaving less requiring unit testing.
I practice ADD Attention Driven Development. Basically I follow my fancy until I get to a state that does not motivate me anymore. Once again great video.
ew, gross. Sorry reading the flutter docs made my eyes bleed. I THINK the main difference is all states are proven by rust at compile time, and no unit testing is required because the compiler proves that there are no possible invalid states in your whole codebase.
Just like the website you're typing in, the firmware of the keyboard you used to type, and the bios of the machine you booted to do this all. Why do you accept them? Because you get more utility than the freedom you give up. For me, Obsidian is the most powerful tool in its category, so I must use it for now. As I said in the video, though obsidian is closed-source, all its plugins, and my data is open, insulating me from the problems I actually care about (vendor lock-in, antifeatures, company bankruptcy etc). I will likely move to an open-source solution once they get good enough. Logseq logseq.com/ is nearly there. If you can't get over Obsidian's licence, try that!
