Post AbPCLmG3acCi0pTdPE by defanor@emacs.ch
(DIR) More posts by defanor@emacs.ch
(DIR) Post #AbPCLlHRDziMyp7Dv6 by defanor@emacs.ch
2023-10-31T18:19:12Z
0 likes, 0 repeats
A few months ago I had to set export of the files I process and remove to an FTP server. Thought a shell script would suffice: copy incoming files into two subdirectories, then process and remove files from one, upload and remove from another. To ensure that only successfully uploaded files are removed, and to avoid anything error-prone in a shell script, I have set it to upload files with curl one by one, which seemed fast enough. Recently the receiving party complained about delayed uploads, which turned out to be caused by FTP PASS command hanging occasionally, curl giving up, and their server apparently still counting it as an active connection, but not allowing more connections from the same IP address. I tried to relax timeouts and to introduce delays between uploads, but eventually decided to rewrite the shell script as a program.Since it does not have to interact with my other programs (which depend on a Haskell library for IPC), I decided to give #Rust a try: have not used it at work yet, and with rexmpp it is quite messy, with raw pointers and "unsafe" everywhere.Planned to use an FTP library, preferably netrc, parse command-line arguments, write logs into syslog or stderr, preferably with a runtime choice. The "ftp" and "netrc" crates worked, for argument parsing "clap" seemed suggested and popular, but one of its dependencies did not like my rustc version, and suggested for me to find out what is the last version of that dependency supporting it. I poked around, did not find a sensible way to find it out, and gave up: used "env::args()" instead. Same happened with env_logger, so I use "eprintln!" instead.I observed seemingly everything requiring a nightly Rust compiler the first time when I tried it, and then each time afterwards, even with such commonly needed libraries. Coupled with pulling everything from Rust-specific repositories and not picking appropriate older versions automatically, it is disappointing.The program works though.
(DIR) Post #AbPCLmG3acCi0pTdPE by defanor@emacs.ch
2023-11-02T13:14:02Z
0 likes, 0 repeats
Looking into other alternatives to #C now, and from documentation alone #Zig looks nicer than I expected: I pictured it as basically C with possibly more of static analysis by default, tweaked syntax and library, and so on, but without substantial changes. Well, it still looks like that, yet it may be that the small changes do add up: it has generics, slices, seemingly good C interfacing, and sum types via compiler-supported tagged unions. Although apparently those tagged unions do not play nicely with the C interfacing yet, but the issue to improve that is open since 2018: <https://github.com/ziglang/zig/issues/1072> (while #Rust's enums with fields have a C representation as tagged unions, which is convenient, though as observed in other confusing cases, mutations do not happen if not enough code around attempts to mutate their fields is wrapped into "unsafe", when raw pointers are involved). And Zig is not in Debian repositories.Probably will look into more C alternatives, started writing notes on those into <https://defanor.uberspace.net/notes/c-alternatives.xhtml>. Perhaps it would also be fair to consider newer C standards and use of helper libraries, not to compare new languages to plain C89.Out of those low-level languages, I think I like (or somehow sympathize with) Rust the most as a language at this point, but the infrastructure (stable libraries available from system repositories, POSIX and C API orientation of those, documentation) is much better for C.
(DIR) Post #AbPCLmz4tEDUGSXaa0 by emaksovalec@emacs.ch
2023-11-02T19:16:39Z
0 likes, 0 repeats
@defanor I liked Zig when I tried it for some small things 2 years ago. But C integration was a bit buggy at that point and printing to stdout was (is?) considered a big no no