6 ms·

My argument here is about developer time though. Python development for low level systems programs would be astronomically slower than using a language like C,

by _gabe_ 4y ago

My argument here is about developer time though. Python development for low level systems programs would be astronomically slower than using a language like C, C++ or Rust which are built for these things. Use the proper tool for the proper job. If you have to have multiple structures that need to be precisely laid out in binary, python is the wrong tool for the job. Delivering content using Tcp or Udp packets requires very explicit binary definitions of the data your sending. Sure you can use a wrapper on top of a library that deals with the low level stuff, and that's what Python is all about. Use the proper tools for the proper jobs. If you're using C to write one off scripts or simple data manipulation like analyzing csv contents or something, then you should probably use a higher level language instead. If though, like curl, you have to be very explicit about the binary description of objects to accurately send and receive those objects between a network, then use a low level language. > runtime isn't the constraint that we're hitting anymore If you're sending data over the network you're absolutely hitting this constraint. Reading some data from RAM is on the order of like nanoseconds, sending data over the network is on the order of hundreds of milliseconds depending on the size and location you're sending that data. When it comes to sending data over the network, literally every byte does matter.

wing-_-nuts 4y ago
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/

by _gabe_ 4y ago

wing-_-nuts 4y ago

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/