121–130 of 274 posts
Earlier quoted context omitted.
Why, would you care if it's a full second or even 5 seconds? Go hyped their compilation speed a lot in its early years, but unless it's C++ templates level slugginess it's not like it's that big of deal.
Swift compilation is slower than C++.
Earlier quoted context omitted.
Rust binaries (at least on Linux) are not statically linked by default. They depend on libc.
Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
Earlier quoted context omitted.
Fairly easy to build against musl thanks to rustup and cargo (except if you have native deps): https://doc.rust-lang.org/rustc/platform-support.html#tier-2...
I've had a 0% success rate compiling other people's Rust apps statically. I always end up with a shared binary or a failed build, even when building with musl.
Earlier quoted context omitted.
Only because the build tooling is less mature. It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. For rust crates that are compiled and packaged straight from git, you could probably automate that today.
> It should be pretty easy to programmatically update a lock file, run the tests, and rebuild a package. You still fundamentally need to rebuild (or at least relink) and re-distribute all the packages, whereas with shared libraries... well you just update that one package.
Earlier quoted context omitted.
It's just classic dependency issues. I'm not familiar with swift specifics, but probably a combination of ABI instability and just plain version incompatibility from one distro to the next with your target program. My opinion is the opposite: I think the old paradigm of distros managing a giant set of system libraries is a bad one, and is how we ended up in the land of docker. Go and Rust made the right decisions her…
As you say, a typical Rust program can easily depend on hundreds of crates that nobody really checks. That's a security issue. The whole point of a distro is that someone distributes them, so you can choose which distro you want to trust. What I don't like about Rust and Go is that they enforce their preference. I am fine if you want to link everything statically. I just don't want you to force me.
Rust supports dynamic linking, and has since well before 1.0.
Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.
Earlier quoted context omitted.
But they do. They do let you choose. Debian's build of rust packages are linked dynanically, for instance. It's a build setting, you can turn it on.
No, crates will be statically linked anyway in general.
[flagged]
I get rust and swift (maybe) but kotlin is basically on par with java at this point. Maybe 2.0 will create a wider gap but if Java 21 has nice things that kotlin doesn't have, and when you add those up there's no clear winner imo.
On the other hand, Kotlin can target native, JS, and WASM platforms as well as the JVM, which is something Java does not do (barring alternative VMs like Graal).
Swift tooling has some really! Sharp! Edges!!! If you need something quick and easier than rust or have some reason to want to take your swift code and run it elsewhere I guess this is good but I don't see why you'd use it besides that.
[flagged]