I don't really care about the security aspects of the language (cool, but not earth-shattering), but I love seeing little passion-project langs like this. I have been doodling a language design for about a year now, and this one is eerily similar in some ways, and totally different in others. I dig it.
The Rune Programming Language
141–150 of 203 posts
Re: The Rune Programming Language
#142Earlier quoted context omitted.
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.
Here's my hot take: if you're designing a new programming language in the modern era, even a systems language, ignore the precedent of C and don't use &|^~ as bitwise operators. You can still have infix bitwise operators, but spell them out as bitand/bitor/bitxor/bitnot. Then you can just use &| for logical and/or, which are 1000x more common than bitwise and/or, and you can reclaim ^ for exponentiation as well. And…
Interesting. I'd go the other way. Continue using single-character bitwise operators, but spell out "and" and "or" for the logical operators.
Rationale: in normal usage, short-circuiting logical operators are, in effect, a special kind of control flow statement, and control flow statements are typically spelled out. Bitwise operators are more unequivocally meant for calculation, and therefore perhaps more deserving of similar syntax to the arithmetic operators, despite their less frequent usage.
I think that this way of drawing the distinction might be particularly relevant in a language that disallows conditional branching - and, by extension, short-circuiting logical operations - on certain kinds of data the way Rune does.
Re: The Rune Programming Language
#143Earlier quoted context omitted.
Great callout, I haven't had my coffee yet. Here is a version that better shows what I intended pub struct Secret (T); impl Secret { pub fn map (&self, func: impl FnOnce(&T) -> U) -> Secret { Secret(func(&self.0)) } } impl > PartialEq for Secret { fn eq(&self, other: &&[u8]) -> bool { constant_time_eq(self.0.as_ref(), other) } } /* Some other file */ use secret::Secret; // Translated from the example fn check_mac >(m…
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)
}
}
impl Secret {
pub unsafe fn reveal(&self) -> &T {
&self.0
}
}Re: The Rune Programming Language
#144Earlier quoted context omitted.
You can have a Secret type in Rust where the Eq, Add, etc. traits are overloaded with constant-time versions. I'm unclear if there are any semantics that operator overloading doesn't address.
The secret (heh) is that any function defined on non-secret arguments can automatically be applied to secret arguments as well, and just returns a secret value now - without having to think about mapping/monads/whatever.
I think that it's actually something like the opposite of that. Rune disallows conditional branching on secrets, which would imply that passing secrets into the subset of functions defined on non-secrets that branch control flow based on an argument's value would be a compiler error.
Re: The Rune Programming Language
#145Earlier quoted context omitted.
But now you've forced computeHmac to only work only secrets, when there is no such need. You've coupled an implementation of an abstract algorithm with the particular case that _you_ want to use it this one time with sensitive secrets. The advantages of monads include exactly the opposite decoupling: the hmac algorithm implementation is true to its bare specification, and it is the context that changes some of its be…
You could overload computeHmac's return value so that it would return either a string or a secret, then you could use it directly with checkHmac, if you wanted, or as a string in other applications.
Consider this: I don't even know what hmac is, and it's implemented in a library.
Also, I can't overload return values on their own in C++, I would have to overload the whole signature. In fact, to get the same monadic result, I need 2^n-1 overloads for a function with n arguments (one for each subset of the arguments except the empty one).
Of course monads' advantages can be coded directly, just as functions can be coded directly in assembly. Personally I code in C++, so I've never used proper monads, but I see where they save work.
Re: The Rune Programming Language
#146Instead of this: do { c = getNextChar() } while c != ‘\0’ { processChar(c) } I'd prefer: loop { c = getNextChar() break if c == ‘\0’ processChar(c) } The eyesight rationale for curly braces (screen readers) is something I had never considered. But it would be nice if they were optional. I've been writing Python for 14 years and have never had a problem with mis-indenting. Edit: I had to correct my post because Tabs w…
As someone who has some difficulty with reading sometimes, I find Python's way of doing things to be a genuine readability challenge. Python's the language I get paid to write, but, if I thought I could get away with it at work, I might try advocating we try out Hy simply so I could return to a world of having visible, non-whitespace delimiters to aid me in reading code. I don't want to make too much hay about my cha…
The braces could be automatically added or removed by any editor, so I don't see the problem, unless someone wants to write code like:
if a == b {
do this
} else {
do that
}Re: The Rune Programming Language
#147There already exists Rune programming language and that one was earlier: https://rune-rs.github.io/ They should be more careful picking the name.
There already was a GO programming language before Google decided to use the name, too.
There also was a singer before Apple decided to name their programming language ;)
Re: The Rune Programming Language
#148~I love when I see programming languages who's first advertised features are implementable in 8 lines of rust~ Edit: ^ the above had the wrong tone. Thanks to dang for pointing it out. What I meant to express was that it's possible to accomplish a similar safety/ergonomics at the library level in rust in not too many SLOC. My personal preference is towards Rust's approach because the type system gives really powerful…
Please don't be snarky when evaluating someone else's work. Your comment would be fine without the opening swipe.
Re: The Rune Programming Language
#149Earlier quoted context omitted.
Let's be real for a minute. What you're actually saying is these hobbyists don't really matter and they don't even deserve to name their projects. Only Real Projects created by Real Programmers at Real Big Tech corporations get the cool names. This is the kind of disrespect that pushed people to create trademark laws.
Hobbyists do deserve to name their projects. And other people can name their projects the same thing. Not a big deal. (By the way, the reverse scenario here should be okay, too. If Google makes a project with with a common noun name, then others should be able to use that noun to name their projects.)
If Google can just stomp on anyone's name and that's fine by you, then what does it mean to say that hobbyists "deserve" to name their projects? What you're really saying is that whoever has the loudest voice backed by the most money gets claim over the name, regardless of who had claim to it first. In that world, hobbyists get whatever is leftover by by big corps, and don't really "deserve" anything.
Re: The Rune Programming Language
#150[deleted]