Conveys the ecosystem. When I see “CLI tool written in Python” vs “CLI tool written in Rust/Go” I pick the latter because Python’s packaging situation for command line tools is beyond awful.

By packaging situation do you mean the user-side of things, i.e. how to install stuff separately of each other? For that I've had good experience using https://pypi.org/project/pipx to install several cli tools without conflicts. Uninstalling them has also been a breeze.

I wrote a tool called pipsi which I believe has influenced pipx but despite the existence of such tools I have no idea these days how to install python packages any more. Ir has become only more confusing and complex. Both for cli tools as well as libraries.

Pipx is the replacement for pipsi. It's good for installing cli tools.

For managing project dependencies, Poetry is the current best. It means I dont have to interact with virtualenv or pip or setuptools or pip-tools or manifest.in.

This is very surprising to read. When I read something like this from others, I was always arguing that "it's not anymore", but I'm absolutely sure you know better than me. Would you mind elaborating actual problems or writing a blog post about it? I am VERY curious about your experience and opinion in this topic!

Personally it's more about familiarity, I dev Rust so I know that I have all the prerequisites and setting this up should be trivial, meanwhile I don't do a lot of Python work so getting that to work might be a bigger commitment.

I don't do a lot of Go either but at least Go generates freestanding binaries so if I install it in precompiled form I know that it will be fairly frictionless and won't rely on half a billion dependencies (which may or may not conflict with something else). I use a bunch of Go programs regularly (like docker or Arch's yay package manager) and it never gets on in the way.

On the other hand if it's an npm package I don't even think about it.

To me, it sets expectations for

- single binary deploy(unlike Python)

- fast (llvm)

- memory efficient (no GC)

- newer (by virtue of the newness of the language itself).

Nothing wrong with setting expectations in title ;-)

You can have single binary deployment with Python.

Yes, but every time I tried it, it always fails me with some obscure error that I run away from it with bitter memory(why did I do this in Python!?!). If it is not a priority for the language, I’ll rather choose a language which cares about it.

Most people don't, though. They provide some install instructions using pip in their README, and IME these barely ever work without modification.

How? Are there reusable tools for this now?

I've used PyInstaller at least. Pretty sure there are others as well.

I found the success rate of this very low and it’s very hard to automate this for all platforms.

I've never really used Python, but as a consumer of tools, I don't recall ever coming across a Python tool packaged as a binary - so it might be possible, but dose anyone actually do it?

youtube-dl does at least.

GCs have come a long way. I think the bit about being memory efficient for not using a GC is FUD.

GCs have a nonzero overhead wrt manual management. This is an undeniable fact. The only time they can compare is for memory allocation profiles that already "emulate" a sort of a tracing/refcounted GC themselves.

Many GC enabled languages offer other ways to manage resources as well.

>> GCs have come a long way

Aha. I have a web server written in rust that literally uses about 5Mb memory on RPi. And that one actually has a proper web framework, not something barebones.

Good luck doing that in Python.

I suppose it depends on how low you need to go, I have a service written in Java EE that is using 13Mb of memory.

I lied. My server actually uses 2.704mb memory.

On top of that, that server doesn't actually use any sorts of downgraded language version that Java EE is.

You literally get that for free with Rust.

I still don't understand why people argue against this. Rust is a better language in so many aspects (tooling, language capabilities) it's really hard to argue against it.

I was thinking about Go not Python when writing the above.

Which crate/framework do you use ?

I'm looking at REST API frameworks for rust these days, but nothing looks decent...

I went with Rocket. Basically I wanted to control the switching of devices on my sound amplifier using USB infrared remote. So I built the UI using yew and the web server using Rocket - but I wanted to do it fast and only in Rust.

But I bet it took a lot more code than:

  python3 -m http.server

Note also that Python is primarily reference counted, with GC used only to detect cyclic references.

I am not serving static content, so this reply is absolutely irrelevant.

On top of this, you can do the same with docker run nginx -v.:/var/www (which btw is a similar number of symbols). Also python’s http module barely supports anything but the most basic content-types (so good luck with eg SVGs).

At a few more orders of magnitude of memory use, sure.

Tradeoffs everywhere, which make sense or not depending on your requirements.

But Python's ref counting isn't a significant factor in its memory use.

>> At a few more orders of magnitude of memory use, sure.

Are you implying nginx uses more memory than a python interpreter? :)

Even just loading the base Python interpreter uses more memory than heavenlyblue's entire server.

  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root     23612  1.2  1.7  62412 17492 pts/1    S+   12:38   0:00  |       \_ python3 -m http.server

Reference counting is a form of garbage collection.

Sure, if you want to be pedantic, but the context was limited memory use, and ref counting does not increase the memory used for unreferenced objects (except in cycles) unlike most other garbage collection algorithms.

In practice it is quite common.

No GC forces the programmer to think about memory, this is a good thing because you need to to that in all garbabe collected languages anyway - or you will get bloat.

For most use cases I consider garbage collection to be a mistake. Scripting languages or small one-off applications exempted.

Unnecessary sarcasm aside, I'm Keen to look at it simple because it's written in Rust. I like Rust so this is interesting for that reason alone.

Besides that, Mozilla and the Firefox community have a lot of Rust devs so writing this in Rust may make this more likely to get PRs from people involved in the FF Send project

Thanks for your extremely useful sarcastic comment. Maybe the author just wanted to play with the language and share their knowledge through a cool open-source tool. Maybe it's just the best language for the job.

yes but they do have a point. 'Written in Rust' adds nothing to the tool itself.

Edit: I see now. Thanks

Aren't many of us programmers? Don't we gain something from reading source code in languages we might be interested in using?

It does actually a lot - I know that when I contribute to this project I have a much lower probability of shooting myself in the foot compared to most of the other languages

We are craftspeople. Of course we care about how tools are made. Else we'd be at ProductHunt.

That's not true! See other comments in this thread.

It might use less battery time?

Nothing. You can get the same secure sharing service with zero hassle with a simple shell script:

    sum=$(sha1sum "$1" | cut -f 1 -d ' ')
    ssh your-vps mkdir /srv/http/files/$sum
    scp "$1" your-vps:/srv/http/files/$sum/
    echo https://your-vps/files/$sum/$1

+ nginx or whatever

Well I can't use this on Windows nor can I guarantee that this cryptic shell script will run on my friends computer who still uses Windows. Even so, he wouldn't know how to run it.

Also it can't be a "secure sharing service" if you're still using 'sha1sum' and it not being end-to-end encrypted...

So use sha256sum, if you don't trust SHA1.

Also it's quite secure since file content is clearly mapped to the URL you're sharing with the other party via independent channel and the receiving party can verify the content of the file.

It may not be completely private if VPS does not run on your own HW, but nothing prevents you from running it on your own HW in your secured location.

You can use this on windows the same way you'd use it on Linux. You just install a bunch of programs and run commands from command line. (basically just like you'd need to do with fsend) It's less hassle on Linux, since the commands are pre-installed. Fsend is more hassle on Linux since it's not preinstalled and requires rust, compilation, etc.

The other people just open a https links and download files in any browser or via curl, no tools required at all, not even JS.

That isn't really comparable in that it's not E2EE

It is, as all ends belong either to you (source computer, vps) or the destination device, and it uses ssh and https.

The VPS doesn't really belong to you. Google has exactly the same ability to view your secret file shared unencrypted over Drive as they do to view your file stored on your f1-micro instance.

That's just your assumption. VPS != Google. It's just a virtual machine running on some HW. I agree that if that HW is not owned by you, it can be a problem. If that's a problem you can just add another layer of encryption to the mix, like a GPG command.

I can and do own that HW. At least as much as one can own anything - it's located in my appartment. You can just as well run the web server from your own workstation/laptop.

The only reason to put shared files on other computer is that the other computer is more available.

Great Dropbox replacement.

I might not be that interested in using it, but now I might be interested in reading a bit of the source.

Prevents people from forking and submitting PRs, given rust's abysmally low usage, and higher complexity for beginners.