While Swift now has the `borrowing` and `consuming` keywords, support for storing references is nonexistent, and the only way to return/store `Span`s, etc, is only possible through using experimental `@lifetime` annotations.
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
I'm very impressed you managed to get nvidia to give you access to the 5070! I have one queetion though, is the 5070 limited to 100W because of the docking connector, or for cooling reasons?
MicroEmacs is small and lightweight. I port it to whatever machine I'm using, and it works nicely in a remote tty window. It doesn't need a customization language, as I just change the source code.
Recently, I added color syntax highlighting to it, and support for unicode characters.
Well, Rust barely has statements [1]. Nearly everything in Rust is an expression, and AFAIK statements /are/ essentially expressions that yield `()` [2].
> AFAIK statements /are/ essentially expressions that yield `()`
This isn't true. The inverse is true, "expression statements" can turn an expression into a statement.
What you're seeing in the playground is just how blocks are defined[1]:
> The syntax for a block is {, then any inner attributes, then any number of statements, then an optional expression, called the final operand, and finally a }.
In this case, you have one statement, and no optional expression.
And so:
> The type of a block is the type of the final operand, or () if the final operand is omitted.
So that's how this works.
Now, that being said, I don't think it's too terrible of a mental model to think of this situation in that way. But if we're getting into nitty-gritty details, that's not actually how it works.
No problem! This really only comes up in very edge cases anyway, which is partially why I don’t think it’s the worst mental model for most people. As long as you know that you can’t put let in expression position, that’s really the only place it goes wrong. Most people who haven’t used a language like Ruby would even think of items as being expressions in the first place.
> Does it interact with the borrow checker somehow?
Nope. The borrow checker cares about the control flow graph, expression vs statement doesn't matter.
> why does Rust make the expression/statement distinction?
I am not 100% sure. If I had to guess, older Rust was much less expression oriented, and then, over time, got moreso.
But also, I think it kinda just makes sense in general for the kind of language Rust is. Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects. Whereas in Rust, 95% of statements are declarations, and of those 95%, the only ones you really use in a normal execution context are let statements. The rest are stuff like "declaring functions" and "declaring structs" and those don't really get evaluated in a language like Rust.
let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition.
> Like, in Ruby, where everything truly is an expression, importing a file and then evaluating it has side effects.
In the context of ML, I think it's a more useful baseline. So declarations are still declarations, but e.g. ; is just a sequential evaluation operator.
> let being a statement is nice because it means it can only happen at the "top level" of a block, and not say, inside a loop condition.
I would argue that it's actually a downside - it means that a loop condition cannot have common subexpressions (that nevertheless need to be evaluated on every iteration) factored out.
If by most you mean 50% then sure. But the other 50% countries prefer to use different app. Be it Facebook Messenger or Telegram... In my eu country nobody has WhatsApp and its not uncommon. Network effects are at play so it's what became popular first.
I appreciate that I was a bit too confrontational in my first reply and should have just added that WeChat, Line and Telegram are also used (plus many others), not just WhatsApp.
Why I think I (over) reacted is that it was, to me, an example of only partial escape from US American insularity. They understood that ppl outside the USA don't use SMS much, but only suggested a US American messaging platform as what was used instead.
Sorry that I didn't much clarify the "pain" though:
It's quite like the experience of using parser combinator in Rust, where you could happily define the grammar and the parsing action using its existing utitlies. But once you have to do some easy wrapping, e.g. to make a combinator called `parenthesized` to surround an expression with parentheses, the "pain" kicks in, you have to leave as many trait bounds as possible since wiring the typing annotations become tedious. That came up while I was using framework like `winnow`.
Async Rust kinda shares some similar characteristics, utility functionalities might bring in many "typing wirings" that could terrify some people (well but I love it though).
I think this criticism is silly. Here's what your first example would look like in a language with keywords (where reasonable, perhaps like C#) instead:
But, this is still confusing! Let's remove even more symbols, and make the syntax more obvious by removing abbreviations:
PUBLIC FUNCTION Play
LIFETIMES
P
PARAMETERS
IN OUT Self
Player AS MUTABLE REFERENCE TO AnimationPlayer WITH LIFETIME P
NewAnimation AS AnimationNodeIndex
TransititionDuration AS Duration
RETURNS MUTABLE REFERENCE TO ActiveAnimation
BEGIN
...
END
IMO, using keywords instead of symbols for references, lifetimes, etc, would just make Rust overly verbose, and there's a reason BCPL used braces instead of BEGIN/END :^)
Well, ML (or at least the first versions of it) used a λx • x syntax [1] for λ-abstractions, the same (excluding the use of • over .) notation as used with the Lambda Calculus, and I've always assumed \ was an ASCII stand in.
That paper isn't showing real ML syntax itself; it's a mathematical presentation to demonstrate how the type system algorithm works. The actual original LCF/ML syntax would differ. I don't believe it used an actual lambda character, although for the life of me I can't find any evidence one way or another, not even in the LCF source code (https://github.com/theoremprover-museum/LCF77)
But yes, the slash is just an ASCII stand-in for a lambda.
ETA: I tracked down a copy of the Edinburgh LCF text and I have to eat crow. It doesn't use a lambda, but it does use a slash rather than a reserved word. The syntax, per page 22, is in fact, `\x. e`. Similar to Haskell's, but with a dot instead of an arrow.
Swift is a nice language, and it's new support for the bare necessity of affine types is a good step forward, but it's not at all comparable with Rust.
reply