Jarkko Sakkinen
Posts
4402Following
315Followers
467Entrepreneur at Siltakatu Solutions Oy
OpenPGP: 3AB05486C7752FE1
@codrusofathens
Rust is pretty much owning WebAssembly at least. For wasm it is almost like what C is for bare metal.
So one probably quite widely used web stack in future has along the lines these layers:
1. JavaScript/TypeScript as orchestrator
3. Rust compiled into wasm as "client-side" latency backend.
3. Java in the "server-side" backend.
Makes sense because more stuff can offloaded to the client. For large batch computations Java is pretty solid, but for more latency sensitive stuff you'd want to use Rust.
And obviously it makes sense in any possible business to scale down the amount of investment to the "new", or like find a sweet spot for that investment...
Rust is pretty much owning WebAssembly at least. For wasm it is almost like what C is for bare metal.
So one probably quite widely used web stack in future has along the lines these layers:
1. JavaScript/TypeScript as orchestrator
3. Rust compiled into wasm as "client-side" latency backend.
3. Java in the "server-side" backend.
Makes sense because more stuff can offloaded to the client. For large batch computations Java is pretty solid, but for more latency sensitive stuff you'd want to use Rust.
And obviously it makes sense in any possible business to scale down the amount of investment to the "new", or like find a sweet spot for that investment...
1
1
0
@codrusofathens
Rust is pretty much owning WebAssembly at least. For wasm it is almost like what C is for bare metal.
So one probably quite widely used web stack in future has along the lines these layers:
1. JavaScript/TypeScript as orchestrator
3. Rust compiled into wasm as "client-side" latency backend.
3. Java in the "server-side" backend.
Makes sense because more stuff can offloaded to the client. For large batch computations Java is pretty solid, but for more latency sensitive stuff you'd want to use Rust.
And obviously it makes sense in any possible business to scale down the amount of investment to the "new", or like find a sweet spot for that investment...
Rust is pretty much owning WebAssembly at least. For wasm it is almost like what C is for bare metal.
So one probably quite widely used web stack in future has along the lines these layers:
1. JavaScript/TypeScript as orchestrator
3. Rust compiled into wasm as "client-side" latency backend.
3. Java in the "server-side" backend.
Makes sense because more stuff can offloaded to the client. For large batch computations Java is pretty solid, but for more latency sensitive stuff you'd want to use Rust.
And obviously it makes sense in any possible business to scale down the amount of investment to the "new", or like find a sweet spot for that investment...
1
1
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
Installed gh (cli.github.com) for the sake of convenience of being able to do this:
gh release download v2.6.0 -R woodpecker-ci/woodpecker
Jarkko Sakkinen
jarkko
@oranki This is a valid point!
And simple batched sync's with rclone have been much nicer 99% of the time nice behavior as far as I'm concerned.
Sometimes tho would be nice to have quick real-time sync'd access. So what I do instead is that I simply run it at localhost 🤷 Then I know at least when I spending my quota, right? :-)
Thanks for the comment! Was a money saver...
And simple batched sync's with rclone have been much nicer 99% of the time nice behavior as far as I'm concerned.
Sometimes tho would be nice to have quick real-time sync'd access. So what I do instead is that I simply run it at localhost 🤷 Then I know at least when I spending my quota, right? :-)
Thanks for the comment! Was a money saver...
0
0
1
@codrusofathens ... and counter arguments are 90% of time qualitative arguments, e.g. "we have this contract/abstraction/invariant so you're wrong".
I only believe in quantitative arguments for the most part. E.g. spec growth is one of such, e.g. you can compare that to a spec that does not grow. Would be foolish to think that spec growth does not have a negative impact to static analysis.
But for any quantitative arguments it is hard to say anything conclusive. Can't beat Gödel's theory of incompleteness, right? ;-)
I only believe in quantitative arguments for the most part. E.g. spec growth is one of such, e.g. you can compare that to a spec that does not grow. Would be foolish to think that spec growth does not have a negative impact to static analysis.
But for any quantitative arguments it is hard to say anything conclusive. Can't beat Gödel's theory of incompleteness, right? ;-)
0
0
1
@codrusofathens and the whole narrative that Rust almost invented memory safety is like totally untrue.
E.g. in the backend Java has delivered the whole gist of memory safety literally decades and JVM's JIT is a monster dealing with server payloads... It is optimized by the best breed of Intel, ARM etc. companies for each micro-architecture.
When looking at beyond the hype I feel that there's exactly one area where I find Rust best tool so far: cli-interfaces. For tpm2-cli I chose Rust because input validation was easier with it than in my previous python experiments (I've done a small Python based stack for kselftest previously).
Not a revolution really ;-)
E.g. in the backend Java has delivered the whole gist of memory safety literally decades and JVM's JIT is a monster dealing with server payloads... It is optimized by the best breed of Intel, ARM etc. companies for each micro-architecture.
When looking at beyond the hype I feel that there's exactly one area where I find Rust best tool so far: cli-interfaces. For tpm2-cli I chose Rust because input validation was easier with it than in my previous python experiments (I've done a small Python based stack for kselftest previously).
Not a revolution really ;-)
2
0
1
Jarkko Sakkinen
jarkko
@codrusofathens yeah, it is f*****g horror story how this plays :-) absolutely hate rusty forking culture.
1
0
0
@hunger I do like Rust, I'm using it too, and have contributed to some upstream projects features and also have some things of my own going on too (still unreleased ASN.1 to bytecode compiler, and alternative super light-weight TPM2 stack).
I just generally learn best by applying "learn by hate"-methodology ;-)
Like when doing kernel dev, I look Linux more like how bad it is, and from that angle I find ways to improve it. And even look into how great NT kernel or Darwin are doing some things, whereas Linux is under-performing.
I just generally learn best by applying "learn by hate"-methodology ;-)
Like when doing kernel dev, I look Linux more like how bad it is, and from that angle I find ways to improve it. And even look into how great NT kernel or Darwin are doing some things, whereas Linux is under-performing.
1
0
0
@hunger Except the one that I already mentioned:
1. Rust static analysis can get only worse over time, given the steady complexity growth in the spec.
2. C static analysis can get only better over time, given a stable and compact spec. And it does. Tooling for analyzing C is a whole multi-million industry of its own.
1. Rust static analysis can get only worse over time, given the steady complexity growth in the spec.
2. C static analysis can get only better over time, given a stable and compact spec. And it does. Tooling for analyzing C is a whole multi-million industry of its own.
1
0
0
@hunger it is well anchored comparison also given the build artifact: ELF binary (or COFF/PE).
Also in binary analysis C wind by a large margin given its trivial binary structure, which is result of compact language spec with only constructs that are great fits for any possible microarchitecture ABI.
Also in binary analysis C wind by a large margin given its trivial binary structure, which is result of compact language spec with only constructs that are great fits for any possible microarchitecture ABI.
1
0
0
I find it somewhat easy because the application category is well defined in my post:
- I based amount of C dependencies based on what I’m typically seeing in the project file. GNOME is a project umbrella, not a dependency.
- Dependencies might be larger but there are much less forks, larger user bases, which adds up to the QA and generally well-defined processes.
- For many Rust libraries I find sometimes hard to trust, given that they have not been exposed that much in the “warzone”. And this is sort of feature of the ecosystem too because you pile up your app stack from these nuts and bolts (also known as “crates”). You end up constructing yourself the “big dep”.
2
0
0
Jarkko Sakkinen
jarkko
Edited 1 year ago
A typical #TUI #Rust application has usually about ~600 dependencies or similar figure.
A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.
And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷
What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.
Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.
Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...
#rustlang #gcc #llvm #toolchain
A typical C applications has less than ten. C application might possibly be less "memory safe" language but you can statically analyze every bit and piece of the code base, including dependencies.
And by doing hat, you end up getting more verified, and *objectively* more memory safe build artifact ;-) 🤷
What many people especially in the Rust community completely have ignored, one side-effect of this new language popping, was igniting the heyday of the development of static analysis of the C language, which has *vastly* improved both in LLVM and GCC toolchains.
Just look at how amazing e.g. GCC 14 is when analyzing C code, and given the low amount of dependencies you can get pretty solid guarantees on safety of your code base.
Static analysis of C can *only* get better because the base language is compact and does not really grow anymore. One thing where C is factors more immutable is the language spec itself ;-) Rust language spec on the other hand is the most mutable spec ever invented, and run by a Github pull request process...
#rustlang #gcc #llvm #toolchain
3
2
6