10 ms·

> I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a

> I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Conversely when 99.9% of the software you use in your daily life is blazing fast C / C++, having to do anything in other stacks is a complete exercise in frustration, it feels like going back a few decades in time

p1esk 4y ago
Conversely when 99.9% of the software you use in your daily life is user friendly Python, having to do anything in C/C++ is a complete exercise in frustration, it feels like going back a few decades in time
- bena 4y ago
  I kind of feel both statements. I like writing things in python. It honestly feels like cheating at times. Being able to reduce things down to a list comprehension feels like wizardry. I like having things written in C/C++. Because like every deep magic, there's a cost associated with it.
- bayindirh 4y ago
  As a person who uses both languages for various needs, I disagree. Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I implement in C++. Lastly, people think C++ is not user friendly. No, it certainly is. It needs being careful, yes, but a lot of things can be done in less lines then people expect.
  - l33t2328 4y ago
    > Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I’m gonna need an example because I do not believe this whatsoever.
    - bayindirh 4y ago
      I'd rather open the code and show what I'm talking about, however I can not. Let's say I'm making a lot of numerical calculations which are fed from a lockless queue with atomic operations to any number of cores you want, where your performance is limited by the CPU cores' FPU performance and the memory bandwidth (in terms of both transfer speed and queries that bus can handle per second). As I noted below, that code can complete 1.7 million complete evaluations per core, per second on older (2014 level) hardware, until your memory controller congests with all the requests. I need to run benchmarks on a newer set of hardware to get new numbers, however I seriously lack the time today to do so and provide you new numbers.
      - necovek 4y ago
        There are definitely operations you cannot speed up in Python as much as in other languages, unless you implement it in one of those other languages and interface it in Python. That much is obvious from Python providing a bunch of C-based primitives in stdlib (otherwise they'd just be written in pure Python). In many cases, you can make use of the existing primitives to get huge improvements even with pure Python, but you are not beating optimized C++ code (which almost has direct access to CPU vector operations as well). Python's advantage is in speed of development, not in speed of execution. And I say that as a firm believer that majority of the Python code in existence today could be much faster only if written with the understanding of Python's internal structures.
  - p1esk 4y ago
    Which “accelerated” libraries for matrix operations are you talking about? Try writing a matmul operation in C++ and profile it against the same thing done in Numpy/Pytorch/TensorFlow/Jax. You’ll be surprised.
    - gpm 4y ago
      This is because numpy and friends are really good at matmul's. As soon as you step out of the happy path and need to do any calculation that isn't at least n^2 work for every single python call you are looking at order of magnitude speed differences. Years ago now (so I'm a bit fuzzy on the details) a friend asked me to help optimize some python code that took a few days to do one job. I got something like a 10x speedup using numpy, I got a further 100x speedup (on the entire program) by porting one small function from optimized numpy to completely naive rust (I'm sure c or c++ would have been similar). The bottleneck was something like generating a bunch of random numbers, where the distribution for each one depended on the previous numbers - which you just couldn't represent nicely in numpy. What took 2 days now took 2 minutes, eyeballing the profiles I remember thinking you could almost certainly get down to 20 seconds by porting the rest to rust.
      - rubyskills 4y ago
        Have you tried porting the problem into postgres? Not all big data problems can be solved this way but I was surprised what a postgres database could do with 40 million rows of data.
        gpm 4y ago
        I didn't, I don't think using a db really makes sense for this problem. The program was simulating a physical process to get two streams of timestamps from simulated single-photon detectors, and then running a somewhat-expensive analysis on the data (primarily a cross correlation). There's nothing here for a DB to really help with, the data access patterns are both trivial and optimal. IIRC it was also more like a billion rows so I'd have some scaling questions (a big enough instance could certainly handle it, but the hardware actually being used was a cheap laptop). Even if there was though - I would have been very hesitant to do so. The not-a-fulltime-programmer PhD student whose project this was really needed to be able to understand and modify the code. I was pretty hesitant to even introduce a second programming language.
  - bb88 4y ago
    Java and Go were both responses to how terrible C++ actually is. While there are footguns in python, java, and go, there are exponentially more in C++.
    - bayindirh 4y ago
      As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C++. Similarly, I'd rather use Java if I'm going to talk with bigger DBs, do CRUD, or develop bigger software which is going to be used in an enterprise or similar setting. However, if I'm writing high performance software, I'll reach for C++ for the sheer speed and flexibility, despite all the possible foot guns and other not-so-enjoyable parts, because I can verify the absence of most foot-guns, and more importantly, it gets the job done the way it should be done.
      - bb88 4y ago
        I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Writing good C++ is hard. People who think they can write good C++ are surprised to learn about certain footguns (static initialization before main, exception handling during destructors, etc). I found this reference which I thought was a pretty good take on the C++ learning curve. https://www.reddit.com/r/ProgrammerHumor/comments/7iokz5/c_learning_curve/ https://www.reddit.com/r/ProgrammerHumor/comments/7iokz5/c_l...
        bayindirh 4y ago
        > I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you. > Writing good C++ is hard. I concur, however writing good Java is also hard. e.g. Swing has a fixed and correct initialization/build sequence, and Java self-corrects if you diverge, but you get a noticeable performance hit. Most developers miss the signs and don't fix these innocent looking mistakes. I've learnt C++ first and Java later. I also tend to hit myself pretty hard during testing (incl. Valgrind memory sanity and Cachegrind hotpath checks), so I don't claim I write impeccable C++. Instead I assume I'm worse than average and try to find what's wrong vigorously and fix them ruthlessly.
  - throwaway894345 4y ago
    I was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).
    - TremendousJudge 4y ago
      >unless something has changed recently No, it's even worse -- there are even MORE ways of doing the same thing now.
    - jb_s 4y ago
      I delved into Python recently to work on some data science hobbies and a Chess program and it's frankly been fairly shit compared with other languages I use. Typescript (by way of comparison with other non-low-level languages) just feels far more solid wrt type system, type safety, tooling etc. C# (which I've used for years) is faster by orders of magnitude and IMO safer/easier to maintain.
      - rocqua 4y ago
        I have found that Python with `mypy --strict` for type-checking is actually quite nicely typed.
    - gpderetta 4y ago
      Python is a powerful yet beginner friendly language with a very gentle learning slope, but I would still take C++ tooling and debuggability any day over Python.
      - throwaway894345 4y ago
        Nah man, I've spent way too much time trying to piece together libraries to turn core dumps into a useful stack trace. Similarly, as miserable as Python package management is, at least it has a package manager that works with virtually every project in the ecosystem. I actually really like writing C++, but there are certain obstacles that slow a developer down tremendously--I could forgive them if they were interesting obstacles (e.g., I can at least amuse myself pacifying Rust's borrow checker), but there's no joy in trying to cobble together a build system with CMake/etc or try to get debug information for a segfault.
  - LoveMortuus 4y ago
    I personally find C++ more friendly, just because of the formatting that python forces upon you. But I do have to say that I never managed to really get into python, it always just felt like to much of a hassle, thus I always avoided it if possible.
    - idlehand 4y ago
      I didn't like it for years but then I kind of got into it for testing out machine learning and I found it kind of neat. My biggest gripe is no longer the syntax but the slowness, trying to do anything with even a soft performance requirement means having to figure out how to use a library that calls C to do it for you. Working with large amounts of data in native Python is noticeably slower than even NodeJS.
    - chowells 4y ago
      The formatting python enforces is just "layout reflects control flow". It's really not any more difficult than that, and it's a lot better than allowing layout to lie about control flow. https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2/ https://www.synopsys.com/blogs/software-security/understandi...
      - doctor_eval 4y ago
        To each their own, but Python's use of indenting for structure is why I never tried it. It just felt, to me, like it was solving one problem with another. I think Go gets this right: it consistently uses braces for structure, but has an idiomatic reformatting tool that is applied automatically by most IDEs. This ensures that the format and indentation always perfectly matches the code structure, without needing to use invisible characters.
  - kaba0 4y ago
    I call bullshit on that. You either don’t compare the same thing, but C++ is not that much faster than even Python.
    - easytiger 4y ago
      That's simply not even remotely true, as someone who has written a lot of both
    - deterministic 4y ago
      You clearly have strong opinions about things you don’t understand or have any experience with.
  - tcfhgj 4y ago
    C++ isn't user friendly. Have you ever tried Rust? Compared to C++, it's like lawyer speech vs poetry
  - tcfhgj 4y ago
    C++ isn't remotely user friendly. Have you ever tried Rust? Compared to C++, it's like heaven
- pjvsvsrtrxc 4y ago
  Yes, writing software in C/C++ is harder. It's a darn good thing most software is used much more frequently than it is written, isn't it?
tester756 4y ago
Is performance inversely proportional to dev experience? because what you wrote could be said about using C++ in the context of dev experience 10 compilers, IDEs, debuggers, package managers and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware I don't believe that this is the best we can get.
- bhauer 4y ago
  > Is performance inversely proportional to dev experience? No. I feel there is great developer experience in many high performance languages: Java, C#, Rust, Go, etc. In fact, for my personal tastes, I find these languages more ergonomic than many popular dynamic languages. Though I will admit that one thing that I find ergonomic is a language that lifts the performance headroom above my head so that I'm not constantly bumping my head on the ceiling.
- pjvsvsrtrxc 4y ago
  Huh? "10 compilers, IDEs, debuggers, package managers" what are you talking about? (Virtually) No one uses ten different tools to build one application. I don't even know of any C++-specific package managers, although I do know of language-specific package managers for... oh, right, most scripting languages. And an IDE includes a compiler and a debugger, that's what makes it an IDE instead of a text editor. "and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated... I'm not sure why you think that's an argument against debloating?
  - throwaway894345 4y ago
    I assume the parent was talking about the fragmentation in the ecosystem (fair point, especially regarding package management landscape and build tooling), but it's unclear.
  - tester756 4y ago
    >No one uses ten different tools to build one application. I meant you have a lot of choices to make Instead of having one strong standard which everyone uses, you have X of them which makes changing projects/companies harder, but for solid reason? I don't know. >"and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated... I'm not sure why you think that's an argument against debloating? I know that lines in repo aren't great way to compare those things, but .NET Compiler Infrastructure: 20 587 028 lines of code in 17 440 files LLVM: 45 673 398 lines of code in 116 784 files The first one I built (restore+build) in 6mins and it used around 6-7GB of RAM The second I'm not even trying because the last time I tried doing it on Windows it BSODed after using _whole_ ram (16GBs)

p1esk 4y ago

Conversely when 99.9% of the software you use in your daily life is user friendly Python, having to do anything in C/C++ is a complete exercise in frustration, it feels like going back a few decades in time

bena 4y ago
I kind of feel both statements. I like writing things in python. It honestly feels like cheating at times. Being able to reduce things down to a list comprehension feels like wizardry. I like having things written in C/C++. Because like every deep magic, there's a cost associated with it.
bayindirh 4y ago
As a person who uses both languages for various needs, I disagree. Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I implement in C++. Lastly, people think C++ is not user friendly. No, it certainly is. It needs being careful, yes, but a lot of things can be done in less lines then people expect.
- l33t2328 4y ago
  > Things which takes minutes in optimized C++ will probably take days in Python, even if I use the "accelerated" libraries for matrix operations and other math I’m gonna need an example because I do not believe this whatsoever.
  - bayindirh 4y ago
    I'd rather open the code and show what I'm talking about, however I can not. Let's say I'm making a lot of numerical calculations which are fed from a lockless queue with atomic operations to any number of cores you want, where your performance is limited by the CPU cores' FPU performance and the memory bandwidth (in terms of both transfer speed and queries that bus can handle per second). As I noted below, that code can complete 1.7 million complete evaluations per core, per second on older (2014 level) hardware, until your memory controller congests with all the requests. I need to run benchmarks on a newer set of hardware to get new numbers, however I seriously lack the time today to do so and provide you new numbers.
    - necovek 4y ago
      There are definitely operations you cannot speed up in Python as much as in other languages, unless you implement it in one of those other languages and interface it in Python. That much is obvious from Python providing a bunch of C-based primitives in stdlib (otherwise they'd just be written in pure Python). In many cases, you can make use of the existing primitives to get huge improvements even with pure Python, but you are not beating optimized C++ code (which almost has direct access to CPU vector operations as well). Python's advantage is in speed of development, not in speed of execution. And I say that as a firm believer that majority of the Python code in existence today could be much faster only if written with the understanding of Python's internal structures.
- p1esk 4y ago
  Which “accelerated” libraries for matrix operations are you talking about? Try writing a matmul operation in C++ and profile it against the same thing done in Numpy/Pytorch/TensorFlow/Jax. You’ll be surprised.
  - gpm 4y ago
    This is because numpy and friends are really good at matmul's. As soon as you step out of the happy path and need to do any calculation that isn't at least n^2 work for every single python call you are looking at order of magnitude speed differences. Years ago now (so I'm a bit fuzzy on the details) a friend asked me to help optimize some python code that took a few days to do one job. I got something like a 10x speedup using numpy, I got a further 100x speedup (on the entire program) by porting one small function from optimized numpy to completely naive rust (I'm sure c or c++ would have been similar). The bottleneck was something like generating a bunch of random numbers, where the distribution for each one depended on the previous numbers - which you just couldn't represent nicely in numpy. What took 2 days now took 2 minutes, eyeballing the profiles I remember thinking you could almost certainly get down to 20 seconds by porting the rest to rust.
    - rubyskills 4y ago
      Have you tried porting the problem into postgres? Not all big data problems can be solved this way but I was surprised what a postgres database could do with 40 million rows of data.
      - gpm 4y ago
        I didn't, I don't think using a db really makes sense for this problem. The program was simulating a physical process to get two streams of timestamps from simulated single-photon detectors, and then running a somewhat-expensive analysis on the data (primarily a cross correlation). There's nothing here for a DB to really help with, the data access patterns are both trivial and optimal. IIRC it was also more like a billion rows so I'd have some scaling questions (a big enough instance could certainly handle it, but the hardware actually being used was a cheap laptop). Even if there was though - I would have been very hesitant to do so. The not-a-fulltime-programmer PhD student whose project this was really needed to be able to understand and modify the code. I was pretty hesitant to even introduce a second programming language.
- bb88 4y ago
  Java and Go were both responses to how terrible C++ actually is. While there are footguns in python, java, and go, there are exponentially more in C++.
  - bayindirh 4y ago
    As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C++. Similarly, I'd rather use Java if I'm going to talk with bigger DBs, do CRUD, or develop bigger software which is going to be used in an enterprise or similar setting. However, if I'm writing high performance software, I'll reach for C++ for the sheer speed and flexibility, despite all the possible foot guns and other not-so-enjoyable parts, because I can verify the absence of most foot-guns, and more importantly, it gets the job done the way it should be done.
    - bb88 4y ago
      I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Writing good C++ is hard. People who think they can write good C++ are surprised to learn about certain footguns (static initialization before main, exception handling during destructors, etc). I found this reference which I thought was a pretty good take on the C++ learning curve. https://www.reddit.com/r/ProgrammerHumor/comments/7iokz5/c_learning_curve/ https://www.reddit.com/r/ProgrammerHumor/comments/7iokz5/c_l...
      - bayindirh 4y ago
        > I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you. > Writing good C++ is hard. I concur, however writing good Java is also hard. e.g. Swing has a fixed and correct initialization/build sequence, and Java self-corrects if you diverge, but you get a noticeable performance hit. Most developers miss the signs and don't fix these innocent looking mistakes. I've learnt C++ first and Java later. I also tend to hit myself pretty hard during testing (incl. Valgrind memory sanity and Cachegrind hotpath checks), so I don't claim I write impeccable C++. Instead I assume I'm worse than average and try to find what's wrong vigorously and fix them ruthlessly.
- throwaway894345 4y ago
  I was a C++ dev in a past life and I have no particular fondness for Python (having used it for a couple of decades), and "friendliness" is a lot more than code golf. It's also "being able to understand all of the features you encounter and their interactions" as well as "sane, standard build tooling" and "good debugability" and many other things that C++ lacks (unless something has changed recently).
  - TremendousJudge 4y ago
    >unless something has changed recently No, it's even worse -- there are even MORE ways of doing the same thing now.
  - jb_s 4y ago
    I delved into Python recently to work on some data science hobbies and a Chess program and it's frankly been fairly shit compared with other languages I use. Typescript (by way of comparison with other non-low-level languages) just feels far more solid wrt type system, type safety, tooling etc. C# (which I've used for years) is faster by orders of magnitude and IMO safer/easier to maintain.
    - rocqua 4y ago
      I have found that Python with `mypy --strict` for type-checking is actually quite nicely typed.
  - gpderetta 4y ago
    Python is a powerful yet beginner friendly language with a very gentle learning slope, but I would still take C++ tooling and debuggability any day over Python.
    - throwaway894345 4y ago
      Nah man, I've spent way too much time trying to piece together libraries to turn core dumps into a useful stack trace. Similarly, as miserable as Python package management is, at least it has a package manager that works with virtually every project in the ecosystem. I actually really like writing C++, but there are certain obstacles that slow a developer down tremendously--I could forgive them if they were interesting obstacles (e.g., I can at least amuse myself pacifying Rust's borrow checker), but there's no joy in trying to cobble together a build system with CMake/etc or try to get debug information for a segfault.
- LoveMortuus 4y ago
  I personally find C++ more friendly, just because of the formatting that python forces upon you. But I do have to say that I never managed to really get into python, it always just felt like to much of a hassle, thus I always avoided it if possible.
  - idlehand 4y ago
    I didn't like it for years but then I kind of got into it for testing out machine learning and I found it kind of neat. My biggest gripe is no longer the syntax but the slowness, trying to do anything with even a soft performance requirement means having to figure out how to use a library that calls C to do it for you. Working with large amounts of data in native Python is noticeably slower than even NodeJS.
  - chowells 4y ago
    The formatting python enforces is just "layout reflects control flow". It's really not any more difficult than that, and it's a lot better than allowing layout to lie about control flow. https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2/ https://www.synopsys.com/blogs/software-security/understandi...
    - doctor_eval 4y ago
      To each their own, but Python's use of indenting for structure is why I never tried it. It just felt, to me, like it was solving one problem with another. I think Go gets this right: it consistently uses braces for structure, but has an idiomatic reformatting tool that is applied automatically by most IDEs. This ensures that the format and indentation always perfectly matches the code structure, without needing to use invisible characters.
- kaba0 4y ago
  I call bullshit on that. You either don’t compare the same thing, but C++ is not that much faster than even Python.
  - easytiger 4y ago
    That's simply not even remotely true, as someone who has written a lot of both
  - deterministic 4y ago
    You clearly have strong opinions about things you don’t understand or have any experience with.
- tcfhgj 4y ago
  C++ isn't user friendly. Have you ever tried Rust? Compared to C++, it's like lawyer speech vs poetry
- tcfhgj 4y ago
  C++ isn't remotely user friendly. Have you ever tried Rust? Compared to C++, it's like heaven
pjvsvsrtrxc 4y ago
Yes, writing software in C/C++ is harder. It's a darn good thing most software is used much more frequently than it is written, isn't it?

tester756 4y ago

Is performance inversely proportional to dev experience? because what you wrote could be said about using C++ in the context of dev experience 10 compilers, IDEs, debuggers, package managers and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware I don't believe that this is the best we can get.

bhauer 4y ago
> Is performance inversely proportional to dev experience? No. I feel there is great developer experience in many high performance languages: Java, C#, Rust, Go, etc. In fact, for my personal tastes, I find these languages more ergonomic than many popular dynamic languages. Though I will admit that one thing that I find ergonomic is a language that lifts the performance headroom above my head so that I'm not constantly bumping my head on the ceiling.
pjvsvsrtrxc 4y ago
Huh? "10 compilers, IDEs, debuggers, package managers" what are you talking about? (Virtually) No one uses ten different tools to build one application. I don't even know of any C++-specific package managers, although I do know of language-specific package managers for... oh, right, most scripting languages. And an IDE includes a compiler and a debugger, that's what makes it an IDE instead of a text editor. "and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated... I'm not sure why you think that's an argument against debloating?
- throwaway894345 4y ago
  I assume the parent was talking about the fragmentation in the ecosystem (fair point, especially regarding package management landscape and build tooling), but it's unclear.
- tester756 4y ago
  >No one uses ten different tools to build one application. I meant you have a lot of choices to make Instead of having one strong standard which everyone uses, you have X of them which makes changing projects/companies harder, but for solid reason? I don't know. >"and at the end of the day LLVM compiles 30min and uses tens of GBs of RAM on average hardware" sure, if you're compiling something enormous and bloated... I'm not sure why you think that's an argument against debloating? I know that lines in repo aren't great way to compare those things, but .NET Compiler Infrastructure: 20 587 028 lines of code in 17 440 files LLVM: 45 673 398 lines of code in 116 784 files The first one I built (restore+build) in 6mins and it used around 6-7GB of RAM The second I'm not even trying because the last time I tried doing it on Windows it BSODed after using _whole_ ram (16GBs)