Beyond technology stack choices I'd say the biggest differences are that k6 is scriptable in JS whereas Tsung has scripting-like capabilities in XML, and that Tsung supports distributed execution of tests which k6 doesn't support yet (only in our SaaS product). Tsung also supports more protocols than k6 at the moment (eg. AMQP, MQTT, PostgreSQL etc.) but k6 supports HTTP/2 and gRPC which Tsung doesn't so depends on one's needs I suppose.

We have a more comprehensive review of open source load testing tools in our blog (including Tsung): https://k6.io/blog/comparing-best-open-source-load-testing-t...

Tsung was made in another era, before devops. I think it shows in the UX and everywhere when using the tool that it wasn't really meant for developers.

Specifically, and with the disclaimer that I haven't used Tsung so much, I'd say the biggest difference is that k6 tests are scripted in a real language (JS) as compared to Tsung's XML.

But k6 also has a modern CLI UX that beats Tsung (and most other tools) by a mile, more integrations now and possibly support for more protocols, or at least more relevant ones (not sure if Tsung supports HTTP/2 for instance). Plus k6 is being very actively developed.

From what I've seen of Tsung I really like it though. Seems like a very performant and solid piece of software. But like mentioned earlier, it was made in another era. Just like Jmeter. If I ranked tools in terms of ascending "DevOps:ness" and UX for developers it'd probably be something like:

Lowest: Jmeter, Tsung

Low: Gatling

Medium: Apachebench, Siege, Hey, Wrk (simple testing)

High: Artillery, Locust

Highest: k6, Vegeta (though Vegeta is only for simple/static tests)

I wrote an article about this topic also: how most load testing tools we have are just not geared for developers and DevOps: https://k6.io/blog/another-load-testing-tool