Comments by "Anony Mousse" (@anon_y_mousse) on "Python is 71x Slower, Uses 75x More Energy, Than C" video.

  1. It's no better than C++ for memory safety, it just has a more annoying compiler.
    16
  2. For competent developers, development time isn't nearly so big a factor as people think. Generally, if you've been in the business for any length of time, then you've either built up your own libraries for doing things or you use specific libraries that someone else wrote. It's only for the newbies that the language's standard library really matters in most instances.
    9
  3.  @hawkanonymous2610  And again I'll point out that unless you're a newbie you'll either have written your own libraries or know which ones to use to accomplish tasks equally as fast as programming in Python. It's just a matter of your experience level.
    7
  4. That is a great multiplier.
    5
  5. And yet again I find myself pointing out that newbies will not be competent in using C and will have an increased development time. This is who Python is aimed at. With more experience comes using either your own libraries or those that you have learned to use and development time is reduced. Go ahead and ask your mother to write something in C and offer no help.
    5
  6.  @josephp.3341  Depends on what you're writing, but some compilers are not as good as they should be at optimizing poorly written code. Even just the difference between calling a function with two arguments versus a struct with two members can cause wildly different results.
    5
  7.  @gruntaxeman3740  This really speaks to your lack of knowledge. C isn't limited to the terminal. I and many others use it to write GUI apps and have for decades. Not to mention all of the games written in it throughout the past 40 years. Monolithic binaries aren't really a good thing. Forget RAM usage, which will likely be lower in a monolithic binary, but startup speed will be significantly worse. It's not difficult to load all the libraries you'll need in the background while the main program starts up and presents an actual usable interface to the user. Learn better design.
    4
  8. One thing I saw that I do take objection to with regards to their test is that of using trees. The implementations can vary to the point of degrading performance a noticeable amount. I didn't see if they used hash tables too, but those can be excessively different in implementation as well. I primarily use C myself, but not for environmentalism reasons, but because I want to save my users time when they use my software. I'm not surprised about Python, because I use it fairly often too, but I am surprised about JavaScript. Yeah, I use that on occasion and it's slower than molasses in a freezer, but I would've expected that all of the work that has gone into optimizing the various interpreters would have meant it would perform better than it did. At least now there's some degree of quantification of how much the other languages suck.
    4
  9. Depends on what you mean. You can write C and compile to wasm and that would certainly run. You could also transpile to JavaScript. Or are you going to be picky about the target of compilation and require that it be an actual executable binary, because in that case, strictly speaking, nothing runs in the browser.
    3
  10. Right, so eschew what little advantage the language does have in favor of writing better code. You might as well be writing C or maybe even C++ at that point. At least if you're as competent as you seem to be claiming you are.
    3
  11. I feel like there are too many incompetent developers these days that need it pointed out, but development time can be reduced with experience. You'll either have developed the libraries you need to aid whatever you do, or you'll use libraries that you've learned about. In either instance, a competent C programmer can do it equally as fast as an incompetent Python programmer, and still equally as fast as a competent one.
    3
  12.  @JodyBruchon  Since I know you use Windows, why not just use the Win32 API functions for extracting bits of an INF file.
    2
  13. Your entire post is based on false premises. You seem to have a disconnect in your brain about the differences between a library and a language. Your arguments about object lifetimes and string handling are entirely false as it's entirely up to the programmer how to structure those things. If you write garbage code or use a garbage library then you're going to have inefficiencies. So stop doing both. Rust is most definitely not number one when parsing text and ripgrep isn't even close to having feature parity with grep. By the time it does it'll likely be slower than grep, but I doubt the guy writing it will ever give it parity. Also, the point about defensive design patterns is just plain stupid. Rust requires you to write things defensively and annoys you about it if you slack even when it won't matter. C allows you to seek out other patterns that are far better and more efficient while Rust forces you to work harder to escape the patterns that its designers wanted you to use. Want to complain about runtime versus compile time validation, then you don't know C++ very well because constexpr and consteval exist.
    2
  14.  @mmstick  I never said I wasn't skilled enough to use Rust, and in fact I do. However, you are apparently refusing to answer the questions I've asked of you, nor do you apparently understand what I'm saying. I have not argued any falsehoods, merely uncomfortable truths.
    2
  15.  @transcendtient  It's not disingenuous, it's just true. With experience comes knowledge, and that knowledge gives you abilities that those without experience will lack.
    2
  16.  @onlinealias622  And since you were too cowardly to directly address me, I'll tell you that it's not the same as those screeching "skill issue", because it's not a matter of skill. Even if you know all the right libraries to use, you could still lack skills and you could have all the skills in the world, but if you don't know when to use the right tool you'll still be a poor developer.
    2
  17.  @gruntaxeman3740  None of what you're saying makes any sense. Complexity is not a stumbling block for a developer that plans and organizes their code correctly. What limits of identifiers are you hitting?
    2
  18.  @transcendtient  No. Experience makes writing code easier in any language. If it doesn't for you then you might want to get an MRI on your brain because you may have a tumor. Also, Python code can still segfault and I haven't had a segfault in my C code for well over a decade.
    2
  19.  @transcendtient  You are literally ignorant to the fact that you don't have to write more code in C if you use the right libraries. Are you people really this stvpld that you think you have to rewrite everything from scratch when you use C? Do you not know that libraries exist so that code can be reused? Or is this just more of the Rustacean mentality where you think if it's not in the standard library that it just isn't possible?
    2
  20.  @gruntaxeman3740  If the code is properly written and modular then you don't have to keep 100k lines of code in your mind at a time. A single developer, if they're decent, should be capable of handling 1m LoC projects on their own. You only need to remember interfaces and there's no way I would believe anyone on here is working with an interface that has 100k functions. I don't know why 31 characters is so limiting to you, but that's really not a small amount and you shouldn't be writing function names that are a paragraph in length. If you can't name each section in three letters or have more than 9 sections, then you're not using C correctly. In which case, use C++ and namespaces.
    2
  21.  @transcendtient  I don't need to admit what isn't true. You're failing to read the qualifying words "if you're experienced". This tells me that you either don't natively speak English, or you just got off the shortbus. Either way, you're probably not a competent programmer anyhow.
    2
  22.  @Chaoktarukto  Try rereading what I wrote and use the ol' noggin to figure out why what you're saying is not equivalent.
    2
  23. And I'll point out that only incompetent programmers will have that problem. If you have that problem, then don't use C.
    2
  24.  @josephp.3341  That presumes that Rust is a good language. If you're even a little bit into language design, you'd realize it's garbage.
    2
  25.  @Turalcar  I'm not talking about the borrow checker, though if you had problems with that for a year or two then you weren't writing good code in the first place.
    2
  26.  @mmstick  Are you claiming that none of those are also issues in Rust? Some of those can't be fully addressed even in Rust and if you think they can then you need to go back to school. Also, what do you have against operator[]? Are you objecting to the fact that you can overload it or are you disliking how it's used in various containers?
    2
  27.  @mmstick  Ah yes, pick one that's not an issue due to actual language, but library design. That could be easily remedied even in C++ by either using a different library or they could merely change the behavior of the standard library. Do you want to address the language level problems instead?
    2
  28.  @mmstick  No. What a function in a standard library does is not a flaw in the language. It's a flaw in the library design. The standard library is not the language. Also, you still haven't said what you have a problem with in regards to operator[]. Is it that you can overload it at all? Or do you have a problem with how the function works in the various points of the library where it's used? If you've got some novel third avenue of complaining about operator[], then what?
    2
  29. It's the hype and it not being able to live up to it. For some people, all of the lies just piss us off.
    2
  30.  @bm1259  Sure, there are many undelivered promises, and that's at the very least annoying. The community around it is exceedingly toxic. But above all else, it's just an ugly language that doesn't provide anything over above the languages which existed before it. If anything, it has an inconsistent syntax that looks worse than C++. Something I keep seeing a lot of lately is a sort of movement to use only the parts of C++ that somebody likes and finds useful while writing programs in basically the same way as C. While I think it'd be better to embrace more of the C++ style of doing things, especially if you make use of classes, it's not a method that's entirely without merit.
    2
  31. One problem with that statement is that nearly all of the correctness checks are compile time only. It really boils down to the competency of the programmer, even in Rust.
    1
  32.  @alexpyattaev  Which is why I qualified that statement with "nearly". People use UB like it's an insult or a detriment to the language, but really it's just to allow for platform specific behavior and optimizations. Generic solutions, like what most languages come up with in an effort to avoid UB, tend to be slower. If anything, UB in both C and C++ actually gives them leeway to solve problems in better ways.
    1
  33.  @alexpyattaev  There's nothing inherently unsafe in undefined behavior. It just puts more burden on the developer to make it safe. In fact, you can write an entire program that avoids all UB and still does useful work and it won't guarantee that it's safe. You can even hit multiple points of UB when writing your program and it could still be safe in a portable way.
    1
  34.  @alexpyattaev  Some elements of UB can be used to determine information about the platform. The portability is a manner of determining how the UB works to guide compiler flags for how your program should proceed.
    1
  35.  @alexpyattaev  No, you look at the output. For quite a few non-standard behaviors you can write a simple program that generates output based on what the compiler does and use that output as input for the next phase of compilation. On Linux systems a lot of this can be handled using a configure script.
    1
  36.  @alexpyattaev  Well, it wouldn't help you with the compiler miscompiling, but if the compiler optimizes away a null pointer check, then it's a bug in the compiler. I think you may have inferred something from what I was writing that I definitely wasn't saying.
    1
  37.  @JodyBruchon  If you're not on Windows then I'm confused as to why you'd need to parse INF files. I'd assume it was a typo for INI, in which case I wouldn't classify them as Windows files since it's just a file format. But if you're on an embedded platform, I'd just use C for all of it. That you can run shell scripts makes me wonder how powerful this device is because most embedded platforms I've dealt with had no shell nor OS. Hopefully you've got a personal library of code you've been building up or know of one. There's probably a couple dozen hundred INI file readers in plain C on GH, if you're feeling lazy.
    1
  38.  @nandoflorestan  Whether anyone wants to or not, the idea is solid. Improve core components and everything that relies on them improves.
    1
  39.  @chralexNET  You say that as if `gcj` and other native compilers don't exist. You're just spreading FUD like every other MS fangirl.
    1
  40.  @chralexNET  And yet, you dishpit, it still exists, still works and isn't the only example of a native compiler. Since you claim to not know what FUD means, you're either a liar and I can expect more BS arguments from you, or you were born this decade and don't know squat. If you want to make the absolute zygote argument that it won't handle the latest version of Java, I'll inform you that it's an open source project and could be picked up by anyone at any time but that yet again, it's not the only one and others are still being worked on.
    1
  41.  @chralexNET  Since YouTube keeps shadowing my posts I'll say it again in a different way for a moroff like you. Discontinued doesn't mean that it no longer works and as it's open source it could be picked up and continued by anyone to work with modern versions of Java too. You say you don't know what FUD is, but as you're an MS shill I find that statement dubious.
    1
  42.  @chralexNET  This probably won't stick either, but it's a tool that stops looking at discontinued and assumes that means you can't use that software, or that other pieces of software don't exist to do the same thing. Unless you were born yesterday, I don't believe you when you claim not to know what FUD means.
    1
  43.  @chralexNET  Go ahead and block me, it's not like you'll learn anything from anyone anyway. You're close-minded and refuse to take a valid point or do any research. As for combative, you already started down the path of violence by lying.
    1
  44. Peak performance is only better in long-running, poorly optimized codebases. Gcj isn't dead, it's just not actively being developed, and again I'll say that there are alternatives, of which Kotlin is a widely used example. Of course, the best advantage in any codebase is having a competent developer.
    1
  45.  @chralexNET  Disingenuous piece of excrement. I hope you really do block me because I can't stand people like you who denigrate older technology and refuse to learn more than one language. Not to mention the intentional misreading of what I write by focusing only on one piece of it. Do other people always have to do your research for you and find every instance where you're wrong before you'll accept that you're wrong? GFY.
    1
  46.  @gruntaxeman3740  I'll say it again, but you don't have to use the terminal for C. You can easily write GUI apps in C and I and many others have done so. Also, I've had my own library for string handling for decades and you really shouldn't used linked lists if you expect your code to be performant. Arrays use less memory and are significantly faster. If you truly require the order to be retained, then a sparse array is still a better option even if it's not quite as memory efficient. A lot of what you're complaining about tells me you're not very good at architecting and you're not up to date on your knowledge of C, nor of C++. YouTube seems to be shadowing more posts than usual under this video.
    1
  47.  @rndszrvaltas  That's a rather disingenuous argument. It's like you're saying that in C you absolutely can't use a library to accomplish these tasks. Like the argument is solely between what's in the standard library. C is far older than most of the other languages that are commonly in use these days and has tons of open source libraries to handle these kinds of tasks quite easily. If you really are a numpty and can't handle manual memory management, there are multiple GC implementations for C as well as many more multiples of arena allocators. No language currently has "proper" modules, and requiring someone to add namespace_ to the start of all the functions they use isn't a valid argument against C until I stop seeing so many people prepend the namespace in other languages. There's not a language in the world that returns arrays on the stack either. They either return a reference to some heap memory or they allocate space on the stack and pass a pointer to that space to the function when calling it. Again, string libraries exist for C in numbers beyond counting. It's almost like every opponent to C doesn't know that code reuse exists. Of course, you likely won't see this because YouTube keeps shadowing long posts, but on the off chance they let it through it needed to be said.
    1
  48.  @gruntaxeman3740  Reading this thread again, I can't help but wonder if your argument about ANSI C limiting identifiers was more disingenuous than I gave you credit for. If you're using ANSI C, then you're clearly going to be on a platform that's old and you won't be using anything else anyway. If you're on a modern desktop, you won't have that limitation because you can use an ISO C compiler. Although, I still question your naming conventions if 31 characters really is a limit for you, but that's not a valid limit for modern C.
    1
  49.  @gruntaxeman3740  Which begs the question then, why bring it up? Of course, it's ridiculous to suggest that C is intended for only one purpose. It is a general purpose programming language and people were just fine writing desktop applications with it in the past, and quite a few still do today. I also completely disagree that Java or TypeScript are well suited to writing desktop applications. If anything, it sounds like your argument is either based on misconceptions or it's being made in bad faith.
    1
  50. That would be an interesting test, but implementations matter more there than with a language like Python which really only has one implementation. Some were better than others and you'd either need to test them all or write one from scratch. Also, there were quite a few BASIC compilers and they would undoubtedly perform better than the interpreted versions.
    1
  51.  @BenQ.-ys4kp  A lot of my complaints come from the language design itself. If you're not into language design then those probably won't matter to you. However, the syntax is worse than C++, and doesn't provide any benefit over idiomatic modern C++ programming techniques. I especially hate the whole lifetime dichotomy. Granted, by default C++ does require more typing there, but you can mitigate that and use better syntax and you don't have to worry about it as often. Though, one of my biggest complaints is all of the lies spread by Rustaceans about what the language can do. If you have an FFI for C, you've already defeated that argument. No one codes every application 100% from scratch. At some point you will need to call into some external library, and especially for a language as new as Rust is, you can't possibly avoid it.
    1
  52.  @BenQ.-ys4kp  It's really up to the programmer to prevent memory bugs. The compiler can only do so much, but both C and C++ have more extensive tooling outside of the compiler. However, it's not whether you can make use of the lifetime notation to prevent bugs, but the fact that for certain things you can't avoid using them, while in other languages you can do work in an area that you already know is safe without having to use such notations. For instance, if a pointer is entirely internal to your library, you really don't need to manage it as much because you know what touches it and when.
    1
  53.  @mmstick  And I think I've finally realized something about Rustaceans. It's not just that you're stupld and Iazy, which you most definitely are and explains the constant bigotry from Rustaceans, but you're unwilling to even learn. How many new features of either C or C++ have you learned about in the past 10 years? And before you try to make an incorrect argument, a) they are separate languages, b) they've had vast changes in the past 10 years, and more so in the past 20. I bet you'll say you've spent countless hours learning about Rust's new features, completely ignoring the fact that while you've only taken the time to learn one language I and other programmers like me have been learning 10. Furthermore, it's honestly kind of sad how much you expect to be in a language's standard library and how you consider that a deficiency of the language instead of learning about the third-party tools and libraries available to you. It's almost like you don't actually want to learn how to program, just "use" your computer like an appliance.
    1
  54.  @CommanderRiker0  Generally, no, they're on equal terms. Though, I would like to hear an explanation of C++ "now" having memory safety as opposed to since the 98 standard which is the first standardization. Using classes correctly with destructors that clean up memory as an object leaves scope is memory safe.
    1
  55.  @CommanderRiker0  I'm dubious of any study which proclaims C++ faster than C in any case based solely on compilers. As for pointers, you generally shouldn't use them raw in C++. If you need a resource remotely, then use a reference. It's technically still a pointer, but not one you manipulate. If the compiler is adding overhead for using std::vector and std::string, then that would negate the compiler argument, and otherwise it negates the pointer argument. Which is it?
    1