General statistics
List of Youtube channels
Youtube commenter search
Distinguished comments
About

Anony Mousse
The Lunduke Journal
comments

Comments by "Anony Mousse" (@anon_y_mousse) on "Rust Compiler Not Stable Enough for Linux Kernel Development" video.

@shurizzle The problem with what you're saying here is that if you have to squeeze through a C ABI to get Rust working, you've eliminated some of the Rust functionality in the process. A lot of people complain about type safety and other such extraneous fluff, and you lose that if you interface with a less restrictive language.
7
@Mavendow And almost succeeded if not for a rogue MS employee. Weird, no?
5
@mytech6779 Completely agreed. The bare minimum for a CS course should be a language like C with some assembly sprinkled in. I would of course accept Pascal, Objective C, C++ and any other such language as a substitute for C, but C is the best choice, unless we're talking about inline assembly, then Pascal.
4
While it would be insane to rewrite project X in language Y that it wasn't already written in, a completely new project using language Y might make some sense. Towards that end, it would be really cool if someone implemented the entire feature set of QB4.5 for modern PC's, but upgraded of course, and then wrote a completely from scratch kernel as a project. I know some people would point towards FreeBASIC, but that wouldn't have the same cool factor as using QuickBASIC.
3
@etherweb6796 Definitely smacks of EEE.
3
We already have the tooling, it's just a matter of the Rustaceans to stop lying and/or learn about it.
3
Technically 10. However, C was stable at 10. So what's their excuse?
3
@Bokto1 Complete with animated graphics in the terminal. Only thing it needs is a selectable color scheme so we can have dark mode without modifying the code.
2
@rusi6219 Yeah, far too many devs cosplaying as senior when they lack the skills to even be junior. Some of them even start companies and make videos on YouTube.
2
@uxel-g9y Not everyone wants to use a 500mb static build and if your builds are smaller then you're not actually including everything needed to run it as I've discovered with quite a few static builds on my own system. There's always a dependency that gets left out. You might think it's worth it for one or two apps, but not everyone has a terabyte sized drive in their system, and if every app is static that adds up. Truthfully, if you were a responsible programmer, it wouldn't matter if every user had terabytes of space, that's still a lot of their space that you're wasting for your own vanity. Also, C and C++ are not the same language and have been largely incompatible without massive compromises for the better part of 25 years. So stop grouping them like they're the same.
2
I'm pretty sure everyone who can verbalize their thoughts are acoustic, unless they're using an amplifier, then they're considered electronic. Of course, we get into a gray area with recordings of acoustic instruments, but I suppose as long as there's no amplifier before it's recorded it still makes sense to call it acoustic. Now this is all to say that you clearly meant to accuse him of being autistic and that's rather bigoted of you, but I expect nothing else from those that preach tolerance and acceptance.
2
@dynfoxx No, because you called LLVM the compiler. The backend doesn't do compilation. At most it converts IL to a final binary format, but the compilation has already been done by clang at that point.
2
@dynfoxx Clang, LLVM is the backend.
2
@Spartan322 After looking at both C2 and C3, I'm inclined to say neither is an improvement over C. They've got some good ideas, but then degraded the language on top of that. For instance, C3 copying the asinine idiocy of using fn to define a function really irks me.
2
Hey now, don't go bashing Pascal. It's a great language that's very C-like in its philosophy. It just happens to be a bit verbose.
2
@RustIsWinning Then use one of the open source ones. Besides, it's not like Rust can do any better than the decades old existing tools for C already. Plus we have other tools for dynamic analysis too, tools which aren't built into Rust or its compiler or its runtime.
2
@Spartan322 Apparently YouTube ate my last response, but I've been writing compilers for long enough that I know that context sensitive makes things harder, but not dramatically so. In fact, it's a whole lot easier if you don't use generators and instead write things by hand. Automated tools can be great, but in this case they're a scourge. They make really cool designs harder, as in the kind of designs that make a programmer's job easier.
2
@Spartan322 And again, I disagree that it's a pain. It's only slightly more work in terms of lexical analysis, in the generic sense. In this specific sense, I had a longer response which was filtered, but any type will suffice to allow parsing of function names. In a language like C it's wholly unnecessary because you don't have constructors, but if the language in question used a different syntax for constructors then it wouldn't even mimic a function declaration/definition/call. Granted, that presents a few problems if you were to implement it in C++, since constructors and aggregate initialization function slightly differently, I think in my own language the solution I've come up with is adequate.
2
@muhdiversity7409 The funny thing is, Rene is an advocate of Rust. He just had some inflammatory titles that if you'd never watched his channel could be mistaken for him hating on it, but in reality he was not. He even regularly speaks out against using C. I certainly don't agree with that standpoint, but he is definitely no enemy of Rust.
2
@Spartan322 Somehow I'd forgotten that people called it that. I never neglect to use full type information when declaring and defining functions and haven't encountered that issue in my own code ever. As it turns out, recent standards have bypassed a lot of it by either requiring typenames or, as in the case of C++, allowing initialization with braces. This is actually the direction I went with my own language, although I had decided this many years ago. You also can't use parentheses like that in declaring parameters to functions in my language. So as far as I'm aware, you can't have such a problem even absent a function keyword.
2
@Aim54Delta I totally understand what you mean with trigonometry. I struggled with understanding sine, cosine and tangent. Even knowing that they're ratios didn't help because I couldn't figure out how to extrapolate a function to calculate them from that. However, I think as far as understanding C goes, it might help you to write a compiler, even if not for C. Learn how the constructs are transformed into a lower level and that should help. Maybe translate into assembly first.
2
@Spartan322 I guess I'll have to keep repeating myself since YouTube sees fit to delete or shadow every other post, but I don't agree that C was particularly visually simple in the first place, especially with the current standard requiring void for an empty parameter list anyway. Although, I'd been writing my function signatures in that way all along anyway because I prefer the consistency. I do the same with C++ too.
2
@Spartan322 Looks like I misspoke, but only slightly. It doesn't require you to use void when the function takes no parameters, but C23 requires such signatures to be interpreted as though you had. So if you define a function as void foo(); and try to pass it anything, the compiler emits an error. Though, I personally think that it should require the keyword instead of continuing with sloppy signatures and that's what I do in my own language.
2
Well, no. Rust isn't the closest thing we have to fixing memory safety because it's not even the biggest problem. For starters, the study that MS published was their invalid assessment of their own software, not software in general which they couldn't do because they don't possess the source code to every piece of software. For seconds, better programmers is the only valid solution to the problem. If you write better code, you don't have problems. However, valgrind, compiler warnings and static analysis are good adjuncts to better programmers. No one is perfect, not even the Rust compiler or standard library developers. There have been real bugs that have been discovered that seemingly can't or won't be fixed which invalidates Rust's so-called memory safety. And in case you're curious, the biggest problem facing programmers is a lack of user input validation. Merely preventing out of bounds accesses in the simplest cases won't fix the lack of validation.
1
@gruntaxeman3740 I think he's got a point here. If it still works, it's still valid. The fact that people want to throw away everything just because it's not the latest and greatest is rather shameful and wasteful. This is why so many modern pieces of software suck, because modern programmers think you can just throw more RAM or CPU at it and solve the problem inherent in the code. That's the Rust way of thinking. Don't be like Rust devs, be like C devs. Keep what works.
1
@Spartan322 I don't think C was particularly visually simple anyway. Even when functions took no arguments, whether in C or C++, I used void to indicate that. The current standard for C requires the use of the void keyword anyway. But for what it's worth, I define a type for function pointer arguments every time that I can, which is generally every time. It makes it significantly cleaner to read a function signature that way. When I write C++, I prefer to put a `using namespace std;` at the top. If I need to avoid a standard name, I'll use my own namespace or just change the name in some other way since I always put using clauses after includes and never in headers. Of course, since my own language has modules, I don't need half of the coping mechanisms that I use in either C or C++. I still don't understand language designers that love clutter. If I import a module I expect that module to be immediately usable, not indirectly usable through a namespace or some other garbage. This is one of the rare times that I would commend Python for how its imports work.
1
@Spartan322 If you've got any examples I'd appreciate you sharing them.
1
@Spartan322 I definitely do understand, but I write my parsers and lexers from scratch. If you're using rigid compiler construction tools, then it's more difficult. Why don't you give it a try, write a compiler from scratch. Let's say an enhanced BF language, something with variables and functions, and translate it into C. Might be too simple of a task, but I think you'll find that it can be enjoyable writing code and writing it all by hand is far more fun and a lot easier to do. Then write a simple BASIC dialect, but give it an editor environment like a C64, and stay within the terminal the whole time. If by the time you're done you don't understand what I'm talking about, then it might be time to retire or change fields. You shouldn't waste your time doing things you don't enjoy and/or don't feel rewarded by accomplishing.
1
@RustIsWinning There's always the original, Lint. Then you've got the compilers themselves. Or Splint, Yasca, Infer Static Analyzer, Moose, Sparse if you're working with the kernel, Frama-C, CppCheck, Coccinelle, SourceTrail, CppLint, PMD, Blast, CPAChecker and SonarQube. Those are just the open source ones and that target C and/or C++. There are more for other languages and more that are closed source. Granted, this is just what I found in a 5 minute search because I haven't needed to use anything more than the compiler to check my code in about 15 years now. I hardly ever make any typos, and those that I make are very easily spotted by the compiler and corrected in 1 second. Of course, you likely won't see this.
1
@timothygibney159 Except that Rust doesn't actually prevent all of those problems. Aside from needing an FFI for all the functionality it doesn't have built-in, which invalidates all of its supposed protections, there's the fact that there's a real bug in the compiler which still hasn't been fixed which invalidates those protections from a security standpoint. If you're a good programmer, you can use C and have safe and secure code. If you're a bad programmer, keep trying to learn how to write good programs by pounding your head against the Rust compiler.
1
Yes, but there's an agenda behind the push that makes that a useless line of attack for them.
1
@mytech6779 I would've said 5 year olds, but that works too.
1
@thcrs1 We already have tools to check our code written in C, whether at compile time or runtime, and we already have techniques that we've been using for decades that prevent leaks and other equally important and much more prevalent bugs. All of our tools for C are stable and have been for decades. There is zero reason to switch things up now, but if there's any benefit to be had, they should just write their own kernel instead of trying to take over an existing one.
1
Except that they did eventually do the work themselves of understanding how the code works. Someone posted a comment under another video, might have been one of Brodie's, where they explained how everything worked. This was work that anyone who would hope to use the inode interface would have been expected to do on their own, regardless of language, and the developers of the inode interface rightly consider the code to be the documentation there. So clearly it wasn't some gargantuan task that couldn't be completed without the developers giving them extraneous plain English documentation, which invalidates all of their complaints and really validates what the original developers were saying.
1
@RenderingUser Cool new tools aren't usable yet. I still can't trust ripgrep to be consistent with how it outputs and it still doesn't correctly interpret PCRE's. It's not the only one, but if all you care about is fancy colors, then submit a PR for any of the tools you were already using to output in color with a flag.
1
@RenderingUser Read this slowly. If a tool doesn't do what I need it to do, such as in the case of rg, correctly handle PCRE's, then it is completely useless, no matter how fast it runs. You might as well ask me to search my files with echo. Of course, with the list you just gave, I'm probably talking to a teenager that doesn't actually work on anything real anyway. None of the tools you list are substantially different enough from what came before or will improve the quality of my life or work. I don't even use a file manager at all, so yazi certainly won't help me. Although, I can't help but wonder if the people behind it are children to use such an awful name. And modrinth, bevy and key echo are toys I have no desire for.
1
@RenderingUser Nope, just updated the repo and checked again. Still doesn't correctly handle PCRE's. Also seems to be slower than it used to be. If you don't get how yazi is a terrible name, then there's no helping you. And I don't call them toys because I have no use for them, but because they're recreational programs. That I have no use for them is a separate matter.
1
@nullid1492 If you restrict yourself to writing code in such a way as to suit backwards compatibility in C++, then you're not really using C++. Same goes for Rust.
1
@Spartan322 What do you mean? As far as I've seen, the Rust Foundation would rather go completely against the US constitution.
1
@Spartan322 Strongly disagree. It's not difficult to context switch based on a token being a typename. It's mostly the same as using a keyword. Although, if your return type is a built-in type, then it already is a keyword and equivalent to that of using fn anyway, but without the redundancy. For a language that is dynamically typed, I'd say fine-ish, but even bash proves that's not necessary. You might want to argue that blocks of code could be analyzed differently if the compiler knows ahead of time that it constructs a function, but in a language like Rust where the last element of a block can just sit on its own, that removes one area of context sensitivity and places it elsewhere, and the compiler should know by the time it reaches the first brace that it's dealing with a function anyway, even in C.
1
@RenderingUser Why do you keep liking your own posts?
1
@RenderingUser C is a systems programming language that is easy for beginners. You just need the right teacher.
1
@gruntaxeman3740 Sounds like you've never worked on anything at all. You're really starting to sound like a Rustacean with all this nonsense.
1
@nullid1492 Some immigrants can provide a boost, if they contribute to the economy in a positive way. However, those calling themselves refugees soak up all the resources and contribute nothing back. Those are the ones that we have far more of now than in the past and they do not boost the economy, they drain it.
1
@gruntaxeman3740 Apparently you've never heard of a library. You write code once then use it in multiple projects. As far as more lines of code, no, not even on a per project basis because we have this thing called code reuse. If you can't write your code efficiently, then it's you, not the language. Also, as far as launching a new process, the scripted language didn't just stay running and wait for a new script to be called, nor do such considerations matter as much when the OS caches things. This also largely depends on the web server in use, but secondary CGI programs that are more likely to be cached are smaller things like C programs, not whole interpreters for scripted languages that then have to load a script and parse it.
1
@mytech6779 That's most Rust devs really. They lack the basic understanding of pretty much everything.
1
Exactly.
1
@RustIsWinning Just going to ignore my response to your other post? Refuse to acknowledge the truth?
1
@RustIsWinning I found that list with a 5 minute search. Why couldn't you? Why can't any Rustacean?
1
@RustIsWinning In other words, you're too lazy to look for yourself and incapable of doing any critical thinking. Got it. I've already told you, I don't use any of those tools because I write perfect code from the start. But if you do the research, they're there and available for all newbs to use. So lazy and stupid means Rust, diligent and intelligent means C.
1
@gruntaxeman3740 No language is fully self contained and monolithic in functionality. Although, C comes pretty close. However, C is still the most efficient language on balance, as in balancing both user and programmer time. You can write inefficient code in any language, but modern programmers seem bound and determined to do it with all of them.
1
@shurizzle I'm sorry, I didn't realize you have a learning disability. I'll say it more simply, if you have to use a C ABI to interface with Rust, you lose the advantages of Rust, and not just at the interface, but for the entire program. That means no more memory safety. Granted, it's a false promise anyway, this just gives you the final nail in the coffin.
1
Not every design decision requires absolute stringency. It's the equivalent of always checking bounds or always checking for a null pointer in internal code where the checks had already happened upon entrance to the library and no longer need the checks. Unfortunately, most compilers aren't capable of detecting when it isn't needed in heavily nested code and still require a programmer to know what they're doing and think about it properly and thus to give hints to the compiler.
1
Interesting thoughts, though I don't quite agree that C is difficult to understand how it translates into machine instructions. Of course, I've written several compilers so it may be that I'm biased in determining what's understandable to the average programmer. Like when I see a member access of a pointer to a struct, I know what code is being generated there and when I see an if/else block, I can see the lea's and mov's that lead to that cmp followed by a series of jne's and je's and sometimes even with a lack of optimization a straight up jmp to lazily fall through the whole block. But yes, I definitely agree that Rust devs need to find a different religion.
1