181–190 of 210 posts
Earlier quoted context omitted.
I mean, in some sense you're right, but in another, the point is that it's not a regression.
True. Also, I coud imagine Rust's type-system raises the bar of dependencies that can be mangaged before everything breaks down. So a lib with 100 deps in NPM isn't the same as a lib with 100 deps in Cargo.
Edit: I mean if you don't use ~ or ^ in your nose dependencies,. Just explicit versions.
Earlier quoted context omitted.
I mean, you're just repeating a sibling comment, but if development has been this way for a long time, it's on the folks who are suggesting the new way to get out there and prove that it's a viable model for software development. It appears that most real-world, actually used software works like this. I am all about improving the world, don't get me wrong, but saying "hey this software works just like all the other s…
> saying "hey this software works just like all the other software" isn't really the insult that you seem to think that it is. Well, it's common knowledge that most existing software is compete and utter crap, as evidenced by the fact that our first thought upon hearing that a particular piece of software is no longer being updated is not "oh good, it is (probably) finished and we can rely on it", but rather "on no,…
One good thing about stat counters for packages combined with GitHub for issue tracking of you can kind of tell.
It does take some level of die diligence and isn't easy. But neither is anything relying on say system installed libraries in C projects.
I'd rather have the package managers than not.
Earlier quoted context omitted.
There’s a third option if the package is so important: put it in the standard library. Technically it’s still a dependency but the standard library is maintained with a standard that is rarely matched by third party libraries, and can dramatically simplify the ecosystems’ dependency graph.
> with a standard that is rarely matched by third party libraries I mean, you can go both ways with this. Standard libraries are significantly more difficult to work on than third party libraries, and I've seen a lot of code in standard libraries that is objectively worse than ecosystem equivalents because of it.
Now, I am somewhat supposed that say tokio or similar hasn't made it in the box yet, it allows for much greater experimentation.
Aside, I wouldn't be surprised to see MS generate a massive sure if libraries if they shift more internals development to rust. Not sure if it'll be good/bad or otherwise.
Earlier quoted context omitted.
HTTP libraries are a prime example of where many, many standard libraries are considered old and crufty, and there are much better ecosystem libraries that end up being wildly used more. You may have that perception, and that is fine, but it's not likely to be a thing that changes significantly, even when Rust is quite old. There's just not a lot of advantage to being in the standard library, and numerous downsides.
We should be more nuanced than that. There are also many standard libraries where the HTTP implementation is the standard. Why? > There's just not a lot of advantage to being in the standard library, and numerous downsides. Look at those huge lists of dependencies and the complaints of Cargo dependency hell. That's the downside. Every node in your dependency graph has overhead for everyone involved, and it's even wor…
I'm less experienced with rust, but with nude, there's many times I'll use a specific dependency over another because it's already in the dependency tree.
Aside, it's rough actually trying to keep node dependencies in check in a project. Especially in web UI projects using npm.
Earlier quoted context omitted.
libc that's it. Every other dependency for curl is optional.....
Try it. If you do not use any "optional" dependency it becomes pretty limited, almost useless for anything serious (eg. zlib, ssl)
TLS implementions are often giant hairballs but one that many things depend on. You can think of it as a somewhat "system level" dependency.
Earlier quoted context omitted.
> saying "hey this software works just like all the other software" isn't really the insult that you seem to think that it is. Well, it's common knowledge that most existing software is compete and utter crap, as evidenced by the fact that our first thought upon hearing that a particular piece of software is no longer being updated is not "oh good, it is (probably) finished and we can rely on it", but rather "on no,…
It depends. If it's in a github repo and there isn't a massive backlog of issues for a software that hasn't been updated in a while, I might think that. One good thing about stat counters for packages combined with GitHub for issue tracking of you can kind of tell. It does take some level of die diligence and isn't easy. But neither is anything relying on say system installed libraries in C projects. I'd rather have…
- a significant (eg, at least as complex as wget) software project,
- that has been unmaintained (no updates, code has the same MD5/etc hash),
- with a significant userbase (not sure exactly how to define that one),
- for a significant amount of time (at least five years),
- which is generally regarded as finished and bug-free (not in need of further development) rather than abandoned?
Because I can't think of a single one, and the only ones that even come close are video games where the known bugs were co-opted into gameplay features. The general consensus seems to be that any system that doesn't have automatic updates running is de-facto insecure (which, since every update mechanism I've heard of can introduce new code (ie new security vulnerabilities), means any system whatsoever is insecure).
(I don't quite disagree with the tacit assertion that actually getting things right on - if not the first try - then at least one of the first thirty or so is a extremely, maybe even unreasonably high standard, but it manifestly is a standard that basically all existing nontrivial software projects fail to meet.)
- support HTTP/HTTPS
- support proxy (for by-passing firewall, censorship, etc, http/https/socks5)
- download one large file in parallel (configurable temporary directory)
- download many small files in parallel (seems too high-level to put in a library, not sure this is a good feature)
- configurable retry (maybe too high-level to put in a library)
- resume download
- good error semantics
- an interface with defined behaviour
- progress report (useful for downloading large files)
I tried using a wrapped (in rust) version of libcurl, and in the end I decided to just use the curl cli, and read through the man page and pass about 13 arguments to it to make it's behaviour defined (to me, to a certain confidence level), I also pinned the curl executable to a specific version to avoid unknown changes.
The end result works, but the process is unnecessarily complicated (invoke the cli binary, know what argument to pass, know the meaning of the many error codes), and the resume is not pleasant to use. I guess libcurl is designed to be that way, so that to an curl-master, he can tune all the knobs to do what he want, but to a average library user who just want to download things, it requires more attention than I'm willing to give to.
Used in an interactive context, the issue of defined behaviour is usually overlooked, but when used a library in a program that runs unattended and expensive to upgrade/repair, achievable defined behaviour is a must, and test is not an alternative to it, even experience is not an alternative (experience are time consuming to get, and not transferable to others).
All package managers needs to download packages from internet, often via HTTP, it's good to have a easy-to-use, well-defined, capable download library, many of them uses curl (Archlinux's pacman, rust installation script), many of them use others with varying level of capabilities, I thinks it would be beneficial if we can have a good library (in rust) for download things.
Earlier quoted context omitted.
It depends. If it's in a github repo and there isn't a massive backlog of issues for a software that hasn't been updated in a while, I might think that. One good thing about stat counters for packages combined with GitHub for issue tracking of you can kind of tell. It does take some level of die diligence and isn't easy. But neither is anything relying on say system installed libraries in C projects. I'd rather have…
Can you give even a single example of: - a significant (eg, at least as complex as wget) software project, - that has been unmaintained (no updates, code has the same MD5/etc hash), - with a significant userbase (not sure exactly how to define that one), - for a significant amount of time (at least five years), - which is generally regarded as finished and bug-free (not in need of further development) rather than aba…
Earlier quoted context omitted.
I think that it is the right tool. 1. CURL without https seems insufficient nowadays. 2. CURL could be improved by running multiple downloads at once. I'm not sure that curl command line utility could do it, but certainly libcurl.so has this ability, it allows client code to work with multiple connections. 3. Any application having UI could benefit from async: input/output and main task are async by nature. For examp…
1. So as to your first point, I totally agree CURL needs to support HTTPS. My point is that Hyper needs a runtime for HTTPS, and it doesn't necessarily make sense for CURL to have a runtime. 2. I'm not sure that CURL should necessarily support multiple concurrent downloads. It could also be argued it's more UNIX-y to make it just do one thing and allow the caller to run multiple CURL processes at the same time 3. You…
One could do a spinning indicator, but not a label STALLED. To get this one need to restart read(2) every while, and there we come to implementation with complexity on par with async. Things become even more interesting if a program wants to process user input in async. UNIX-way is to send signals, but it is just plain ugly. dd from coreutils allows to use signals to trigger it to print progress, it is very inconvenient way to do it.
> I think ultimately you'd have to decide based on the relative cost of including an entire runtime vs. just launching a second thread.
I'm not so sure. Runtime for user-space context-switching is very small. I did it for educational purposes at some time in the past with C. It is operation like save registers, switch stacks, restore registers and jump to another thread. If you have more than two threads, then you'd need some kind of structure to store all contexts and to decide which one to choose next. Add some I/O code (like epoll) to track state of file descriptors, and you are done. One could do it without async, but it wouldn't become much smaller, because it would be the same logic, just instead of stack switching program would recreate stack frames.
I find myself in the need of a "lib_download" a few times, a high level library that: - support HTTP/HTTPS - support proxy (for by-passing firewall, censorship, etc, http/https/socks5) - download one large file in parallel (configurable temporary directory) - download many small files in parallel (seems too high-level to put in a library, not sure this is a good feature) - configurable retry (maybe too high-level to…
The --libcurl command line argument can help translate curl to libcurl.