9 ms·

My point was more broad. We're not short on compute power in most cases, we're short on dev time. If you're talking low level microcontroller stuff, or bit ba

My point was more broad. We're not short on compute power in most cases, we're short on dev time. If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like. In general though, I'd rather devs using a higher level language that gives them tools to deal with things like memory management and concurrency. The slowest code is the code that was never written, not the code that takes an extra 100ms because it was done in python instead of C.

_gabe_ 4y ago
> I see this sort of argument for low level, system languages all the time. It seems like you were advocating using a higher level language for low level, systems programs. If that's the case I disagree. My original argument was about Unix utilities. Unix utilities contain everything from "list the files in a directory" to "compile this C program". The original poster was talking about how Curl would probably be written in Python if it was written today. This is just incorrect. From the author of curl[0]: >> If I would start the project today, would I’ve picked another language? Maybe. Maybe not. If memory safety and related issues was the primary concern I had, then sure. But as I’ve mentioned above there are several others concerns too so it would really depend on my priorities. > If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like. This is the argument I'm making. Unix utilities are usually dealing with low level bit banging stuff. Unix utilities are also meant to be extremely portable. C is the glue that holds all programming languages together, whether we like that or not. So programming a library in C automatically ensures that the library can be used in practically any higher level language. [0]: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ https://daniel.haxx.se/blog/2017/03/27/curl-is-c/

_gabe_ 4y ago

> I see this sort of argument for low level, system languages all the time. It seems like you were advocating using a higher level language for low level, systems programs. If that's the case I disagree. My original argument was about Unix utilities. Unix utilities contain everything from "list the files in a directory" to "compile this C program". The original poster was talking about how Curl would probably be written in Python if it was written today. This is just incorrect. From the author of curl[0]: >> If I would start the project today, would I’ve picked another language? Maybe. Maybe not. If memory safety and related issues was the primary concern I had, then sure. But as I’ve mentioned above there are several others concerns too so it would really depend on my priorities. > If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like. This is the argument I'm making. Unix utilities are usually dealing with low level bit banging stuff. Unix utilities are also meant to be extremely portable. C is the glue that holds all programming languages together, whether we like that or not. So programming a library in C automatically ensures that the library can be used in practically any higher level language. [0]: https://daniel.haxx.se/blog/2017/03/27/curl-is-c/ https://daniel.haxx.se/blog/2017/03/27/curl-is-c/