C99 support on windows is not so bad. For one, you do not have to use msvc, you can install clang for windows. And C99 is very usable with MSVC, only a few niche features like complex numbers or VLAs (which are a bad idea anyway) require workarounds. Especially if you separate operating system dependant code and use the WIN32 API directly it works fine. But if you want to use the C standard library on windows be prepared to endure some Microsoft silliness (CRT Warnings, having to compile a manifest file to use the narrow API functions with UTF-8, stuff that is handy on unix but missing on windows) As you mentioned you would be reimplementing standard library features anyway to work around C's questionable defaults (Null terminated strings, errno, undefined behaviour in functions like isdigit, inconsistent APIs), I doubt you would have many issues writing C99 on windows. C99 improved a lot in recent times and even C17 like _Generic are implemented in MSVC, I think that people who say C99 support is bad on windows are programmers who have not tried it recently, came from UNIX and expected some things to be there or really like VLAs.
I do agree that VLAs aren't a feature you should use very often. I stand corrected about C99 on Windows and I'll keep that in mind for the future. I would probably like to try it and see. I think the "solution" of going through CPP files was decent enough, though, but I'll be honest that I'm obviously hand-waving here a lot.
Yes, a traditional installion of clang relies on MS build tools. But my point is, that you can use GNU C extensions and attributes, as well as Standard C features like C11 atomics (only very recently also added in MSVC), VLAs, _Complex, etc. if you need these features. If you do not want to use MSVC build tools you can use MinGW gcc, or zig, which is basically clang but it is using the gnu linker and libraries. The reason why I like clang on windows is partly due to it relying on windows build tools, your headers are always up to date (e.g. My gcc install did not have CreatePseudoConsole Or the ioringapi though I admit it was gcc version 6 because I downloaded an old version). Furthermore I prefer the UB/ASAN sanitizers, error messages of clang vs gcc. (PS: I could not link a program with gcc on windows with ASAN, though MSVC and clang worked fine.)
Thank you so much for making this. First time in my life someone on youtube actually cared enough to give me that kind of detailed answer to something I asked.
@@mccGoNZooo I think videos that do the best is when you explain by contrasting a concept or a process to get your point across. I would love a video on error handling(if this subject is not too boring for you) and you compare how multiple languages do it and put them on a spectrum. From "meh" ..to "the best one for me" . I know Odin is the winner but I'm definitely interested in the nuances and your thoughts on where the fancier Haskell, Scala and Rust sit in your mind. I'm just a low IQ scripting language user and more of an amateur programmer and I have so much to learn on how Odin, Haskell, Rust approach these topics. I am slowly learning about Odin because of your videos. If you weren't opinionated about what you like about it I would have ignored it and just limited myself only to Zig.
I am going to think about this and see what I can come up with. I have some ideas already, so I think I can get something done fairly soon. Thanks for the suggestion! :)
Have to say I agree about Rust- it has some things about it that seem nice, but every time I dig deeper into them I get frustrated and disappointed. I was hoping its type system would be as powerful as an ML or Haskell but it seems like it just has the annoying parts without some of the most useful ones. Honestly it feels like if they made a new kitchen sink language like C++ with the complicated ecosystem and package philosophy of JavaScript/npm.
I 100% agree with the assessment that they basically just created a package-driven development language for systems programming that rapidly is getting as complicated and arduous to use as C++. Anything in that type of direction of preferring complication "because you need it" has lost me entirely as of late and I'm convinced at this point that simple(r) is pretty much always better. There is a limit, of course, but I think the only ones who are even remotely close to that limit at the moment are Odin, Zig and Golang. Most languages fall on the wrong side of this and should be stripped down to far less than they are currently. With that said, I should mention that I imagine Odin to be endgame for me; I'm tired of learning languages and I don't see the point anymore.
Always been a fan of c++ and use it in unreal engine every day, but recently odin piqued my interest. Seems like a great language for programming games , especially with the curated vendor library. Your channel was a big help in getting me started.
Thanks for the honest assessment of these various tech stacks. I have similar views on Rust, I see it as a huge step backwards that is basically taking all the bad things about web dev / js, that make it popular.. and trying to apply that to systems programming. I don’t see anything good coming out of that longer term. At worst, we get a whole generation of newer programmers who bring bad patterns of thinking from web dev into critical low level systems. It’s a train wreck waiting to happen. Thanks for the heads up on ATS too .. first I’ve heard of that, looks interesting
It's an interesting scenario; when you give yourself the freedom to do precisely whatever you want. It's interesting also that I consider CakeLisp for that scenario because I do write a fair amount of my own code and nowhere in it will you find any macros or other interesting things.
Maybe I can articulate the Rust to Haskell thing since I lived it very recently and this is what I thought folks were referring to. I think it's safe to say that some functional programming ideas are more prevalent in many many languages and it's really nice to solve some problems with basically a map filter reduce pipeline style. I liked that fireship joke. Anyway, I recently wrote an Axum web server (A common Rust web framework) and when I got to a point where I was ready to launch I realized since I had recently also wrote a Yesod (common Haskell web framework) Haskell web server that a lot of constructs I wrote in Rust looked just like Yesod in Haskell. To say that the language is a lot like Haskell is a bit of a stretch I think it's more almost just a moment where you realize that writing these abstract functional pipelines eventually leads you to what Haskell looks like when that language solves the same problem. Is it ground breaking well no but is it cool and fun to bring up sure.
It's a fair point that there are themes that come about because yes, once you do Haskell-like things you inevitably end up doing something that at least sort of looks like Haskell... But I think people stretch this stuff a bit far sometimes and it seems a lot like some odd sort of attempt at gaining FP clout when some of the Rust people talk about this stuff. In any case I think a language is likely better off *not* having Haskell-like things in the end, or any FP-oriented constructs at all.
I really gotta give Odin a try. So far I've mainly used Rust in recent years but I still don't like the overly abstract features like traits etc which tend to force countless annotations everywhere and simply make everything more confusing. This isn't an issue for my own code but in my experience devs use whatever the language offers and so a lot of third-party code ends up near unreadable and really inflates the compile times. Zig is a great language on paper that alleviates those issues in a really elegant way, but I think its error handling is just too limited and some decisions in terms of syntax feel unintuitive to me, sometimes it feels like they did things differently just to be different. Same with the insistence on throwing a compiler error for unused variables/functions. Meanwhile Odin, like Zig, seems to also include efficiency oriented QoL features (native bitsets etc), and a quick look already showed a few improvements over Rust's design. So many new interesting alternatives to C and C++, I get the feeling that many people really are ready to look for something better.
You're not alone, I think that Rust is bloated mess and it wont get better as time goes by, because corporations that providing founding for project want constantly more fetures.
Indeed! I wanted to highlight some lesser known languages because I feel like they are more unique and I could definitely see myself using them or something like them in the future.
@@mccGoNZooo can you please namedrop the ones that were candidates for this video but were replaced? ATS and cakelisp are a very curious discovery for me as well!!
Did you land on one yet? My personal vote would go towards Odin, but this depends a bit on whether what you're doing is something you're going to need a ton of domain-specific libraries for. Most problems are in fact *not* that, but this also depends on how ready you personally are to implement things yourself.
I'm happy that the video struck a chord. If you haven't already, I think considering what you wrote here you might like Odin as a language and especially the general behavior of people who write Odin (i.e. not as many libraries for a project, if any at all) and much more focused on just "doing the thing".
About Rust: it took you only 2 seconds to compile? that's nothing! at work, if you change one line of code in any of our rust projects, it takes about 45 seconds 😂. but yeah, you explained perfectly why I don't like Rust either.
Heh, yeah, that's awful. Keep in mind this was 2 seconds in a sub-1k line project, so a very clear early signal that stuff is messed up. Happy to hear that the video struck a chord. :)
Hello Rickard Andersson, great video again, I found very useful to interiorise and share with fellow programmers the video "How I programme C", it's a incredible video and the link to it's libs make a really interesting code to study, like a master class kind of thing. And I also have to check cakelisp, sounds interesting. I'm also a user of Odin. maybe one day you should do a "How do I programme Odin" 2:30 H kind of video :-)
Yeah, I really love "How I program C" because it's so straight forward and it doesn't talk about any fluff, really, just the practical reality of using C in {{CURRENT_YEAR}}. As for my own video on this, possibly in the future when this mountain of code might be a bit more of a mountain and not a hill, but we'll see. Certainly we have a lot more videos in us yet, so we'll probably do interesting things. :)
Take these kinds of videos for what they are; it's very hard to get a reasonable perspective on a language by proxy. I would obviously say that if you find yourself in the same situation as me (writing your own code) Odin is a good choice. but use it as a priority list more than anything else and see what you feel yourself.
Helpful video, I'd add Ada programming language, different, with the performance of C, used in satellites, hardware, etc. you can have formally verification of your program as well.
Yeah, Ada was actually an unfortunate casualty of the 10 programming language limit for this video. I would've talked about it otherwise, because I do think it's an interesting language, but in practice it is a language that always exists in the background but never makes it to the foreground for me. I tried out Ada for the first time in university and it was the first time I tried a "When it compiles it works"(TM) language. A very interesting language indeed.
Extremely curious to hear if you stumbled on V or tried it too? What you said about Nim's unreadablity is 100% what I feel, and V absolutely changes that. Its fast, small, all tools baked in. Would love your thoughts on it!
Haven't used it, it was wildly overhyped and proven to be completely broken very fast. This led to the creator making some very questionable posts on the Internet and I think this kind of soured a lot of people on the language, myself included. On top of that I don't think there is any real upside to using V over, say, Odin. At least this was the case last I checked.
The reason why D's standard library is not usable without GC is that it uses exceptions for error handling. And exceptions are classes so they are allocated with GC by default. If you dont really care about GC when things go bad then you can still use it
Is it actually that clear cut? They must have cleaned up a lot in that case because it was certainly the case before that there was much more to it than just exceptions. You'd never actually use exceptions in BetterC mode which would be the only real way to use D, IMO.
It's interesting how you see a bare bone low level linear type programming in ATS as a future. It's clearly a trend to "hide" raw linear types behind syntax/abstractions (Rust as an example) because it's very hard to use linear types directly for general programming.
I think maybe this is mostly because I've seen what Rust turned out to be and it's scarcely more interesting than C++ with RAII, i.e. it's basically not useful at all. I think it's clear at this point that that design was a dead end and that it's probably more useful and will yield better results to expose the actual proofs as values for the programmer. With that said there's also the much more obvious alternative: Leave both of those paths entirely and just use a much less complex language and set of tools to get better end results. That's where I personally am right now and probably where I'll stay mentally for the foreseeable future.
Really interesting video. Ive used rust professionally for almost 2 years full time. I completely agree with compile times and the Pin comment! I remember when i first encountered it to buffer a stream, it took me a whole day to figure out how to do it! And i was experienced by then (but maybe im just dumb). But i do really like Rust, the type system is incredible IMO and yes it's verbose i still think it's great. I programmed in C and C++ many moons ago (especially C so i dont really remember my experience) and to be honest C++ was a nightmare compared to Rust. I've also dabbled in Zig, i do like it but you know you grow to like what you do and Rust is low level enough that i can think of the assembly it produces, great video
I think I would've liked Rust if it had more of the things I needed because at least I could tolerate the rest of the language in that case, but given its objectively lacking and lagging support for custom allocators, etc., it's just not as relevant as the rest. I'll be honest: I also prefer unsafe-by-default when it comes to writing foundational things, or maybe even in general. The way I see it I have both better higher-level languages and better lower-level languages than Rust at my disposal, so it doesn't necessarily fit in anywhere without making huge concessions. It's kind of like OCaml in that regard (for me). As for C++ being a nightmare compared to Rust; C++ is a nightmare compared to most languages in some regards. As soon as you have to deal with dependencies, builds, error messages, etc., it's bad. For me, solo, I think it's probably still better than Rust... Fortunately I don't have to use either.
D is a gem of a language, but history has not been kind to it. I think D is one of those languages that would do extremely well with a group of certain people with very clear guidelines for how to do things. I also think those people probably should construct a solid way to use custom allocators, or maybe I'm underestimating the standard library allocators a bit. Last I checked they weren't great to use. I also think using `-betterC` as a default might be viable for the type of team I referenced above, which makes D a much, much better language than without it, IMO.
Tried to reply on your comment below, but also removed, don't know why. I thought the original comment was auto removed because it contained what looked like a link, but now I am totally confused. Anyways, I am an old school C person, its simple yet powerful, and C3 is trying to keep a much as possible from C but make it more modern. I totally agree with all your comments, and I am almost sure that you will like C3 philosophy too. They have a channel here called C3Lang", please check the talk Why build the C3 language, and let me know about your opinion, possibly another great video like this one.
I don't know why the comments aren't being posted; they're not in my "Held for review" section either. I'll check the video out and see what my impression is and probably get back to you in a reply. :)
I liked the talk and I like the ideas behind C3. I think it would definitely be in the conversation had I looked into it more previously. I think it's unfortunate that the videos otherwise on the channel aren't showing things like the output from the programs, etc.. I checked their issue tracker and am happy to see that tagged unions are being considered as well, which was something I was missing from the C3 website material.
@@mccGoNZooo maybe, once they add tagged unions, you may consider a live stream to reimplement something that you have already implemented in Odin using C3, so we have your impressions. I would also encourage everyone to star the repo and +1 the tagged union issue too.
just a counter argument on your remark, that you cannot Crystal seriously for real work because of the missing Windows support: It looks like the backend of Kagi Search is written in Crystal
Just to clarify, the "Not working on Windows" thing was when I was checking it out quite a while ago and does not represent any opinion I hold now. Like I said in the video, I think a lot of what they've done is super neat in terms of providing a good natively compiled language with OO features, etc., and I think Crystal is neat. I just have no personal use for it, so that's why it's not something I use.
I'm deep in zig right now, thinking of making it my go to language. I haven't tried Odin yet and this video peaked my interest in it, but I have a feeling you talked too much about why Zig is good but not enough why Odin is better, and I would be really interested in the "details" you skipped. Great video nevertheless!
The things that Odin has that Zig doesn't is much better error handling (which I did mention, but I don't think people see the actual gravity of), a much bigger standard library (at least from what I remember of Zig) that covers more bases as well as a vendor library that gets you very far in terms of rendering and game development. On top of that you have array math built in, swizzling, etc., which comes in handy whenever you have to do anything that touches on matrices and vectors. Personally, a sizable portion of my code is error handling and I honestly wouldn't go back to Zig to use that error handling over Odin's even if the gains were bigger elsewhere. It's incredibly tedious to only have error codes and have to bubble up values separately from them and once I realized how well everything fits together in Odin I really couldn't stomach C, C++, Zig or Rust when it came to error handling at all.
You said Rust has very few of Haskells upsides, what exactly are the upsides of Haskell? I am very curious the answer of an Odin programmer, because whenever I tried to figure it out it seems people just want the math like esthetics and don't seem to care much about building real things.
It depends on who you ask, of course, but in my book Haskell has a very distinct edge in anything that requires multiple threads and shared memory. It has transactional variables/STM, which allows you to treat memory as you would database values, i.e. with transactions, rollbacks, etc.. None of this requires the swamp that is Rust's `async` hell. On top of that Haskell does, if you are willing to get into it, have a compile-time only constraints system that allows you to very, very tightly control exactly what effects functions can execute without bothering with ridiculous things like algebraic effects. If that's your jam, Haskell will provide that safety whereas Rust cannot in any reasonable way do the same. Haskell is a better imperative language than most, and using mutable values in it is better than in most languages, IMO. Personally I'm much better off using something like Odin nowadays, because I think it just hits the right notes and makes the right tradeoffs for getting stuff done, but Haskell is a very reasonable language for getting stuff done for the most part. The only parts that annoy me greatly are error handling (which Rust doesn't improve on, by the way) and some slice of the community that doesn't appreciate that the language is only there to facilitate getting stuff done (where Rust is even worse).
One thing I like about C++ is that you can declare types on the stack and have them be destroyed at the end of the scope via the destructor. What does Odin use for this pattern? I think they have a memory arena as part of the context and you add it to the that, right? Then you need a simple stack allocator to get the same kind of performance as declaring on the stack itself. Seems like C++'s solution is easier to use actually and more performant probably.
All variables you declare and use in a function are going to be on the stack. If something is only on the stack it needs no destruction because the stack is always pushed and popped to in each function call. What you're thinking of is automatic calling of destructors at end of scopes (RAII) which is only relevant when resources need to be managed beyond the stack (file descriptors, heap memory, locks, etc.). If we wanted to have something happen at end of scope we would use `defer do_something(...)` and it would happen at the end of the current scope. You can see this being used in this video: ruclips.net/video/bJUnCXEIie0/видео.html At no point in any high-level language do we need to clean anything on the stack up; that's done for us. C++ and Rust both encourage one-at-a-time thinking because they both expect for resources to be managed ostensibly for you, but there is no good deterministic way to have that happen in bulk like you would get with a bulk memory allocator that you free all at once (an arena). The best solution in C++ if you want to solve that problem is to use `pmr` or have your own allocators as far as I know. The best solution in Rust is to switch language since it has terrible support for custom allocators.
@@mccGoNZooo ok I think zig is doing the defer call thing too. This is a nice feature for sure but it's an extra line of code and thing to remember if you just want to keep something alive for the duration of a scope.
I had this experience with an elixir shill on ThePrimeagen server. Dude was so toxic I couldn’t help but leave. Anyways, I think not all “official” channels are toxic. r/golang for example has some of the most chilled out folks.
There are official/big channels of communication that don't devolve very badly, yes, but I think there is a general tendency in these types of places to build up a cult-like feeling around the language. I've seen it in both the small and the large, growing over time. It can start out as innocent "Guys, I can't believe this language is so good!" type of stuff and with enough of that you very quickly get this tension between legitimate gripes (usually from people who have used the language more) with the language and the overenthusiastic beginner type of opinions. With that said I think Go and Odin have a very long lasting feeling of joy because they both have a very fundamental joy of simplicity to them, which takes you much further and lasts longer than just "Wow, this particular thing is so 'simple' in this language!" type stuff.
Hi! I'm a Rust developer and I was interested to hear you critique. It does sound like we think differently. I like creating abstractions because they allow me to eloquently solve the problem. In addition, they help me understand the code of others better. I can accept the N seconds compile times because it does many checks and other useful things for me. I love many small libraries where each solves one problem well. And I'm happy when my libraries use other libraries because it makes the most important libraries heavily scrutinized. I a bit dislike Rust's Pin type as well but for different reasons. I'd love to have a way to construct an "immovable" T on the heap. However, this level of control is great and I love how I can get as much control as I need while taking as little control as possible by default.
I think Rust offers too little control over things and replaces it with song-and-dance type development where the type system and Rust-isms have to be satisfied more than anything else. I've seen plenty of posts by people doing for example embedded development in Rust who feel the same way, where the abstractions are more for Rusts edification than actually solving the problem. And yeah, the rest of it sounds like we just have fundamentally different views about what's difficult in software development. Many small libraries to me is a nightmare and I don't gain as much as you do from them; they usually represent a liability and time cost more than any kind of savings.
In Rust I've written a tokenizer + parser for a language, a service for logging (the one mentioned in the video), a RSS autodownloader for torrent files and some random CLI tools. Nothing big, really, but enough to know that I don't find it enjoyable. I hope it was clear from the video that I do think there are other people Rust is for and a lot of them will likely have the opposite experience and opinion to me regarding both Rust and Odin.
@@mccGoNZooo No worries, I am nit offended. I am very interested in Odin but find it hard to justify using it since I am not a veteran programmer. Rust's safety wheels make it a gentle, if a bit frustrating, first dip into low-level programming. That said, I did not understand rust at all until I learned the basics of C.
I wouldn't worry too much about not living up to some level required for writing Odin, to be honest. Don't let that stop you in the long run; just jump in and create things. With that said, do the thing that you enjoy the most at the end of the day. Life is too short to worry about what you *should* be using or not. :)
@@mccGoNZooo I disagree with that philosophy. Programming is fun but at the end of the day it is a profession. At least in my case it is a means to an end and while having fun along the way is good, and may contribute to code quality and productivity, it is secondary to acheiving the goal of profitable software. For now I am betting on Rust getting me there better than Odin, but that may change as my aptitude and understanding grows.
There is a time and place for everything, but learning is hard when you don't have fun and can't maintain an interest. The easiest way to learn a lot is to make sure you find something that is actually fun, or find the fun in something productive.
That's probably a reasonable suggestion for people who are stuck with Rust, but I think there are better directions to pick as base defaults in the end.
This is super helpful and I found I have some very similar opinions about most of the languages especially Rust was spot on. :) I also came from Haskell but I probably have done more Ruby/Javascript but a lot less C++. Currently I'm actually developing mostly in Zig and I only know about Odin because I met a friend at Handmade Seattle who recommended Odin to me. I also saw Ginger Bill at the conference as well. My biggest question is for someone who's versed in Zig, what does he/she gain by going for Odin? My take away is 1. error handling 2. simplicity but you'd lose comptime. Does that sound about right?
A video on this premieres today. :) In short: - No comptime in Odin, but we get some of it back with `when` directives - Error handling is nicer in Odin to someone with experience in Haskell or other ML derivatives (most likely) and you could argue makes a slight bit more sense - Odin tries to maintain clarity while allowing some select areas of implicitness whereas Zig overall tries to maximize explicitness (zero-value initialization is a guarantee that allows us some implicit things, `context` is another one. Both are clear in what they do, but enable less verbose code.) - No "functions as methods" in Odin, we just have data + functions.
I haven't tried Jai but it's not really relevant to me as long as it stays in closed beta. It'll barely be relevant as an open beta, to be honest. We'll see how I feel when it's generally available and I play around with it. Things I'm looking forward to trying out are some of the stuff you can supposedly do to write programs that take your programs as input. It seems like an overall much better idea than macros in the case of program analysis at least; I like the idea of very easily being able to create project-specific linting rules and so on.
I've only looked Hare very briefly and it doesn't seem to have any concept of custom allocators, which makes it very awkward to use and makes me question the users' and creator's familiarity with the concerns that I usually have with systems level code. It's not a good look for any language that wants to make memory management sane and possible to make fast and efficient. Z I know nothing about. The list of languages is not exhaustive; there are plenty of languages that I simply didn't bring up because they're not worth bringing up: They're either not interesting enough to really talk about in a video like this. Hare strikes me as that kind of language; it has seemingly no benefits that aren't already in languages in this video.
@@MrApplewine I looked at V around 2019 and the unfortunate reality then and later was that it was sold as something it really wasn't; the compiler would produce code that had memory leaks for even the most basic of things while the claim was that it could somehow solve that issue on its own. All in all I would say V seemed to be a lot about perception rather than reality. I've also never seen anything from it that would make it actually better than Odin or Zig, so there really hasn't been any reason to "see past" these obvious lies and half-truths to see whether there was something actually useful there.
@@mccGoNZooo I see. What do you think about C-Odin, or "Codin" the Odin to C compiler written in C? I just watched a the video on C-Odin by Dale Weiler. The 3 main reasons for C-Odin are supposed to be 1.LLVM (not using it) 2. Speed 3. Debugging.
@@MrApplewine I don't have much of an opinion on it. As far as I can see it hasn't really materialized in any meaningful way and the Tilde backend for Odin will do the same thing and will be built into the Odin compiler.
Did Odin make any progress with multithreading support? One of the key reasons to use rust (if not the most compelling one) is the thread safety story, which is something many people miss. Another aspect is compiler speed. On large projects rustc is actually quite comparable in speed to clang on c++ codebases, and serde is not exactly small (10k LOC).
Rust achieves thread safety with a combination of things Odin doesn't have and shouldn't have, so I don't know that it's something anyone should ever expect. Odin currently has thread pools, etc., like you would expect a lower level language to have but I think going much further than something like channels (certainly adding non-library solutions, i.e. changing the language, not just libraries) would be a step too far. With regards to Rust and compiler speed: Being as fast as C++ is pretty meh and I hope no one is patting themselves on the back for that. 10k lines is basically nothing and it's only because of the sad reality that most things use LLVM that lots of languages take seconds to compile 10k lines. None of this also changes the fact that in my story I had something like 800-1000 lines, added serde and some deriving for a struct and suddenly compile times go out the window. That's just not a very compelling user experience.
@@mccGoNZooo My point about thread safety being a language feature was mostly related to things such as bevy game engine, where thread pool (and shared access to global state) are enforced through type system, and thus you do not need to worry about different threads accessing the same data at the same time and/or getting stuck on a mutex. AFAIK in Odin, Zig, C++ and many others you'd have to just "be careful" and not mess this up. Similar argument applies to multithreaded web services. For single-threaded tasks Rust's borrow checker is indeed overkill, and mostly gets in the way (imo what Zig does with debug allocator is quite sufficient). Totally agree on compiler speed, as fast as C++ is not good enough, but for some reason nobody seems to notice just how slowly C++ code compiles, especially when it is heavy on templates. It is gradually getting better in rustc, but at this point ~50% of the time is spent in LLVM, so unless someone comes up with better LLVM rustc is not likely to become much faster =( Adding Serde is indeed sorta sad, but doing the same stuff by hand is way too much hassle. Overall, if I was to make a math library (like BLAS) I'd definitely consider Odin. If I am about to make a multithreaded web server I'd pick rust (mostly for correctness). With games it is sort of a tossup between zig, odin, jai and rust, and ultimately would be driven by which game engine is used. PS: Recommend you check out Roc, it is a very interesting concept (nothing production ready yet, but interesting nonetheless).
What's wrong with how Nim imports everything from the module including overloads? The alternative would be specifying which things you want but wouldn't that get tedious extremely fast?
It's not only importing everything, it's importing everything unqualified (i.e. what you get with an `#include` in C) which makes for an absolutely awful baseline for understanding where your values and functions are coming from. In almost all languages where it's possible the absolute best way to manage imports is to import them qualified or if you absolutely want unqualified imports you specify exactly what you import, so that it's clear from the actual file what you've ended up importing from other modules. But yes, Nim and its users have very little regard for what's readable, understandable and maintainable generally speaking, so the choice to have unqualified imports and not specify what comes from where is not surprising with that context.
@@mccGoNZoooWhat language has an example of this "qualified" imports? Lets say you have module with 10 functions and 10 types you want, you need to specify that list on the callee side? I'm only used languages like C++ and Pascal which import all the public interface and never ran in to problems. I'm using Swift for work now and packages are a single "Import" statement also.
A qualified import is one where the names in an imported module are namespaced by the module name or otherwise namespaced at all, i.e. we don't get all the identifiers imported into our own namespace, hence my reference to `#include` in C as an example of unqualified imports. Odin qualifies imports by default (as most sensible languages do nowadays). In Haskell you have to *ask* for a qualified import: `import qualified Module.Submodule as Submodule` and if you did `import Module.Submodule` you'd instead pollute your module's namespace with all of the identifiers that that module contains. You can also do `import Module.Submodule (identifierIActuallyWant, TypeIWant)`. For obvious reasons the version where you just import literally everything the other module has without any indication of what and the callsite has no indication where it comes from is frowned upon, because it makes for much less clear code generally speaking. In Nim, that's just Tuesday. When you use imported stuff there is no qualification. If the module you import has a function called `add` it'll just be available as `add` with no indication where it comes from at all. There is a pretty roundabout way of saying exactly which identifiers you want to import and you can qualify imports as well but no one ever does it; they just live in the mud.
@@mccGoNZooo Oh I see. Pascal at least has a public/private section and Swift has modifiers per type. If you can't reference the name of the module to resolve conflicts that's bad too obviously.
@mccGoNZooo, really like your content and this video too. Just came to give a detailed opinion as I thought that you weren't that fair with your Nim's reasoning. With all due respect, suggesting that "Nim and its users have very little regard for what's readable, understandable and [...]" misses the essence of the language. Nim prioritizes flexibility over forcing specific coding habits, making it distinct from and not a direct alternative for languages like Odin or Zig. Unqualified imports being the default (while qualified imports and namespace clashes avoidance are still possible), multiple memory management schemes (with even custom allocation being possible, even if not direct - the easiest being patching malloc through config.nims) and going big on macro support showcase this "flexibility over opinionated design" preference. Asking the users to choose their level of involvement in language features. You can basically not know more than half of the language and still work your way through a huge project with a respectable outcome (which btw I think Nim does the best). Nim's approach is not about imposing a single coding style, nor a single way of doing things. Users can opt for concise, readable code and embrace lower-level features for greater control or just jot down an awful looking project that themselves won't be able to understand anymore. I myself default to qualified imports, self manage memory when I feel the need to, etc (and a lot of the well-maintained most used libs in Nim produce well readable understandable code in that regard). Its philosophy just resonates with those who prioritize productivity and a wide feature set, making Nim a compelling choice for quick pocs and scripting too for example, distinguishing it from languages like Zig, Rust and Odin. In essence, Nim's philosophy shifts back code habits complexity from the language back to the programmer because it's just not something you can impose. You can make a language that limits the user in every way possible and he still chooses to name his variables and functions with every language alphabet available. This approach aligns Nim more with those using Python/Elixir-like language while missing the control/performance of C-like languages and the hard typing of Ada-inspired languages. An epigraph I like from the manual that I believe summarizes this, says: "Complexity seems to be a lot like energy: you can transfer it from the end user to one/some of the other players, but the total amount seems to remain pretty much constant for a given task." So it's not that Nim has very little regard for readability, explainability and maintainability. It's just that it has a higher regard for user permissibility and feature-richness flexibility and it keeps the code writing choices to those who write code. Non-opinionated and productive vs opinionated and restrictive :shrug: (that obviously results in worse code for bad programmers but that's really for the users to deal with as far as Nim is concerned) I also don't think that focusing on macros is focusing on the "wrong" thing. Many languages do feature a first-class support for macros and do come out pretty well too. And debugging is not something that Nim doesn't focus on, it's just that macros *almost always* make debugging a hard task to go about. According to your train of thought, I don't think you'd be interested in macros anyways so you won't feel their weight while working with Nim. As for libraries, that's just a side-effect. I work in HPC (a domain based on debugging and performance more than readability or else), most of the used libraries are written with macros and pragmas, the awful debugging experience comes with the package and you still can't really complain. Again, thanks for the content 🙌
I've been conisdring most of the languages on this list for a small "handmade" project I have in mind and recently decided to go with Rust.... But I just don't like the language for many of the reasons you describre. Odin and Zig are in the same zone of contention.
I'll be honest, it's rare to find me not use *any* software to solve a problem, but I frequently use a whiteboard in my office to sketch out things when the problem allows for it and I'm trying to get a handle on something.
The first build of a Haskell project Ill admit takes infuriatingly long, but after that incremental builds are blazingly fast, so DX isn't really impacted. And Haskell does have macros in the form of Template Haskell. Also, I share the sentiment about people comparing Haskell to Rust. I dislike Rust and I think it is in part because it feels like and incomplete Haskell with extra steps.
No, I've had plenty of infuriatingly slow builds after the build cache is well and truly warmed up, especially when using things like Template Haskell and so on. Also, TH is nowhere near good enough to be compared to macros in Scheme and languages like it. Not that it really matters in the long run because TH and anything like it on a language level is a net misfeature that solves a non-problem, generally. I'll be honest: I think you need to write more Haskell and see more Haskell code bases, because some of what you're saying points to a general lack of exposure.
@@mccGoNZooo Well, i've written plenty of Haskell and maintain a couple libraries on Hackage as well. I'm sorry that you've had bad experiences but then again, maybe it was like that in your time. I think you are being a bit of a gatekeeper with Scheme macros, they are essentially the same thing: you get access to an AST you can manipulate to generate new code. Yes, TH is less ergonomic, but you can do the same things.
Heh, "in my time"... This is 1.5 years ago. Let's agree to disagree; I think that there is a question of perspective here as well. There are people who believe Rust has acceptable compile times as well but when you talk to them you realize that they think that 5-10 seconds for a project of a few thousand lines is acceptable. And honestly, just "no" to the whole "TH is the same as Scheme macros". I don't particularly care whether you want to invoke some gatekeeping alarm on this either, because it's such a tired and pointless critique that lacks substance entirely. Keep that miles away from my channel, please. There is no point in having any discussion about how Haskell is lacking with someone who is basically unable to accept that it is to begin with. I'm surprised you would even bring this up to begin with since you probably know yourself that you lack any and all perspective.
@@mccGoNZooo it's hard to argue when I tell you the reasons I believe something but you just tell me "just no". And also, at no point have I said something about your person (and at this point there is plenty I could say) but you keep talking about my made up lack of experience and perspective. These two things tell me you don't really want to discuss anything, but instead felt offended by my original comment and you took that personally. I'll myself out, you seemed like a nice dude, but I guess we can never trust social media.
Yes, because your arguments for TH being equivalent to Scheme macros were filled with such amazing substance. You've provided no substantiation for any of your statements either. And no, I don't want to discuss any of these things with people who have to even be convinced that there are downsides to Haskell to begin with, like I said. It's pointless to have discussions with people who can't see even the most obvious problems. There are plenty of good sides to Haskell, but I'll be fucked if I'm going to listen passively to people telling me even the obviously shit aspects of Haskell are somehow not a problem.
Rust is in many ways a simplification of ATS. In order to achieve safe mutable state, we need certain guarantees, Rust does that through it's complicated type system, ATS does that through theorem solving. Well, Rust also has a way to side step it's own rules, using unsafe and box types, but ATS does not. There are re-write and oracle pragmas, but it's not easy to use in practice. Maybe when AI advances, we might get AI helper rewrite pragmas for some patterns, that way the programmer doesn't need to theorem solve everything.
Most if not all languages have ways to sidestep things and while I'm no ATS expert I'm fairly certain you can define axioms that are simply given truths about things, as you can in most languages, both those that are more strict and powerful in terms of type system guarantees than Rust and those that are less powerful. I would say the main reason I think *something* like ATS is more interesting than Rust is that once the Rubicon is crossed we should at least get the most out of our type system and affect runtime less. Rust is an unattractive middleground in general, in my opinion. `unsafe` and the code that you're forced to write in it is just a worse version of everything else we have and we're not getting as much as we could out of the actual safe parts either. To each their own, though. I just think Rust isn't it.
I find the sales pitch of Nim suspicious. To call python a "mature" language is like calling a person "mature" just because they're a certain age. That the person has Down Syndrome should affect that equation. Just because it's old doesn't make it less of a hobby project. It's just not stable or deterministic and I can show examples that prove this in recent interpreters of Python. It's basically a more versatile shell language that pretends to be a programming language for more serious stuff. If my bank had a single line of Python code touching my transactions I would switch to another. I have no confidence that a python program does what it is supposed to, even if the code is syntactically correct.
I think the name dropping of Python is an attempt mostly at attaching themselves to something more popular in order to say that it's "kind of like that". Believe it or not, lots of people *do* think that Python is basically the only thing that matters and to name drop it in marketing blurbs can be an effective tactic to get someone to listen, I think. There is also the root of some of those types of things where a language may have had inspiration from certain languages and wants to make that known.
I think there are just a lot of people thinking the same things about software. It's a counter to the mainstream that seems to constantly move in the opposite direction.
@@mccGoNZooo I don't know why there is any gap between this and mainstream, nor have I ever met the "mainstream programmers." Programming must be depressing for them.
CakeLisp has macro support and I didn't suggest that I would use CakeLisp without them. I don't think that using Lisp without macros at all is a super useful endeavor; I said specifically that I wouldn't use them a lot.
I find the complaint about Rusts compile time a bit disingenuous. Most people who complain about Rusts compile times are also the ones who compare it to (almost) zero dependency alternatives. Serde is by no means lightweight and serialization would probably be just as heavy in other system languages(unless it's in the standard lib). Also you can even use it without the derive feature flag if you really wanted. Derive (and proc macros in general) are heavy, but offer ergonomics, so it is a trade-off. You can disable the feature and just use serde manually though.. Just for a comparison: My current project uses GLFW, Serde, Kira(for audio) and OpenGL and has 2.35 seconds clean build times(and 0.2 incremental one). That said, I would definitely avoid wini+wgpu, which add like 150 transitive dependencies and blow up the build times. I agree with the other points though. If you prefer to write unsafe by default, Rust will just get in the way.
Disingenuous is a bit of a stretch... Rust heavily promotes package-based development and the community heavily favors `serde` for things, it's not a stretch to say that "adding JSON decoding can add seconds to your compile times". It's true that you can actually have a Rust project that doesn't take a long time to compile, but I would argue that it's rarer, harder to come by in the wild and much harder to maintain that situation in Rust than it is in Odin. Everything is a tradeoff, and unless you end up in good company both C++ and Rust users will usually tend to favor more language candy, more dependencies and clever language usage over short compile times.
I have checked out Beef, but it didn't make the list mostly because I don't have all that much to say about it. I think it would've been on the list if I didn't already have a few much more interesting languages at the end.
C99 support on windows is not so bad. For one, you do not have to use msvc, you can install clang for windows. And C99 is very usable with MSVC, only a few niche features like complex numbers or VLAs (which are a bad idea anyway) require workarounds. Especially if you separate operating system dependant code and use the WIN32 API directly it works fine. But if you want to use the C standard library on windows be prepared to endure some Microsoft silliness (CRT Warnings, having to compile a manifest file to use the narrow API functions with UTF-8, stuff that is handy on unix but missing on windows) As you mentioned you would be reimplementing standard library features anyway to work around C's questionable defaults (Null terminated strings, errno, undefined behaviour in functions like isdigit, inconsistent APIs), I doubt you would have many issues writing C99 on windows. C99 improved a lot in recent times and even C17 like _Generic are implemented in MSVC, I think that people who say C99 support is bad on windows are programmers who have not tried it recently, came from UNIX and expected some things to be there or really like VLAs.
I do agree that VLAs aren't a feature you should use very often. I stand corrected about C99 on Windows and I'll keep that in mind for the future. I would probably like to try it and see. I think the "solution" of going through CPP files was decent enough, though, but I'll be honest that I'm obviously hand-waving here a lot.
MSVC: "With the advent of two new compiler switches, /std:c11 and /std:c17, we are officially supporting the latest ISO C language standards."
I find clang still needs msvc to function. I haven't been about to use clang on windows without Microsoft build tools.
Yes, a traditional installion of clang relies on MS build tools. But my point is, that you can use GNU C extensions and attributes, as well as Standard C features like C11 atomics (only very recently also added in MSVC), VLAs, _Complex, etc. if you need these features. If you do not want to use MSVC build tools you can use MinGW gcc, or zig, which is basically clang but it is using the gnu linker and libraries. The reason why I like clang on windows is partly due to it relying on windows build tools, your headers are always up to date (e.g. My gcc install did not have CreatePseudoConsole Or the ioringapi though I admit it was gcc version 6 because I downloaded an old version). Furthermore I prefer the UB/ASAN sanitizers, error messages of clang vs gcc. (PS: I could not link a program with gcc on windows with ASAN, though MSVC and clang worked fine.)
Isn't that the longest and most detailed answer to a comment ever? 😂❤
We try very hard here :D
Thank you so much for making this. First time in my life someone on youtube actually cared enough to give me that kind of detailed answer to something I asked.
It was an interesting question and gave me a chance to talk about a bunch of different languages, so it's definitely appreciated. Thank you! :)
@@mccGoNZooo
I think videos that do the best is when you explain by contrasting a concept or a process to get your point across.
I would love a video on error handling(if this subject is not too boring for you) and you compare how multiple languages do it and put them on a spectrum.
From "meh" ..to "the best one for me" . I know Odin is the winner but I'm definitely interested in the nuances and your thoughts on where the fancier Haskell, Scala and Rust sit in your mind.
I'm just a low IQ scripting language user and more of an amateur programmer and I have so much to learn on how Odin, Haskell, Rust approach these topics.
I am slowly learning about Odin because of your videos. If you weren't opinionated about what you like about it I would have ignored it and just limited myself only to Zig.
I am going to think about this and see what I can come up with. I have some ideas already, so I think I can get something done fairly soon. Thanks for the suggestion! :)
Have to say I agree about Rust- it has some things about it that seem nice, but every time I dig deeper into them I get frustrated and disappointed. I was hoping its type system would be as powerful as an ML or Haskell but it seems like it just has the annoying parts without some of the most useful ones. Honestly it feels like if they made a new kitchen sink language like C++ with the complicated ecosystem and package philosophy of JavaScript/npm.
I 100% agree with the assessment that they basically just created a package-driven development language for systems programming that rapidly is getting as complicated and arduous to use as C++.
Anything in that type of direction of preferring complication "because you need it" has lost me entirely as of late and I'm convinced at this point that simple(r) is pretty much always better. There is a limit, of course, but I think the only ones who are even remotely close to that limit at the moment are Odin, Zig and Golang. Most languages fall on the wrong side of this and should be stripped down to far less than they are currently.
With that said, I should mention that I imagine Odin to be endgame for me; I'm tired of learning languages and I don't see the point anymore.
Always been a fan of c++ and use it in unreal engine every day, but recently odin piqued my interest. Seems like a great language for programming games , especially with the curated vendor library. Your channel was a big help in getting me started.
That's exactly why I wanted to make the Odin content, I'm very happy to hear this! :)
Thanks for the honest assessment of these various tech stacks.
I have similar views on Rust, I see it as a huge step backwards that is basically taking all the bad things about web dev / js, that make it popular.. and trying to apply that to systems programming.
I don’t see anything good coming out of that longer term. At worst, we get a whole generation of newer programmers who bring bad patterns of thinking from web dev into critical low level systems.
It’s a train wreck waiting to happen.
Thanks for the heads up on ATS too .. first I’ve heard of that, looks interesting
Love, love, love your videos! I appreciate them so much! Keep up the awesome work! If you had a Patreon, I'd donate.
Thank you so much! I was inspired by this and opened up my Patreon that had been sitting for a while: ruclips.net/video/w6HZJgpl_cE/видео.html
Agreed, the best part of C++ is that it's just C.
Your daydream of writing cakelisp in a cabin in the woods had me cracking up, I found it very relatable!
It's an interesting scenario; when you give yourself the freedom to do precisely whatever you want. It's interesting also that I consider CakeLisp for that scenario because I do write a fair amount of my own code and nowhere in it will you find any macros or other interesting things.
Maybe I can articulate the Rust to Haskell thing since I lived it very recently and this is what I thought folks were referring to. I think it's safe to say that some functional programming ideas are more prevalent in many many languages and it's really nice to solve some problems with basically a map filter reduce pipeline style. I liked that fireship joke. Anyway, I recently wrote an Axum web server (A common Rust web framework) and when I got to a point where I was ready to launch I realized since I had recently also wrote a Yesod (common Haskell web framework) Haskell web server that a lot of constructs I wrote in Rust looked just like Yesod in Haskell. To say that the language is a lot like Haskell is a bit of a stretch I think it's more almost just a moment where you realize that writing these abstract functional pipelines eventually leads you to what Haskell looks like when that language solves the same problem. Is it ground breaking well no but is it cool and fun to bring up sure.
It's a fair point that there are themes that come about because yes, once you do Haskell-like things you inevitably end up doing something that at least sort of looks like Haskell... But I think people stretch this stuff a bit far sometimes and it seems a lot like some odd sort of attempt at gaining FP clout when some of the Rust people talk about this stuff.
In any case I think a language is likely better off *not* having Haskell-like things in the end, or any FP-oriented constructs at all.
@@mccGoNZooo I agree. Hype is about questioning the hype and Odin’s focus is a pleasant aspect of the language.
I really gotta give Odin a try. So far I've mainly used Rust in recent years but I still don't like the overly abstract features like traits etc which tend to force countless annotations everywhere and simply make everything more confusing. This isn't an issue for my own code but in my experience devs use whatever the language offers and so a lot of third-party code ends up near unreadable and really inflates the compile times. Zig is a great language on paper that alleviates those issues in a really elegant way, but I think its error handling is just too limited and some decisions in terms of syntax feel unintuitive to me, sometimes it feels like they did things differently just to be different. Same with the insistence on throwing a compiler error for unused variables/functions.
Meanwhile Odin, like Zig, seems to also include efficiency oriented QoL features (native bitsets etc), and a quick look already showed a few improvements over Rust's design.
So many new interesting alternatives to C and C++, I get the feeling that many people really are ready to look for something better.
Great video again, dude! I finally found someone who has the same thoughts about rust as me.
Thanks! There are tens of us out there in the world who feel this way! Tens of us! :D
You're not alone, I think that Rust is bloated mess and it wont get better as time goes by, because corporations that providing founding for project want constantly more fetures.
indeed.
first time I've heard of ats and cakelisp. interesting stuff!
Indeed! I wanted to highlight some lesser known languages because I feel like they are more unique and I could definitely see myself using them or something like them in the future.
@@mccGoNZooo can you please namedrop the ones that were candidates for this video but were replaced? ATS and cakelisp are a very curious discovery for me as well!!
Really appreciate the long breakdown. I'm trying to decide on a language.
Did you land on one yet? My personal vote would go towards Odin, but this depends a bit on whether what you're doing is something you're going to need a ton of domain-specific libraries for. Most problems are in fact *not* that, but this also depends on how ready you personally are to implement things yourself.
It's blowing my mind that everything you said about Rust are my thoughts exactly as well.
I'm happy that the video struck a chord. If you haven't already, I think considering what you wrote here you might like Odin as a language and especially the general behavior of people who write Odin (i.e. not as many libraries for a project, if any at all) and much more focused on just "doing the thing".
@@mccGoNZooo Hey! Thanks for the reply. I have been aware of Odin for more than a year now. Very neat language, however I would rather stay with Zig.
About Rust: it took you only 2 seconds to compile? that's nothing! at work, if you change one line of code in any of our rust projects, it takes about 45 seconds 😂.
but yeah, you explained perfectly why I don't like Rust either.
Heh, yeah, that's awful. Keep in mind this was 2 seconds in a sub-1k line project, so a very clear early signal that stuff is messed up.
Happy to hear that the video struck a chord. :)
Hello Rickard Andersson, great video again, I found very useful to interiorise and share with fellow programmers the video "How I programme C", it's a incredible video and the link to it's libs make a really interesting code to study, like a master class kind of thing. And I also have to check cakelisp, sounds interesting. I'm also a user of Odin. maybe one day you should do a "How do I programme Odin" 2:30 H kind of video :-)
Yeah, I really love "How I program C" because it's so straight forward and it doesn't talk about any fluff, really, just the practical reality of using C in {{CURRENT_YEAR}}. As for my own video on this, possibly in the future when this mountain of code might be a bit more of a mountain and not a hill, but we'll see. Certainly we have a lot more videos in us yet, so we'll probably do interesting things. :)
Thanks for sharing your thoughts, this is useful for navigating these newer languages, will definitely save me some time
Take these kinds of videos for what they are; it's very hard to get a reasonable perspective on a language by proxy. I would obviously say that if you find yourself in the same situation as me (writing your own code) Odin is a good choice. but use it as a priority list more than anything else and see what you feel yourself.
Helpful video, I'd add Ada programming language, different, with the performance of C, used in satellites, hardware, etc. you can have formally verification of your program as well.
Yeah, Ada was actually an unfortunate casualty of the 10 programming language limit for this video. I would've talked about it otherwise, because I do think it's an interesting language, but in practice it is a language that always exists in the background but never makes it to the foreground for me.
I tried out Ada for the first time in university and it was the first time I tried a "When it compiles it works"(TM) language. A very interesting language indeed.
Nice to see Dlang and Crystal mentionned.
You still missed Janet, C3, Hare, Vlang and others ;)
Extremely curious to hear if you stumbled on V or tried it too? What you said about Nim's unreadablity is 100% what I feel, and V absolutely changes that. Its fast, small, all tools baked in. Would love your thoughts on it!
Haven't used it, it was wildly overhyped and proven to be completely broken very fast. This led to the creator making some very questionable posts on the Internet and I think this kind of soured a lot of people on the language, myself included. On top of that I don't think there is any real upside to using V over, say, Odin. At least this was the case last I checked.
The reason why D's standard library is not usable without GC is that it uses exceptions for error handling. And exceptions are classes so they are allocated with GC by default. If you dont really care about GC when things go bad then you can still use it
Is it actually that clear cut? They must have cleaned up a lot in that case because it was certainly the case before that there was much more to it than just exceptions. You'd never actually use exceptions in BetterC mode which would be the only real way to use D, IMO.
It's interesting how you see a bare bone low level linear type programming in ATS as a future. It's clearly a trend to "hide" raw linear types behind syntax/abstractions (Rust as an example) because it's very hard to use linear types directly for general programming.
I think maybe this is mostly because I've seen what Rust turned out to be and it's scarcely more interesting than C++ with RAII, i.e. it's basically not useful at all. I think it's clear at this point that that design was a dead end and that it's probably more useful and will yield better results to expose the actual proofs as values for the programmer. With that said there's also the much more obvious alternative: Leave both of those paths entirely and just use a much less complex language and set of tools to get better end results. That's where I personally am right now and probably where I'll stay mentally for the foreseeable future.
Really interesting video. Ive used rust professionally for almost 2 years full time. I completely agree with compile times and the Pin comment! I remember when i first encountered it to buffer a stream, it took me a whole day to figure out how to do it! And i was experienced by then (but maybe im just dumb). But i do really like Rust, the type system is incredible IMO and yes it's verbose i still think it's great. I programmed in C and C++ many moons ago (especially C so i dont really remember my experience) and to be honest C++ was a nightmare compared to Rust. I've also dabbled in Zig, i do like it but you know you grow to like what you do and Rust is low level enough that i can think of the assembly it produces, great video
I think I would've liked Rust if it had more of the things I needed because at least I could tolerate the rest of the language in that case, but given its objectively lacking and lagging support for custom allocators, etc., it's just not as relevant as the rest. I'll be honest: I also prefer unsafe-by-default when it comes to writing foundational things, or maybe even in general. The way I see it I have both better higher-level languages and better lower-level languages than Rust at my disposal, so it doesn't necessarily fit in anywhere without making huge concessions. It's kind of like OCaml in that regard (for me).
As for C++ being a nightmare compared to Rust; C++ is a nightmare compared to most languages in some regards. As soon as you have to deal with dependencies, builds, error messages, etc., it's bad. For me, solo, I think it's probably still better than Rust... Fortunately I don't have to use either.
Rust compile times are a joke. Also I appreciate the D mention. D deserves better!
D is a gem of a language, but history has not been kind to it. I think D is one of those languages that would do extremely well with a group of certain people with very clear guidelines for how to do things. I also think those people probably should construct a solid way to use custom allocators, or maybe I'm underestimating the standard library allocators a bit. Last I checked they weren't great to use.
I also think using `-betterC` as a default might be viable for the type of team I referenced above, which makes D a much, much better language than without it, IMO.
Tried to reply on your comment below, but also removed, don't know why. I thought the original comment was auto removed because it contained what looked like a link, but now I am totally confused. Anyways, I am an old school C person, its simple yet powerful, and C3 is trying to keep a much as possible from C but make it more modern. I totally agree with all your comments, and I am almost sure that you will like C3 philosophy too. They have a channel here called C3Lang", please check the talk Why build the C3 language, and let me know about your opinion, possibly another great video like this one.
I don't know why the comments aren't being posted; they're not in my "Held for review" section either. I'll check the video out and see what my impression is and probably get back to you in a reply. :)
I liked the talk and I like the ideas behind C3. I think it would definitely be in the conversation had I looked into it more previously. I think it's unfortunate that the videos otherwise on the channel aren't showing things like the output from the programs, etc.. I checked their issue tracker and am happy to see that tagged unions are being considered as well, which was something I was missing from the C3 website material.
@@mccGoNZooo maybe, once they add tagged unions, you may consider a live stream to reimplement something that you have already implemented in Odin using C3, so we have your impressions. I would also encourage everyone to star the repo and +1 the tagged union issue too.
just a counter argument on your remark, that you cannot Crystal seriously for real work because of the missing Windows support: It looks like the backend of Kagi Search is written in Crystal
Just to clarify, the "Not working on Windows" thing was when I was checking it out quite a while ago and does not represent any opinion I hold now. Like I said in the video, I think a lot of what they've done is super neat in terms of providing a good natively compiled language with OO features, etc., and I think Crystal is neat. I just have no personal use for it, so that's why it's not something I use.
I'm deep in zig right now, thinking of making it my go to language. I haven't tried Odin yet and this video peaked my interest in it, but I have a feeling you talked too much about why Zig is good but not enough why Odin is better, and I would be really interested in the "details" you skipped. Great video nevertheless!
The things that Odin has that Zig doesn't is much better error handling (which I did mention, but I don't think people see the actual gravity of), a much bigger standard library (at least from what I remember of Zig) that covers more bases as well as a vendor library that gets you very far in terms of rendering and game development. On top of that you have array math built in, swizzling, etc., which comes in handy whenever you have to do anything that touches on matrices and vectors.
Personally, a sizable portion of my code is error handling and I honestly wouldn't go back to Zig to use that error handling over Odin's even if the gains were bigger elsewhere. It's incredibly tedious to only have error codes and have to bubble up values separately from them and once I realized how well everything fits together in Odin I really couldn't stomach C, C++, Zig or Rust when it came to error handling at all.
You said Rust has very few of Haskells upsides, what exactly are the upsides of Haskell? I am very curious the answer of an Odin programmer, because whenever I tried to figure it out it seems people just want the math like esthetics and don't seem to care much about building real things.
It depends on who you ask, of course, but in my book Haskell has a very distinct edge in anything that requires multiple threads and shared memory. It has transactional variables/STM, which allows you to treat memory as you would database values, i.e. with transactions, rollbacks, etc.. None of this requires the swamp that is Rust's `async` hell.
On top of that Haskell does, if you are willing to get into it, have a compile-time only constraints system that allows you to very, very tightly control exactly what effects functions can execute without bothering with ridiculous things like algebraic effects. If that's your jam, Haskell will provide that safety whereas Rust cannot in any reasonable way do the same.
Haskell is a better imperative language than most, and using mutable values in it is better than in most languages, IMO. Personally I'm much better off using something like Odin nowadays, because I think it just hits the right notes and makes the right tradeoffs for getting stuff done, but Haskell is a very reasonable language for getting stuff done for the most part. The only parts that annoy me greatly are error handling (which Rust doesn't improve on, by the way) and some slice of the community that doesn't appreciate that the language is only there to facilitate getting stuff done (where Rust is even worse).
One thing I like about C++ is that you can declare types on the stack and have them be destroyed at the end of the scope via the destructor. What does Odin use for this pattern? I think they have a memory arena as part of the context and you add it to the that, right? Then you need a simple stack allocator to get the same kind of performance as declaring on the stack itself. Seems like C++'s solution is easier to use actually and more performant probably.
All variables you declare and use in a function are going to be on the stack. If something is only on the stack it needs no destruction because the stack is always pushed and popped to in each function call. What you're thinking of is automatic calling of destructors at end of scopes (RAII) which is only relevant when resources need to be managed beyond the stack (file descriptors, heap memory, locks, etc.).
If we wanted to have something happen at end of scope we would use `defer do_something(...)` and it would happen at the end of the current scope. You can see this being used in this video: ruclips.net/video/bJUnCXEIie0/видео.html
At no point in any high-level language do we need to clean anything on the stack up; that's done for us.
C++ and Rust both encourage one-at-a-time thinking because they both expect for resources to be managed ostensibly for you, but there is no good deterministic way to have that happen in bulk like you would get with a bulk memory allocator that you free all at once (an arena). The best solution in C++ if you want to solve that problem is to use `pmr` or have your own allocators as far as I know.
The best solution in Rust is to switch language since it has terrible support for custom allocators.
@@mccGoNZooo ok I think zig is doing the defer call thing too. This is a nice feature for sure but it's an extra line of code and thing to remember if you just want to keep something alive for the duration of a scope.
I had this experience with an elixir shill on ThePrimeagen server. Dude was so toxic I couldn’t help but leave.
Anyways, I think not all “official” channels are toxic. r/golang for example has some of the most chilled out folks.
There are official/big channels of communication that don't devolve very badly, yes, but I think there is a general tendency in these types of places to build up a cult-like feeling around the language. I've seen it in both the small and the large, growing over time. It can start out as innocent "Guys, I can't believe this language is so good!" type of stuff and with enough of that you very quickly get this tension between legitimate gripes (usually from people who have used the language more) with the language and the overenthusiastic beginner type of opinions.
With that said I think Go and Odin have a very long lasting feeling of joy because they both have a very fundamental joy of simplicity to them, which takes you much further and lasts longer than just "Wow, this particular thing is so 'simple' in this language!" type stuff.
Hi! I'm a Rust developer and I was interested to hear you critique. It does sound like we think differently.
I like creating abstractions because they allow me to eloquently solve the problem. In addition, they help me understand the code of others better.
I can accept the N seconds compile times because it does many checks and other useful things for me.
I love many small libraries where each solves one problem well. And I'm happy when my libraries use other libraries because it makes the most important libraries heavily scrutinized.
I a bit dislike Rust's Pin type as well but for different reasons. I'd love to have a way to construct an "immovable" T on the heap.
However, this level of control is great and I love how I can get as much control as I need while taking as little control as possible by default.
I think Rust offers too little control over things and replaces it with song-and-dance type development where the type system and Rust-isms have to be satisfied more than anything else. I've seen plenty of posts by people doing for example embedded development in Rust who feel the same way, where the abstractions are more for Rusts edification than actually solving the problem.
And yeah, the rest of it sounds like we just have fundamentally different views about what's difficult in software development. Many small libraries to me is a nightmare and I don't gain as much as you do from them; they usually represent a liability and time cost more than any kind of savings.
What kind of programs do you mostly write? I've been writing a database in rust and it's been mostly great.
In Rust I've written a tokenizer + parser for a language, a service for logging (the one mentioned in the video), a RSS autodownloader for torrent files and some random CLI tools. Nothing big, really, but enough to know that I don't find it enjoyable. I hope it was clear from the video that I do think there are other people Rust is for and a lot of them will likely have the opposite experience and opinion to me regarding both Rust and Odin.
@@mccGoNZooo No worries, I am nit offended. I am very interested in Odin but find it hard to justify using it since I am not a veteran programmer. Rust's safety wheels make it a gentle, if a bit frustrating, first dip into low-level programming. That said, I did not understand rust at all until I learned the basics of C.
I wouldn't worry too much about not living up to some level required for writing Odin, to be honest. Don't let that stop you in the long run; just jump in and create things. With that said, do the thing that you enjoy the most at the end of the day. Life is too short to worry about what you *should* be using or not. :)
@@mccGoNZooo I disagree with that philosophy. Programming is fun but at the end of the day it is a profession. At least in my case it is a means to an end and while having fun along the way is good, and may contribute to code quality and productivity, it is secondary to acheiving the goal of profitable software. For now I am betting on Rust getting me there better than Odin, but that may change as my aptitude and understanding grows.
There is a time and place for everything, but learning is hard when you don't have fun and can't maintain an interest. The easiest way to learn a lot is to make sure you find something that is actually fun, or find the fun in something productive.
Thanks for the content
i too had long compile in rust, but changing the linker drops my compile time from 16s to 0.2s
That's probably a reasonable suggestion for people who are stuck with Rust, but I think there are better directions to pick as base defaults in the end.
This is super helpful and I found I have some very similar opinions about most of the languages especially Rust was spot on. :) I also came from Haskell but I probably have done more Ruby/Javascript but a lot less C++. Currently I'm actually developing mostly in Zig and I only know about Odin because I met a friend at Handmade Seattle who recommended Odin to me. I also saw Ginger Bill at the conference as well. My biggest question is for someone who's versed in Zig, what does he/she gain by going for Odin? My take away is 1. error handling 2. simplicity but you'd lose comptime. Does that sound about right?
A video on this premieres today. :)
In short:
- No comptime in Odin, but we get some of it back with `when` directives
- Error handling is nicer in Odin to someone with experience in Haskell or other ML derivatives (most likely) and you could argue makes a slight bit more sense
- Odin tries to maintain clarity while allowing some select areas of implicitness whereas Zig overall tries to maximize explicitness (zero-value initialization is a guarantee that allows us some implicit things, `context` is another one. Both are clear in what they do, but enable less verbose code.)
- No "functions as methods" in Odin, we just have data + functions.
I need zeus or poseidon programming language
zeus is zig for obvious reasons
jesuschrist programming language
Did you try jai ? If so how would you review it as and alternate to zig, odin and C
I haven't tried Jai but it's not really relevant to me as long as it stays in closed beta. It'll barely be relevant as an open beta, to be honest. We'll see how I feel when it's generally available and I play around with it.
Things I'm looking forward to trying out are some of the stuff you can supposedly do to write programs that take your programs as input. It seems like an overall much better idea than macros in the case of program analysis at least; I like the idea of very easily being able to create project-specific linting rules and so on.
I like Go
Then I heartily recommend learning Odin with us, you will find that it has many of the same qualities as Go. :)
What about V and Hare systems programming languages?
I've only looked Hare very briefly and it doesn't seem to have any concept of custom allocators, which makes it very awkward to use and makes me question the users' and creator's familiarity with the concerns that I usually have with systems level code. It's not a good look for any language that wants to make memory management sane and possible to make fast and efficient.
Z I know nothing about.
The list of languages is not exhaustive; there are plenty of languages that I simply didn't bring up because they're not worth bringing up: They're either not interesting enough to really talk about in a video like this. Hare strikes me as that kind of language; it has seemingly no benefits that aren't already in languages in this video.
@@mccGoNZooo I meant "V", not "Z".
@@MrApplewine I looked at V around 2019 and the unfortunate reality then and later was that it was sold as something it really wasn't; the compiler would produce code that had memory leaks for even the most basic of things while the claim was that it could somehow solve that issue on its own.
All in all I would say V seemed to be a lot about perception rather than reality. I've also never seen anything from it that would make it actually better than Odin or Zig, so there really hasn't been any reason to "see past" these obvious lies and half-truths to see whether there was something actually useful there.
@@mccGoNZooo I see. What do you think about C-Odin, or "Codin" the Odin to C compiler written in C? I just watched a the video on C-Odin by Dale Weiler. The 3 main reasons for C-Odin are supposed to be 1.LLVM (not using it) 2. Speed 3. Debugging.
@@MrApplewine I don't have much of an opinion on it. As far as I can see it hasn't really materialized in any meaningful way and the Tilde backend for Odin will do the same thing and will be built into the Odin compiler.
Did Odin make any progress with multithreading support? One of the key reasons to use rust (if not the most compelling one) is the thread safety story, which is something many people miss.
Another aspect is compiler speed. On large projects rustc is actually quite comparable in speed to clang on c++ codebases, and serde is not exactly small (10k LOC).
Rust achieves thread safety with a combination of things Odin doesn't have and shouldn't have, so I don't know that it's something anyone should ever expect. Odin currently has thread pools, etc., like you would expect a lower level language to have but I think going much further than something like channels (certainly adding non-library solutions, i.e. changing the language, not just libraries) would be a step too far.
With regards to Rust and compiler speed: Being as fast as C++ is pretty meh and I hope no one is patting themselves on the back for that. 10k lines is basically nothing and it's only because of the sad reality that most things use LLVM that lots of languages take seconds to compile 10k lines.
None of this also changes the fact that in my story I had something like 800-1000 lines, added serde and some deriving for a struct and suddenly compile times go out the window. That's just not a very compelling user experience.
@@mccGoNZooo My point about thread safety being a language feature was mostly related to things such as bevy game engine, where thread pool (and shared access to global state) are enforced through type system, and thus you do not need to worry about different threads accessing the same data at the same time and/or getting stuck on a mutex. AFAIK in Odin, Zig, C++ and many others you'd have to just "be careful" and not mess this up. Similar argument applies to multithreaded web services. For single-threaded tasks Rust's borrow checker is indeed overkill, and mostly gets in the way (imo what Zig does with debug allocator is quite sufficient).
Totally agree on compiler speed, as fast as C++ is not good enough, but for some reason nobody seems to notice just how slowly C++ code compiles, especially when it is heavy on templates. It is gradually getting better in rustc, but at this point ~50% of the time is spent in LLVM, so unless someone comes up with better LLVM rustc is not likely to become much faster =(
Adding Serde is indeed sorta sad, but doing the same stuff by hand is way too much hassle.
Overall, if I was to make a math library (like BLAS) I'd definitely consider Odin. If I am about to make a multithreaded web server I'd pick rust (mostly for correctness). With games it is sort of a tossup between zig, odin, jai and rust, and ultimately would be driven by which game engine is used.
PS: Recommend you check out Roc, it is a very interesting concept (nothing production ready yet, but interesting nonetheless).
What's wrong with how Nim imports everything from the module including overloads? The alternative would be specifying which things you want but wouldn't that get tedious extremely fast?
It's not only importing everything, it's importing everything unqualified (i.e. what you get with an `#include` in C) which makes for an absolutely awful baseline for understanding where your values and functions are coming from. In almost all languages where it's possible the absolute best way to manage imports is to import them qualified or if you absolutely want unqualified imports you specify exactly what you import, so that it's clear from the actual file what you've ended up importing from other modules.
But yes, Nim and its users have very little regard for what's readable, understandable and maintainable generally speaking, so the choice to have unqualified imports and not specify what comes from where is not surprising with that context.
@@mccGoNZoooWhat language has an example of this "qualified" imports? Lets say you have module with 10 functions and 10 types you want, you need to specify that list on the callee side? I'm only used languages like C++ and Pascal which import all the public interface and never ran in to problems. I'm using Swift for work now and packages are a single "Import" statement also.
A qualified import is one where the names in an imported module are namespaced by the module name or otherwise namespaced at all, i.e. we don't get all the identifiers imported into our own namespace, hence my reference to `#include` in C as an example of unqualified imports. Odin qualifies imports by default (as most sensible languages do nowadays).
In Haskell you have to *ask* for a qualified import: `import qualified Module.Submodule as Submodule` and if you did `import Module.Submodule` you'd instead pollute your module's namespace with all of the identifiers that that module contains. You can also do `import Module.Submodule (identifierIActuallyWant, TypeIWant)`. For obvious reasons the version where you just import literally everything the other module has without any indication of what and the callsite has no indication where it comes from is frowned upon, because it makes for much less clear code generally speaking.
In Nim, that's just Tuesday. When you use imported stuff there is no qualification. If the module you import has a function called `add` it'll just be available as `add` with no indication where it comes from at all. There is a pretty roundabout way of saying exactly which identifiers you want to import and you can qualify imports as well but no one ever does it; they just live in the mud.
@@mccGoNZooo Oh I see. Pascal at least has a public/private section and Swift has modifiers per type. If you can't reference the name of the module to resolve conflicts that's bad too obviously.
@mccGoNZooo, really like your content and this video too. Just came to give a detailed opinion as I thought that you weren't that fair with your Nim's reasoning. With all due respect, suggesting that "Nim and its users have very little regard for what's readable, understandable and [...]" misses the essence of the language. Nim prioritizes flexibility over forcing specific coding habits, making it distinct from and not a direct alternative for languages like Odin or Zig. Unqualified imports being the default (while qualified imports and namespace clashes avoidance are still possible), multiple memory management schemes (with even custom allocation being possible, even if not direct - the easiest being patching malloc through config.nims) and going big on macro support showcase this "flexibility over opinionated design" preference. Asking the users to choose their level of involvement in language features. You can basically not know more than half of the language and still work your way through a huge project with a respectable outcome (which btw I think Nim does the best).
Nim's approach is not about imposing a single coding style, nor a single way of doing things. Users can opt for concise, readable code and embrace lower-level features for greater control or just jot down an awful looking project that themselves won't be able to understand anymore. I myself default to qualified imports, self manage memory when I feel the need to, etc (and a lot of the well-maintained most used libs in Nim produce well readable understandable code in that regard). Its philosophy just resonates with those who prioritize productivity and a wide feature set, making Nim a compelling choice for quick pocs and scripting too for example, distinguishing it from languages like Zig, Rust and Odin.
In essence, Nim's philosophy shifts back code habits complexity from the language back to the programmer because it's just not something you can impose. You can make a language that limits the user in every way possible and he still chooses to name his variables and functions with every language alphabet available. This approach aligns Nim more with those using Python/Elixir-like language while missing the control/performance of C-like languages and the hard typing of Ada-inspired languages. An epigraph I like from the manual that I believe summarizes this, says: "Complexity seems to be a lot like energy: you can transfer it from the end user to one/some of the other players, but the total amount seems to remain pretty much constant for a given task."
So it's not that Nim has very little regard for readability, explainability and maintainability. It's just that it has a higher regard for user permissibility and feature-richness flexibility and it keeps the code writing choices to those who write code. Non-opinionated and productive vs opinionated and restrictive :shrug: (that obviously results in worse code for bad programmers but that's really for the users to deal with as far as Nim is concerned)
I also don't think that focusing on macros is focusing on the "wrong" thing. Many languages do feature a first-class support for macros and do come out pretty well too. And debugging is not something that Nim doesn't focus on, it's just that macros *almost always* make debugging a hard task to go about. According to your train of thought, I don't think you'd be interested in macros anyways so you won't feel their weight while working with Nim. As for libraries, that's just a side-effect. I work in HPC (a domain based on debugging and performance more than readability or else), most of the used libraries are written with macros and pragmas, the awful debugging experience comes with the package and you still can't really complain.
Again, thanks for the content 🙌
I've been conisdring most of the languages on this list for a small "handmade" project I have in mind and recently decided to go with Rust.... But I just don't like the language for many of the reasons you describre. Odin and Zig are in the same zone of contention.
Odin and Zig are indeed very close for me, but Odin takes a slight lead because of some key features. Video on this today. :)
@@mccGoNZooo Super dig your helpful videos. Please keep them coming!
"Fundamental problem solving tools I'd try before using any software" when?
I'll be honest, it's rare to find me not use *any* software to solve a problem, but I frequently use a whiteboard in my office to sketch out things when the problem allows for it and I'm trying to get a handle on something.
Wonderful.
Happy that you liked the video! :)
The first build of a Haskell project Ill admit takes infuriatingly long, but after that incremental builds are blazingly fast, so DX isn't really impacted.
And Haskell does have macros in the form of Template Haskell.
Also, I share the sentiment about people comparing Haskell to Rust. I dislike Rust and I think it is in part because it feels like and incomplete Haskell with extra steps.
No, I've had plenty of infuriatingly slow builds after the build cache is well and truly warmed up, especially when using things like Template Haskell and so on.
Also, TH is nowhere near good enough to be compared to macros in Scheme and languages like it. Not that it really matters in the long run because TH and anything like it on a language level is a net misfeature that solves a non-problem, generally.
I'll be honest: I think you need to write more Haskell and see more Haskell code bases, because some of what you're saying points to a general lack of exposure.
@@mccGoNZooo Well, i've written plenty of Haskell and maintain a couple libraries on Hackage as well. I'm sorry that you've had bad experiences but then again, maybe it was like that in your time.
I think you are being a bit of a gatekeeper with Scheme macros, they are essentially the same thing: you get access to an AST you can manipulate to generate new code. Yes, TH is less ergonomic, but you can do the same things.
Heh, "in my time"... This is 1.5 years ago.
Let's agree to disagree; I think that there is a question of perspective here as well. There are people who believe Rust has acceptable compile times as well but when you talk to them you realize that they think that 5-10 seconds for a project of a few thousand lines is acceptable.
And honestly, just "no" to the whole "TH is the same as Scheme macros". I don't particularly care whether you want to invoke some gatekeeping alarm on this either, because it's such a tired and pointless critique that lacks substance entirely. Keep that miles away from my channel, please.
There is no point in having any discussion about how Haskell is lacking with someone who is basically unable to accept that it is to begin with. I'm surprised you would even bring this up to begin with since you probably know yourself that you lack any and all perspective.
@@mccGoNZooo it's hard to argue when I tell you the reasons I believe something but you just tell me "just no".
And also, at no point have I said something about your person (and at this point there is plenty I could say) but you keep talking about my made up lack of experience and perspective.
These two things tell me you don't really want to discuss anything, but instead felt offended by my original comment and you took that personally.
I'll myself out, you seemed like a nice dude, but I guess we can never trust social media.
Yes, because your arguments for TH being equivalent to Scheme macros were filled with such amazing substance. You've provided no substantiation for any of your statements either.
And no, I don't want to discuss any of these things with people who have to even be convinced that there are downsides to Haskell to begin with, like I said. It's pointless to have discussions with people who can't see even the most obvious problems.
There are plenty of good sides to Haskell, but I'll be fucked if I'm going to listen passively to people telling me even the obviously shit aspects of Haskell are somehow not a problem.
Rust is in many ways a simplification of ATS. In order to achieve safe mutable state, we need certain guarantees, Rust does that through it's complicated type system, ATS does that through theorem solving. Well, Rust also has a way to side step it's own rules, using unsafe and box types, but ATS does not. There are re-write and oracle pragmas, but it's not easy to use in practice. Maybe when AI advances, we might get AI helper rewrite pragmas for some patterns, that way the programmer doesn't need to theorem solve everything.
Most if not all languages have ways to sidestep things and while I'm no ATS expert I'm fairly certain you can define axioms that are simply given truths about things, as you can in most languages, both those that are more strict and powerful in terms of type system guarantees than Rust and those that are less powerful.
I would say the main reason I think *something* like ATS is more interesting than Rust is that once the Rubicon is crossed we should at least get the most out of our type system and affect runtime less. Rust is an unattractive middleground in general, in my opinion. `unsafe` and the code that you're forced to write in it is just a worse version of everything else we have and we're not getting as much as we could out of the actual safe parts either.
To each their own, though. I just think Rust isn't it.
so interesting !!
I find the sales pitch of Nim suspicious.
To call python a "mature" language is like calling a person "mature" just because they're a certain age. That the person has Down Syndrome should affect that equation.
Just because it's old doesn't make it less of a hobby project. It's just not stable or deterministic and I can show examples that prove this in recent interpreters of Python.
It's basically a more versatile shell language that pretends to be a programming language for more serious stuff. If my bank had a single line of Python code touching my transactions I would switch to another. I have no confidence that a python program does what it is supposed to, even if the code is syntactically correct.
I think the name dropping of Python is an attempt mostly at attaching themselves to something more popular in order to say that it's "kind of like that". Believe it or not, lots of people *do* think that Python is basically the only thing that matters and to name drop it in marketing blurbs can be an effective tactic to get someone to listen, I think. There is also the root of some of those types of things where a language may have had inspiration from certain languages and wants to make that known.
You watch the exact same stuff as me, you even know Eskil... Maybe all the Odin programmers are the same after all.
I think there are just a lot of people thinking the same things about software. It's a counter to the mainstream that seems to constantly move in the opposite direction.
@@mccGoNZooo I don't know why there is any gap between this and mainstream, nor have I ever met the "mainstream programmers." Programming must be depressing for them.
It was interesting to listen to your ideas and views. However, lisp without macros is like a car without wheels ;)
CakeLisp has macro support and I didn't suggest that I would use CakeLisp without them. I don't think that using Lisp without macros at all is a super useful endeavor; I said specifically that I wouldn't use them a lot.
I find the complaint about Rusts compile time a bit disingenuous. Most people who complain about Rusts compile times are also the ones who compare it to (almost) zero dependency alternatives. Serde is by no means lightweight and serialization would probably be just as heavy in other system languages(unless it's in the standard lib). Also you can even use it without the derive feature flag if you really wanted. Derive (and proc macros in general) are heavy, but offer ergonomics, so it is a trade-off. You can disable the feature and just use serde manually though..
Just for a comparison: My current project uses GLFW, Serde, Kira(for audio) and OpenGL and has 2.35 seconds clean build times(and 0.2 incremental one). That said, I would definitely avoid wini+wgpu, which add like 150 transitive dependencies and blow up the build times.
I agree with the other points though. If you prefer to write unsafe by default, Rust will just get in the way.
Disingenuous is a bit of a stretch... Rust heavily promotes package-based development and the community heavily favors `serde` for things, it's not a stretch to say that "adding JSON decoding can add seconds to your compile times".
It's true that you can actually have a Rust project that doesn't take a long time to compile, but I would argue that it's rarer, harder to come by in the wild and much harder to maintain that situation in Rust than it is in Odin.
Everything is a tradeoff, and unless you end up in good company both C++ and Rust users will usually tend to favor more language candy, more dependencies and clever language usage over short compile times.
People can talk about go without saying backend, python ai, rust …. Femboy,woke, etc
I'll be honest, I have no idea what this comment is really trying to say.
@@mccGoNZooo no one knows what it means but its provocative
check out beeflang
I have checked out Beef, but it didn't make the list mostly because I don't have all that much to say about it. I think it would've been on the list if I didn't already have a few much more interesting languages at the end.
51:56