171–180 of 203 posts
Earlier quoted context omitted.
Hard disagree on single characters for logic and exponentiation. ASCII has too few special characters and you'd want to use those elsewhere, without creating ambiguity. Elixir got it right.
ASCII has tones of unused chars we could grab for coding.
Earlier quoted context omitted.
It all gets more complicated when you want to pass more than one secret parameter, or the function already returns a Secret - now you need a monad. The key feature seems to be that the code does not need 'map' or anything, the secrecy flag is propagated regardless.
> now you need a Monad "need a Monad" sounds scary but in practice it looks like this impl Secret { pub fn map (&self, func: impl FnOnce(&T) -> U) -> Secret { Secret(func(&self.0)) } pub fn flat_map (&self, func: impl FnOnce(&T) -> Secret ) -> Secret { func(&self.0) } } If you need an escape hatch for something more complicated, you could provide an api to that impl Secret { pub unsafe fn reveal(&self) -> &T { &self.…
func(param1: A, param2: B) -> C
flat_map(secret1, |param1|
map(secret2, |param2|
func(param1, param2)
)
)
do! {
param1 func(secret1, secret2)Why do they call it " Python-inspired " if it looks like C++? From https://github.com/google/rune/blob/main/benchmarks/mandelbr... for k = 0u32, k (8 * x + k) / width - 1.5; }
Not syntactically. It's slot-based, vaguely like Python, and has reference-counting GC, like Python. That's how I understand it.
> The only close competitor is C++, where the author uses the little-known MemoryPool class from the library. I was like I know C++ and I’ve never heard of MemoryPool. Turns out that MemoryPool doesn’t exist in . In the source code they’re talking about it’s an alias to std::pmr::monotonic_buffer_resource. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Why would the struct-of-arrays layout be beneficial in a binary tree where every single node is visited, and the left + right arrays constitute all of the data in the tree? The previous example they gave was touching 75% less memory. In the binary tree it's the same amount of memory. Is the order it's touched better somehow?
Earlier quoted context omitted.
I was just considering a nicer interface for computeHmac at a library level, but if you don't have that, you could still just implement checkHmac using your Secret class and call it with checkHmac(Secret(str), message, mac).
It's turtles all the way down. Without the secrets monad support in the language, at some point I have to be the one enforcing secrets in multiple places: if I implement checkHmac(secret(str),...) that calls computeHmac(str)->str then I must both "unbox" the secret(str) _and_ "box" the return value of computeHmac. I can do this, sure, and if I forget then I'll have a security bug. This is similar to the situation wit…
x^2 means x squared, orphaning the XOR operator. Rune is for crypto, so math comes first. Isn't XOR used very heavily in crypto? (As is exponentiation of course)
It would've been wiser to duplicate C's bit operators ( ~ ^ & | > ) than give the emperor some "new clothes."
Welcome to another "Not Invented Here" language dying to be special and full of surprises. It's a fail.
x^2 means x squared, orphaning the XOR operator. Rune is for crypto, so math comes first. Isn't XOR used very heavily in crypto? (As is exponentiation of course)
It looks like Rune still has a bitwise XOR operator: @ https://github.com/google/rune/blob/main/bootstrap/database/... That innovation does seem like a potential footgun.
Why do they call it " Python-inspired " if it looks like C++? From https://github.com/google/rune/blob/main/benchmarks/mandelbr... for k = 0u32, k (8 * x + k) / width - 1.5; }
Written in C. Uses LLVM for execution. Parsers are Lex and Yacc.
Hand-coded parser-lexers are far more powerful because their diagnostics are useful and are much easier to maintain.
Lex/yacc / flex/bison products by contrast have awful diagnostics and become steaming piles of confusion that have to be rewritten.