181–190 of 203 posts
Any language that's implemented in C++ already starts with a handicap That's nice to see they went with C I like the syntax
Earlier quoted context omitted.
Don’t really buy it. Seems to be both “spherical cow optimistic assumptions” and “anyone who could seriously think about pulling this off has nation-state level resources and already 0wnz you and/or already has the rubber hose at hand"
Not really. It doesn't rely on that big of an assumption, nor does it require nation state resources[0]. When you're trying to find the secret you can make a bunch of requests and measure for statistically significant change, which can still be detectable beyond jitter & web server load. Also ignoring the fact that calling constant_strcompare(string, string) instead of strcompare(string, string) when working with sec…
Earlier quoted context omitted.
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.
No, I’m saying that nobody has “claim over the name”. Naming collisions happen all the time, and I don’t know why we get so bent out of shape about it. There are two multibillion-dollar software companies called Epic. There are a million businesses called AAA. I’ve been to three different breakfast restaurants called Sunrise.
What's up with having two different new experimental languages from Google on the front page https://news.ycombinator.com/item?id=33756800 - did Google just happen to release them at the same time? I think when Carbon came out people's reaction was stronger than deserved (like saying that Google don't believe in Rust, or that Go has been a failure because it hasn't replaced C++ etc.) while in reality all of this is v…
Promotion cycle, new unfinished languages.
"Hey I built a thing, let's toss it over the wall but let people know what not to expect" is a perfectly fine thing for anybody to do.
> 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?
This code, as written, makes left node accesses temporally correlated with other left node accesses (and by symmetry must do the same for right nodes), allowing the caches at all levels to have a higher hit rate. Whether that higher rate is actually attained depends on the architecture, compiler, other running code, linker, and all sorts of other garbage, but it has a lot higher chance of better behavior anyway.
Earlier quoted context omitted.
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 o…
With a strong type system, it knows if the input is bool or integer
There already exists Rune programming language and that one was earlier: https://rune-rs.github.io/ They should be more careful picking the name.
Who is the rightful owner of a name or similarly, a piece of land, or an idea, patent? The first settler? The first settler that held it for at least a year, 10 or 100? The most powerful entity claiming it? In the modern western mind there is the notion that whoever grabs it first rightfully owns it. Which is a simple rule, but encourages squatting and holding but not using. The squatter can then hold ransom against…
It used to be that if you have lived on the land for 3 generations it's yours.
Earlier 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…
Earlier quoted context omitted.
Why is that odd? You could provide a typed API in other languages that leverages a suite of different side-channel proof algorithms. In order to provide such an API, you need a portable language compatible with the C calling convention for FFI support in other languages. The only language that meets such criteria is C.
You can't provide an API that gives the security features they want in c. The core feature here is a generic secret type. In c that's a void*, defeating the purpose of the typed, safe, API.
// lib.h
struct SecureString {
uint8_t *content;
size_t len;
}
bool secure_str_eq(l *SecureString, r *SecureString) {
// some constant-time algorithm
}
SecureString *new_secur_string() {
struct SecureString *s = malloc(sizeof(struct SecureString));
// initialize s
return s;
}
// #include "lib.h"
import "C"
type SecureString struct {
ptr *C.struct_SecureString
}
func NewSecureString() *SecureString {
return &SecureString {
ptr: C.new_secure_string(),
}
}
func (s *SecureString) Eq(other SecureString*) bool {
return C.secure_str_eq(h.ptr, other.ptr)
}