Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Rusky
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
21 ms
·
241.
▲
by
Rusky
5y ago
Rust has equivalent functionality but it works on syntax trees rather than token streams, so you write `#[cfg(target_os = "macos")]` as an attribute rather than wrapping an arbitrary chunk of text in `#if`/`#endif`.
242.
▲
by
Rusky
5y ago
Indeed, it's a special case that relies on associativity, which is why it also works for + and *: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/continue...
243.
▲
by
Rusky
5y ago
IO is not (primarily) about where failures lie, but about where side effects lie- side effects are where you start caring about the order of execution. Array indexing failures, on the other hand, are not something you typically care about a
244.
▲
by
Rusky
5y ago
I do think the article's criticism of C++'s move semantics is fair. Rust's "copy" of both RAII and move semantics is drastically simpler, and C++'s version is part of what makes the language so huge.
245.
▲
by
Rusky
5y ago
> An exception that isn't thrown costs nothing. It costs binary size for unwinding tables, and in some cases it is an optimization barrier.
246.
▲
by
Rusky
5y ago
Ironically escape analysis is the one thing Rust went above and beyond to solve in a novel way.
247.
▲
by
Rusky
5y ago
> "async fn" is even misleading since the function itself returns synchronously (and immediately): it's the returned value where the async-ness lies. You've got the causality backwards- it's the async-ness that c
248.
▲
by
Rusky
5y ago
The difference between `await` and `?` is that the former completely transforms the entire function body containing it, while `?` just conditionally returns from it. (There's less of a difference to the caller of the function, where bo
249.
▲
by
Rusky
5y ago
The reason to mark a function as async (in today's Rust) is that you want to `await` something within it. If a function does this, it must be async- there's no other way to implement it. If a function does not do this, there is
250.
▲
by
Rusky
5y ago
Another interesting variant is a cross between 1 and 2- centralize ownership of the nodes, but continue to use references rather than handles. You can't do this with a Vec<Node> (unless you can create all the nodes up front befor
251.
▲
by
Rusky
5y ago
I think the article is just... wrong about async and closures. You're right that async Rust simply doesn't deal with them, because (contrary to the article) they're not used in the async compiler transformation.
252.
▲
by
Rusky
5y ago
> But such a type doesn't really mention the lifetimes of whatever it captures, so in practice it doesn't work well in Rust. It can: Box<dyn Fn(Arg) -> R + 'a> This is just the general syntax for any trait object
253.
▲
by
Rusky
5y ago
I'm not sure there's any causality between Windows preventing overcommit and Windows having slow process creation- there's nothing inherently slower about CreateProcess()/posix_spawn() than fork() + exec() as an API. It
254.
▲
by
Rusky
5y ago
That doesn't really make much sense for Rust, unfortunately. That is, for stack objects, LLVM/etc already do this and lifetimes don't add any useful new information. A function will generally adjust the stack pointer once to
255.
▲
by
Rusky
5y ago
It didn't start talking about "this." It started talking about something unrelated that you mistook for "this."
256.
▲
by
Rusky
5y ago
I am not talking about data oriented programming. With or without that sort of memory layout optimization, ECS "component" still refers to un-abstracted chunks of concrete data rather than interfaces/protocols/etc. Let&#
257.
▲
by
Rusky
5y ago
You are still conflating two totally unrelated things. The book is one of the first sources to move into discussing "components," as in coding against interfaces/protocols/traits/etc. ECS deals with "components
258.
▲
by
Rusky
5y ago
None of this stuff is NIH, it's just from a different lineage than C.
259.
▲
by
Rusky
5y ago
As an interesting related data point. Edge has a mode with no JIT and it might be usable for a lot of practical scenarios: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec... Our current software is de
260.
▲
by
Rusky
5y ago
Rust uses basically the same optimizer passes as Clang. Borrow checking is more like a type checking pass, not an optimization pass- it's pass/fail, and doesn't change the IR. Probably the most interesting thing to look at he
261.
▲
by
Rusky
5y ago
Right, you should get noalias optimizations within a particular locking, but not on the outer `&Mutex` references.
262.
▲
by
Rusky
5y ago
It goes further- immutable/shared references get the same treatment as they will not change out from under you either. The thing that disables it is interior mutability- types like `Mutex` or `Cell` that can be mutated through shared r
263.
▲
by
Rusky
5y ago
WASM JIT implementations tend to be quite a bit different from JavaScript JIT, so that's not really where the perf difference comes from. First, WASM gets all the heavy AOT optimizations from the middle end of the compiler producing it
264.
▲
by
Rusky
5y ago
> Also a language is neither fast nor slow, the implementation of said language is. I don't like how much this simplification gets used. Of course there is more than one way to implement a given language. But there is also more than
265.
▲
by
Rusky
5y ago
The changes to the IR data structures in this release are really neat- whole trees and graphs fit in a small fixed number of flat arrays. This saves on allocations, saves on total memory usage, and makes them trivial to serialize because th
266.
▲
by
Rusky
5y ago
That's not what I (or the standard, or compiler writers, or programming language researchers) mean by "semantics." From the perspective of defining and specifying a programming language, when we say "semantics" we m
267.
▲
by
Rusky
5y ago
Are you serious? Again: it's not up to the compiler at all, it's up to the spec. The spec indicates the current semantics won't change next week. The semantics for non-UB code are completely fixed across optimization levels a
268.
▲
by
Rusky
5y ago
> What you are asking programmers to do is to both master the fine points of UB (which is impractical) and look into the future to see what changes may be invisibly committed to the compiler code. I am asking programmers to understand an
269.
▲
by
Rusky
5y ago
That's not how it works. Taking advantage of UB doesn't change the semantics, it just exposes which behaviors were never in the semantics to begin with. Barring compiler or spec bugs, we do in principle know exactly when the com
270.
▲
by
Rusky
5y ago
> The idea that UB is carte blanche for implementations to do whatever is an unintended consequence of the vague language of the standard. Whether or not this was originally intended, it's certainly become the way the standard is wr
More ›