>[...] the standard library is about as complete as you can get (and probably better than the classical scripting languages — all of Ruby/Python/Perl missed a good API for some things like HTTP, which led to the rise of separate packages like Faraday/Requests/etc)

What? Rust basically has no standard library. At least Python doesn't require pulling in third-party libraries to do globbing, create a zip/tar, create a tempfile or send/serve http. Hell, it doesn't even do command-line arguments outside of manually parsing and iterating over the args vector.

Admittedly they did ship a lot out of core outright, but a single line in `Cargo.toml` fetches any of these things pretty expediently, and they're still well standardized across the ecosystem.

    zip = "0.2"
    tempfile = "2.1.4"
    getopts = "0.2"
    hyper = "0.9.12"

it sort of does, though. Trying to use urllib2 is like pulling teeth

Which is why you use httplib[1] for sending HTTP requests.

    >>> import httplib, json
    >>> conn = httplib.HTTPConnection("httpbin.org")
    >>> conn.request("GET", "/get")
    >>> res = conn.getresponse()
    >>> print res.status, res.reason
    200 OK
    >>> data = json.load(res)
    >>> print data
    {u'origin': '0.0.0.0', ...}
    >>> conn.close()

[1] https://docs.python.org/2.7/library/httplib.html#examples

So, I'm going to stop you right there on the fast to bootstrap & run...

Certainly Java is kind of a hybrid worst if both worlds kind of thing, but C/C++? For simple scripting problems you don't need complex build logic. You can usually get by with "cc foo.c -o foo", which you can embed in the source file. Sure, if you have library dependencies it can be a bit more involved, but most modern IDE's (even less than modern) will manage that for you. It's particularly simple if you do static linking (which often makes sense with small scripts anyway). These days there are so many header only libraries that can remove even that boy if pain. On the deploy side, it's simple and likely faster to run than Rust.

Now, many C/C++ projects start with auto tools/cmake or similar heavy lifting, and long build times. But there's selection bias there: those projects aren't simple scripting jobs, but actually intend to exploit close system integration and support building with a broad variety of compilers and linkers. They do it because they want people to use the code and for a larger project, it isn't that much extra overhead.

Nah, the main pain with C++ in particular is the lack of a standard, simple library for network services like HTTP & databases. That problem seems to be finally getting resolved, but historically I've addressed by just standardizing on one of curl, cpp-http, etc. Once you do that with a modern C++17 compiler, and maybe their in Folly as well to make it truly easy, it starts to become a remarkably viable scripting language.

You will type a bit more, but the compiler will also catch a lot more stuff for you automatically, reducing the cognitive load. There are better alternatives, but if you are in a shop with C++ already, the advantages of just using the same tool as everywhere else are more than enough to justify it.

A bit tangential but here goes: I have some friends whose background is mostly algorithmic problems in competitive programming environments. I enjoy that kind of practice occasionally, but for them, it's the 90% of code they've written, and they are just too good at that stuff.

This means they know C++ best, as this is usually the language you use in those competitions. It's interesting to see the approach to scripting of these guys. While I tend to resort to shell pipelines and maybe throw in a short Lua program in-between, they write C++ code for everything, escaping to the shell for some stuff while using ordinary text files instead of piping, e.g. system("curl somesite >input.txt") and then fopen("input.txt", "r"). They write the glue between these calls, call the C compiler and run the binary.

They know their C++ and know how to write it fast; as a result, they can get a valid script running about as fast as I can do the same using a shell pipeline.

When I see this, I'm reminded how awesomely tools can be bent to do something they're not primarily designed for, when in the hands of someone skilled who knows them inside-out.

Throw in cling or cint and you are good to go!