Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rune Programming Language

github.com

Post reply on HN
Print view View original

131–140 of 203 posts

Re: The Rune Programming Language

#131

Post by mumblemumble »

grantjpowell wrote: post #127

~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…

This Rust example seems like it misses the point? Rune detects that you're working with data that is marked as secret, and gives you a compiler guarantee that it's defending against some set of known attacks.

The Rust code above depends on the programmer to consistently remember to enforce safety, and to do so correctly every time.

Sure, you could probably implement that as a library. But, "We don't see much value in compiler help with this, a combination of libraries and being careful gets the job done," would be a peculiar position for a rustacean to defend.

Re: The Rune Programming Language

#132

Post by tom_ »

kweingar wrote: post #118
wycy wrote: post #110

Earlier quoted context omitted.

It shouldn’t need to be a company policy, you’d think a competent engineer would simply do due diligence in naming their project. I remember searching for name clashes for a project I wrote solo when I was ~13 years old in the early 2000s.

Unfortunately Rob Pike, Ken Thompson, and Robert Griesemer are not competent engineers by this standard. I’m sure they’ll be sad to hear it.

The competence is assumed. The disappointment comes from people who are competent not doing the due diligence that some think should be par for the course when naming a project.

Re: The Rune Programming Language

#133

Post by mumblemumble »

prirun wrote: post #130

Instead 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 challenges because I'm not sure they realistically qualify as a disability. But my own meager experience in this department does demonstrate to me first-hand that "it would be nice if accessibility affordances were optional" largely defeats the purpose of accessibility.

Re: The Rune Programming Language

#134

Post by grantjpowell »

mumblemumble wrote: post #131
grantjpowell wrote: post #127

~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…

This Rust example seems like it misses the point? Rune detects that you're working with data that is marked as secret, and gives you a compiler guarantee that it's defending against some set of known attacks. The Rust code above depends on the programmer to consistently remember to enforce safety, and to do so correctly every time. Sure, you could probably implement that as a library. But, "We don't see much value in…

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>(mac_secret: Secret, message: &[u8], mac: &[u8]) -> bool {
        // This returns a new Secret
        let computed_mac = mac_secret.map(|secret| hmac_sha_256(secret.as_ref(), message));

        // This uses the `constant_time_eq` impl from above
        computed_mac == mac
    }
I think the interesting part of the example is what you _can't_ do in the other file. It's pretty hard to misuse because the return type of `Secret::map` is a new `Secret`, the only way to do `==` on a `Secret` uses a constant time compare.

I guess my main point is that when you have a instead of having to add new things at the language _level_, if I have something as powerful as the rust type system I can implement the same functionality in not much of code.

Re: The Rune Programming Language

#135

Post by 3a2d29 »

grantjpowell wrote: post #127

~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…

Compiler checking is always better than programmer checking.

As someone who uses rust, I assume you would prefer the former absolutely.

Re: The Rune Programming Language

#136

Post by cmdrk »

alpaca128 wrote: post #122
matheusmoreira wrote: post #115

Earlier 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.

The actual issue here is you acting like a name collision is a huge problem. It isn't, it's an everyday occurrence on Github alone. We just add a bit more info, like the account name in the case of Github or the year of release for movies/series/games etc.

name collision becomes a problem when at least one of the entities is willing to bring lawyers to bear. not saying that's happening here, but certainly more of a concern in a situation where you have a hobbyist going up against a big company.

Re: The Rune Programming Language

#137

Post by yccs27 »

grantjpowell wrote: post #134
mumblemumble wrote: post #131

Earlier quoted context omitted.

This Rust example seems like it misses the point? Rune detects that you're working with data that is marked as secret, and gives you a compiler guarantee that it's defending against some set of known attacks. The Rust code above depends on the programmer to consistently remember to enforce safety, and to do so correctly every time. Sure, you could probably implement that as a library. But, "We don't see much value in…

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.

Re: The Rune Programming Language

#138

Post by mumblemumble »

aflag wrote: post #117
henrydark wrote: post #75

Earlier quoted context omitted.

But it's not just operator overloading, there seems to be a monad-like "secret" that makes calls to func(a, ...) -> b with secret(a) return secret(b). The example doesn't spell this out explicitly, but I think those are the semantics of secret.

What makes that different from creating a Secret class that's just a container class and defines its own methods? I just don't see what it is that requires a new language to accomplish and couldn't just be implemented as a library in many of the pre-existing languages (including popular ones like C++).

It seems like we're focusing way too much on just the very first example, instead of the feature list as a whole?

There are plenty of other interesting features, such as disallowing conditional branching on the contents of secrets, all the way down to enforcing Spectre and Meltdown mitigations around secrets without necessarily globally taking that performance hit on sensitive and non-sensitive data alike.

Re: The Rune Programming Language

#139

Post by mumblemumble »

grantjpowell wrote: post #134
mumblemumble wrote: post #131

Earlier quoted context omitted.

This Rust example seems like it misses the point? Rune detects that you're working with data that is marked as secret, and gives you a compiler guarantee that it's defending against some set of known attacks. The Rust code above depends on the programmer to consistently remember to enforce safety, and to do so correctly every time. Sure, you could probably implement that as a library. But, "We don't see much value in…

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…

That covers the one case in the example, but the language goes even further than that in ensuring constant-time processing of secrets, including ensuring speculative execution in the CPU won't expose the data to timing attacks.

I don't know enough about the subject to really evaluate this in detail, but I am more than willing to at least entertain the notion that the problem space is thorny enough that a language-level solution really can do some things that can't be as effectively accomplished with a library solution. Even in a language with a strong compiler like Rust.

Rune also has an interesting approach to pointer safety that's significantly different from Rust's: https://github.com/google/rune/blob/main/doc/index.md#runes-...

Re: The Rune Programming Language

#140

Post by yccs27 »

kibwen wrote: post #113
anhner wrote: post #78

Is there any reason the `secret` type can't be implemented in, say, Rust, or is it just Google getting really excited to reinvent the wheel again?

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.
Post reply on HN