"we've been stagnated since 1996" Cobol has entered the chat

The other guy is breathing so hard lmao once you hear it you can't unhear it

Developer experience is easy to overlook in business

ARE YOU GONNA FREE THAT MEMORY?!

I think Jonathan is saying that programming is like art. First it is abstract and it slowly turns into something less abstract. You are working with the nuts and bolts. And i think for most problems he is right. You only see the best solution for a problem if you are looking at the 1st kinda working version of the solution to that problem. In modern languages you dont have or are not allowed to use all the nuts and bolts... I want to work on the problem not fight the programming language or read docs.

I expected to hear how exactly it sucks and how he proposes to solve it. Every time he stops short without going into details. Of course we know how it sucks for us but I wanted his take on it. Just saying sucks doesn’t move us closer to solving it

Personal experience here as a contractor, ymmv. Nowadays programming sucks to me because there's a legion of people ready to criticize everything I do. From the language you picked to why are you not using framework XYZ or why aren't you writing unit tests (or if you are why aren't you writing mutating tests instead) or not using this or that design pattern or not using this or that development cycle. I can't just pick a problem and solve it, I need to follow a endless list of disparated requirements, some of them perfectly reasonable and making sense, but a lot of them just to satisfact someone's else ego because was their idea. I am just fed up with all this bs.

It's 2024, not just languages, EVERYTHING sucks!

In business programming - the hardest problem is NOT the programming.

Memory Leaks are not a problem because you restart the game. Try doing that at a core business service handling a ton of cash. Maybe being a game developer does not grant insights into all areas of programming.

The real problem is that we’re inventing languages to make developer skills irrelevant, but we will never get there because unskilled developers will always find ways to f it up. We turned programming into a circus… There are a billion libraries for hundreds of languages written so badly that no skilled developer wants to touch or maintain them… The code quality slowdowns surpasses Moors’s law, storage capacities, and compiler optimizations with geometric progression… We need to start to differentiate coders, software developers, and software engineers…

"Just simplify your code" lol.

Carmack said your brain is a faulty interpreter. Hence rust isn't for geniuses who know in their brain that yes that snippet of code will behave exactly that way. It's for adhd, lazy people like me who don't want to optimize stuff but are forced to due to the rust compiler. It's not for geniuses who can compile the whole program into binary in their brain. It's for silly geese like me who wants to make some app and be able to be relatively assured that I won't get a call from my boss/client that It's memory leaking or the app is doing something undefined.

Can't wait to see all rust fanboys in the comment section explaining how awful people are for not using rust and not thinking it's the best thing ever.

The problem is that Jon speaks as though there's only 1 problem domain. The performance demands of a game make GC'd languages a non-starter. But PLENTY of applications for code can tolerate 100x the perfomance impact of a GC. The thing that can be frustrating about Jon is that he regularly demonstrates that he's more than smart enough to understand this. He points out that Rust is too restrictive for the fast iteration that games require. Exactly Jon! And C/C++/Jai has too much friction to development in other problem domains! We all seem to understand that what's important is the "shape of the problem" (a term Jon himself has used) but we seem to completely forget this when we start complaining about languages.

He's speaking mainly from a games dev perspective. Security and safety are extremely important for long running backend services.

I've listened the whole thing and have no clue what he tries to say

I like a lot of what JB says but it's really starting to bug me that he has way more gripes than solutions and gets so much more coverage than I would expect from someone that has only released two games in 15 years. Maybe this guy just likes to talk a lot.

to all people criticising jon, have you seen how bad modern programming is?

This dude needs to just shut up and build something like Linus Torvalds. Linus has given us Linux and Git without constant rants.

Blow seems to have the wrong idea about what Rust's memory management story is. It's not focused on ensuring you free memory (though it does have RAII heap allocation containers). It's focused on preventing shared mutability problems, like iterator invalidation, data races, and use *after* free.

Rust doesn’t give a fuck whether you free memory. Maybe it’s because it was cut from a longer session, but he was talking for over six minutes and said absolutely nothing.

Jon does himself a disservice with this whole "they aren't solving hard problems" thing. The actual point here is completely correct without the edginess: the tradeoff Rust is making is trading off iteration loop speed for the hope that they'll save time overall by "writing production-ready code the first time it compiles". This is mainly a pipe dream, but in the particular development environment Rust was designed in it may be the right trade-off to pursue. Maintaining a web browser is very different from making and launching a video game: web browsers are maintained for years, with features being added continuously, it needs to be maintained in a production-ready state at all times, and introducing any memory leaks is deadly for an application people leave open on their computer day in and day out. Mozilla is also a large, bureaucratic organization where by the time a developer is implementing something it has already been thoroughly designed and specced out, and the developer is on a strict deadline to deliver exactly that system as specified whether it's a good design or not. In contrast, if like Blow you are trying to iterate through a bunch of prototypes to figure out what the system should be or even what the game design should be, then obviously it's an incredibly bad tradeoff to spend any extra time getting "production ready code" for iterations you're going to throw away. Video games, very much unlike web browsers, are also basically launch-once products: very few features are typically added after release, usually just content additions if anything, and often that content is already built during development and simply gated as DLC for release for marketing reasons. As for the trade-off Blow is pursuing--to optimize for speed of iteration loops--many programming languages have pursued that trade-off, primarily in the interpreted language space. Only more recently have we seen languages that try to accomplish faster iteration speed without performance tradeoffs: with taglines like "the productivity of Python with the speed and safety of a compiled language". Go is probably the most successful to pursue that goal, but it is again in its own extremely specific development environment: servers for web services in the context of very large bureaucratic organizations. Game development is a unique development environment and will need a different solution. If Jai is trying to get fast iteration and prototyping while also achieving game-engine performance, that's definitely a fairly unique space to pursue in language design. Just because other people's problems aren't Jon's problems doesn't mean they aren't hard. For a man in his 50's he sounds like a total moron still pushing this adolescent "I'm the only one with hard problems" ignorance.

... As opposed to Javascript's mindset which is that no code is production code.

DO NOT REDEEM MEMORY SIRS

What is he trying to say? What's his argument? What is a hard problem for him?

I think the stagnation comes from focus on making programming more accessible, which is a good thing on its own, but it kills great ideas that might have come from wide adoption of heavily math based computer languages. Like imagine C, but in 1996 it didn't evolve into an object oriented language, but it instead all the focus went into building software almost as a series of mathematical statements. Kind of like if formal verification went on steroids in 1996 and it bore into creation widely popular languages focused on mathematics rather than the OO wave we had throughout the end of nineties.

Rust seems to suck the joy out of programming imho

I like programming (I pretty much do all stuff in managed languages). But one hard problem is always managing complexity. And I think this is the issue Jon raises. For example an RPG can have so many different systems to keep track of, it can be hard to try to keep everything in your head. And it can be hard to try to prevent the code from becoming one big ball of spaghetti. So it would be awesome if a language could help out here, in some way.

I agree with him. I am so frustrated with today's software and most developers and languages! We've go systems that are literally a million times faster (FLOPS) than what we had 30 years ago. And yet software feels just as sluggish but it consumes 100s of MBs for shit we did in 1995 with 4MB! And the features aren't increased either! Writing in Excel or Word feels the same as almost 30 years ago, but we consume 200+ MB and nothing is in the bloody workbook or on the bloody page yet! We didn't get 1000 times more features or 1000 times more speed increase. Hell even my Windows starts only 3 or 4 times faster -- and that's mainly because of my NVme. My Linux starts about the same speed but I am not doing anything more than I did in 1997. That was surfing and coding back then and it is still now.

I don't get the many complaints about programmers not being productive nowadays when you're doing nothing about it. Provide solutions and stop the constant rants 🙄

I'd be interested to hear Mr. Blow's take on this with a bit of distance from it. To me, it comes off as mere nostalgic. It sounds like programming was perfect when he first touched it because it was magical etc etc and that's what he's seeking, but it can't be found. Like people who just keep playing the same vanilla private servers over and over again. You'll, unfortunately, never be able to go to Ironforge for the first time ever again, or see the graphics go from 2D to Mario flippity flopping all over the place.

Every programming talk always say that the industry hasnt really moved forward fundamentally. However, I don't agree. Programming in modern times is far more delightful than trying to do it in 2000. It is different and we have better more refined tools than before.

There are some fundamental problems with Jon takes here, so, here I go. 1. On the matter of having "10%" slowdown For Jon, it appears that something like Rust costing a 10% slowdown would made for him impossible to finish his projects (like he said). While I agree that the time he would take is an important factor and that it is maybe true that could not deliver such a product with a 10%+ slowdown, I don't think a 10% or more friction will equate to 10% of slowdown in the code your write. Your brain can just accomodate with more friction and in this case developing your own mindset about the problems you are writting will integrate with this, so the slowdown can be much, much less invasive. The other question is about the flat statement on itself. While it can be true that Rust (or any other language that he dislikes on the matter) can "slowdown" him by 10%, he's stating it like that 10% slowdown will not reflect any other benefit with it that could result in a net gain, and this is a statement that he will need to prove (and it is not easy to do that). While it can be true that Rust can result in a net loss because it just "adds friction" and "slowdown development time", this is not an already proven statement and, in fact, Rust is knowed for having programs that generally "just work" when they actually compile because of the additional strictness of the compiler that will prevent a class of bugs and runtime problems (far from being just "memory-leak" things). If you take this in consideration, and the time you will spend debugging your code or trying to trace a bug that the language prevented by having this "10%" more friction/slowdown, then the time you where slowed down can be surpassed by the time you prevented wasting doing these things, so it would be a net gain. I think most of the time this is not a given thing, some programs will benefit from this strictness and it will really result in a cost-benefit situation, but some programs maybe not, but bold claims are almost every single time wrong and unreasonable, and they need to be justified and actually measured instead of speculatively saying "oh I would not be able to do it using X language because of Y". 2. Rust mindset is that "all code is production code" I don't think he was clear on what he wanted to say here, but I'll assume he's talking about the strictness of the language and type system over defining what is expressable in the language to say that the code that is written in Rust will have a "production aura" kind of thing. If this is the case, then first I want to ask what is the borderline between what is a "development code" and a "production code", I don't think this line is well defined, at maximum it is extremely blurry. I think Jon know the famous """meme""" in the development area that technical debt is normally 'never paid'. Simply because, feature after feature, delivery after delivery, the time to "ensure correctness of the code, fix the messiness and make a good architecture for your 'development code'" can literally never come, and now you are stuck with a shitty code. This was actually one of the problems with the forager (the game) development, it is a problem in many instances and legacy projects as well (I have touched codebases with 10 years or more that are literally a giant mess of "development code" stopped in time). So that line he's trying to draw of "production code" is dubious at best. For the second part of this, Rust is not so strict that you cannot write a mess with it, no language is strict enought for that. If you want to write shitty and messy code, but shitty and messy code that will still be safer and more foreseable than you would do in something like C++, then just use .unwrap everywhere, use Rc, abuse of constructs that will make the writting of the code so "direct" that you will not feel the friction nearly as much. And for the "programming being fun" thing, I just think he's taking things so much seriously and thinking so much about the "modern programming problems" that he's removing every joy on his own life, like everyone who tries to compare the present with their idealistic and perfect past generally do. And of course, Jon is a 52 year old man, so... well, take what you want about this. But in the end of the day, just take it easy, programming , that's why I'm a programmer for so long, and that's why I want to be a programmer for the rest of my life if I can.

It's just my perspective but he makes problem solving sound so linear. It's very perpendicular, and above all the largest problem is determining what problems do and don't need to be solved. He's much smarter than me so maybe I'm just creating subjection where there is none. But the idea of modern languages is both intuitive in that we don't have to solve old problems and counterintuitive in that we don't know as much about how to solve new problems.

3:18, whenever I'm developing alone, I understand every line of it. 5:43, I think using STL is a good strategy: use its containers, make aliases, and later turn them into something you want to deal (for performance, mostly), without lots of refactoring for its communications to outside the container. i.e. use std::vector, to later turn it into a static_vector of your own, for performance - if the compiler already didn't take care of it. The code will change only inside the container. So doesn't it matter how big is the project.

If Jon can't get productive in Rust, I definitely can't.

"I'm trying to make what would have been the next step in 1996." Too late bro, GNU99 standard is already out. It's not much of a progress, but it's an open standard. Build from there at the very least.

Yes his comments about freeing memory also for me is very easy, because I have static tool checkers, and runtime checkers, I really have no excuse for having application shipping at all that doesn't free memory properly. The difference is my apps are connectivity utilities and need to run 24x7

Modern languages: just = Just(); Just.doIt();

Nim seems to be interesting language with meta programming capabilities.

KZfaq needs AI so you can block recommendations just based on who is in the thumbnail…

0:14 I don't think Erlang came as a solution to a "simple problem" 1:18 Rather "it's important not to leak memory" I think the main concern is regarding security: poor memory management results in a lot of issues (ex. CVEs, cheating, etc). 2:04 Sounds like "just don't write bugs" 3:05 100% agree, that's why I think you should use a GC language rather than something with manual memory management 3:44 Agree, but this kind of features (ex. reflection), are better handled in GC'd languages (best example probably Common Lisp) 4:20 Rose tinted glasses. You don't miss the way you wrote code, you miss being 11 yo

If you know that hard problem you solve will be rewritten anyway, why not first solve it in a language that is easy to iterate in? Solve it in JavaScript, once you're clear on pitfalls and exceptional cases, properly rewrite it in statically typed, performant and memory safe language.

game programming may not be the best point of view for a language designer. what is a hard problem ? parallel, concurent,realtime with lots of variables, database, and inputs ?

It's all about abstraction and matching it with the maths I.e The sun ☀️ is a source , of light, illumination The moon reflects the light of the sun The moon orbits the earth therefore is prostrating to the earth , the earth orbits the sun therefore prostrating all these are relationships Rain is droplets of sustenance coming from above, ideas and thoughts that help develop something into practicality is divine rain ( rain upon the conscience ) Abstract is the key

js and shyton are OP, i see... we have REAL problems!

Give me a C with fixed sized integer types and primitive inheritence. I do not need garbage collection, etc.

Yep! I'm in that subfield.

Excuse-me. Memory leaks are super bad, super critical. Yeah, Johny 15 years old playing CyberPunk, will reboot his computer if he has too... but... When you're coding for a bank, server applications that run 24/7, repeat what you said about memory leaks plz.

i guess thats why js entering every space that shouldn't be in. its just so easy to whiteboard

I know let's make another javascript framework!

At the same time games are not important for humanity, in fact they are irrelevant, in fact if they disappeared we would be better off doing things that are useful. So no, problems in games are not hard. The reality of the world is hard.

„Soooo you are saying we are not supposed to be a geniuses and express your whole program in dependent types and monads with all corner cases and no memory leaks at first try or your program wont compile?? NNNnOooOooooo!!! „ - haskell and rustard fanbois, probably.

The phrase "If your code is too complicated to understand where you should free the memory just simplify your code" makes no sense. Code that uses smart pointers can be many times simpler than code that doesn't, thanks to the smart pointers. Automatic memory freeing is a powerful tool to write good maintainable code, just like structs, functions, traits, etc. Game development is different than other kinds of developments. The phrase "Rust's mindset is that all code is production code" makes no sense. Development is greatly simplified and accelerated by compile/write-time validation of the code. All code is intended to be production code. Rust helps you reach production code faster. "When I was a kid I wrote a game that sucked and I was happy, now I'm a professional programmer and it sucks". I have 17 years of C++ experience. Yeah, it sucks. I have almost two years of Rust experience. Programming doesn't suck anymore.

jon is a bit stuck in his own bubble bc there has been many projects, including languages, that try to solve the parallelism issue, and a lot of strategies for green threads. It's just that they are not low level system languages, as automating that while still giving control to the user is very challenging. I guess Rust is the only one that tried stuff for that , like making threading safer, and async features. too bad Rust is garbage

What are the specifics? What are the problems you need solved? Ok, you don't care about memory leaks, but what DO you care about? 'I don't understand how my program works' is not a language problem, sorry

This comment section makes me fully understand why people like Jon always turn off comments in their videos.

Totally agreed

Muhaha... started programming at age 12, still doing it every day at 50+... me too! 😀 But got to the stage of "programming sucks" ~20 years ago so now I work on hard problems and enjoy it. But if you think wavefront computing is "new", better look up Ivan Sutherland. Start with Alan Kay explaining who he was, _then_ check his "How Quantized Should a Digital System Be?", otherwise you would click away in 30 secs because _he is hard._

Perhaps it's worth simply adding more visualization to the programming process? Programmers manipulate abstractions in their minds to implement code. However, what if the code(environment) itself were to assist in this, facilitating abstraction work?

Jon blow is probably the only human being alive that can bash garbage collectors for impacting performance and in the same breath say that languages need reflections...

No general purpose language ever solves hard problems...

Sounds like blow should try Zig instead of working on Jai

I had this compiler written in c++. I never freed anything. Why would I? Such a tool does one job and immediately exits. Memory leaks are only an issue if you risk running out of memory. Typically, when you keep on leaking in a long running program.

It sounds to me as if he only cares about how fast the code is written. But don't be surprised if that mentality leads to an insecure, untestable, unmanageable mess that everyone will hate working on & will need to be rewritten completely from scratch in 1-2 years.

The entire point is that rust and other higher level languages makes programs more simple by being able to express things more easily and the compiler helping you. It doesn't seem johny understands this.

Christ he got it very wrong. Creating bad code first results in bad code out the door thats a fact. The reality is when the budget and time pressures hits guess what gets chopped? thats right, that last tasks of the security & code rewrite. If you’re wrapped over the knuckles every time you create bad code: you get good. Your patterns change and your performance increases naturally with experience! It’s not a sustained problem contrary to his preference of constantly creating garbage.

So fucking true

Rust absolutely sucks for that matter. As powerful as it is, it is time-consuming to write anything, and requires full alertness at any given moment you're typing, thus reducing the barrier of entry both on the population and the times at which you can feel confident taking up your Rust project. Just imagine managing the state of a full game in Rust.

I'd like it if they talked about the real problems and didn't dismiss all language developent in the last 20 years.

"Try to solve the problems that are really hard". That absolute statement makes no sense unless we are talking complexity classes (as in P vs NP). What problems are "hard" in your setting? Making sure the nuke plant behaves correctly and all loops terminate provably? Making communication between software agents manageable? Making the user interface actually usable and discoverable? Generate pixels really fast? But yeah, C++ is the optimally bad language for everything.

I would love it if a "speaker" like that came with an actual proposition for enhancement of x, y or z language. Ok, so GC is basically useless but complexity should be resolved : show us one way it could be done, instead of saying it shouldn't be like that. Because if you don't have a clue about how it could be resolved maybe you are not competent enough to say that this other problem should be ignored in favor of that one.

However severe or not you think memory leaks are it still stands to reason (and data) that the earlier you squash bugs the less they pile up later in development. We see this with the Sea of Thieves devs who, before that point, were responsible for Banjo Kazooie Nuts and Bolts. They did this through tests, mind - outcomes matter more for a lot of things than the sorts of checks the rust compiler is giving you - but even as a "super genius programmer" you have to pick your balance of performance, scalability and security.

A better approach to what C++ attempted to do are actually layering a scripting language on top. (Pick your favorite: Tcl. Perl, Python, Lua). And oddly enough Tcl, Perl, and Python were all in common use by 1996. For that matter, BASIC is also an interpreted language. And BASIC is older than C. We need a toy/DSL language that frees us from the petty details, and a deep wizard compiled language that lets us write optimized routines and low-level device drivers. Any language that tries to do both has been failsauce.

He’s 100% correct.

good

Rust is a joke!

Memory leaks are fine! We'll fix the problems later! I don't need to write clean code! Code faster! ...wait, why can't I understand my code? That doesn't come across well. It sounds to me, not a game programmer, that games need better frameworks, and domain-specific languages, rather than borrowing C, C++, C#, Rust, Python, or anything else from the developers that know you can't fix memory leaks and race conditions later.

I like this guy, seems to have a common sense attitute to programming. But I don't really understand his objections to moden C++. Sure, multiple inheritance often result a mess, but STL? That is the complete opposite. That heavily reduces the mess, by not forcing everyone to invent the wheel over and over again and waste time implementing sorting algorithms for the millionth time.

Elegant objects and the true encapsulation the answer

Dennis Ritchie made C after making B and UNIX. Chris Lattner made Mojo after making LLVM, MLIR and Swift. Blow even has the audacity to make fun of him... Jon Blow makes Jai after making Braid and The Witness claims it's gonna be better than anything out there, he also mentions many times he'd make a better OS than Windows (because the bozzo thinks Windows is better than Linux) but he doesn't have time LOL! Who's BSing you? If you've played Braid and The Witness you should realize who's trying to scam you, or who's playing a character since the Indie Game documentary, is kinda sad he has legit people who thinks he's capable of pulling this off. Odin and Zig have better origin stories and teams with people way more capable than Jon and his team. But you do you homies, my guess is that you're probably too young to detect this grift.

Jblow is again right. Modern software is just an organizational tool to scale up the software industry. Politics, essentially, but for people that are specially bad at politics and socializing. (Programmers)

I love the authority Jon Blow speaks, one, if not educated, would think he designed many languages... But honestly, he just doesn't have the credentials for this nor the knowledge, and makes PS2 looking games in 2024, you don't need a new programming language to solve that, just use UE5.

Boring and generic talk

The problems he's describing aren't language problems, it's architecture design and process problems.