4 ms·

It's just a wrapper arround aws-lc which is 100% C++/C/ASM.

• brundolf 3y ago
  It still matters for the ecosystem to have SDKs available for use
• methodical 3y ago
  It's incredible how many Rust packages are just wrappers around C++ implementations. That being said, as a weekend rustacean (I hate saying it but couldn't resist the urge) and current user of tch-rs (a rust PyTorch C++ wrapper) I'm glad somebody out there is writing the interfaces to allow more functionality in Rust. It's probably a good thing that C++ is so established since it allows these types of packages to come to fruition without the leg work of an actual re-implementation of the same logic in Rust from scratch.
  • catgary 3y ago
    Have you looked at burn.dev? It’s kind of a neat approach where they backend to torch/candle/other things and are also building a pure Rust backend that compiles to webgpu shaders.
    • paholg 3y ago
      There's also dfdx, which is pure Rust and really leverages the type system.
  • bee_rider 3y ago
    It seems odd but it makes sense, right? Rust prevents a whole class of bugs. But, reusing existing code that’s already well debugged and battle-tested prevents even more bugs!
  • IshKebab 3y ago
    I think it's actually surprising how few crates are C++ wrappers. You can really tell if you try and cross-compile big Rust programs because it's always the C/C++ wrapper crates that cause issues and 90% of the time it's OpenSSL. There are more wrappers than in Go, but probably fewer than Python.
• jrpelkonen 3y ago
  Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation. Furthermore, it has a ring compatible API, and it is evidently faster than ring itself[1]. [1] https://www.memorysafety.org/blog/rustls-performance/ https://www.memorysafety.org/blog/rustls-performance/
  • briansmith 3y ago
    > Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation. This really oversimplifies the situation. Even at my most pessimistic, I believe just a very few, very small, parts need to be written in assembly language to maintain the "constant time" properties, and that's just until we can work together better with the Rust language team to eliminate these small gaps. Even before then, the Rust language team is doing a good job at independently improving and expanding the building blocks we need to get to entirely-safe (in the Rust `unsafe` sense) and high-performance crypto libraries in Rust. > evidently faster than ring itself[1]. If you're running on an AVX-512 system, there is a notable performance gap, temporarily. This state will persist for a few months at most, most likely. It's inevitable that we (all the OpenSSL forks, and even including non-OpenSSL-forks like rust-crypto) all converge on more-or-less the same implementations and/or different implementations of the same optimizations.
    • CodesInChaos 3y ago
      What kind of improvement are you looking for? A `blackbox` intrinsic with stronger guarantees?
• jedisct1 3y ago
  So what? It allows Rust code to access a set of fast and battle-tested implementations. I personally don't care about the tools and languages something uses as long as it does a good job.
• up2isomorphism 3y ago
  So what? why don’t you make a wrapper? Or if you don’t like that way, make one yourself instead of complaining thing’s others give you for free?