Unexpected productivity boost of Rust(lubeno.dev)
lubeno.dev
Unexpected productivity boost of Rust
https://lubeno.dev/blog/rusts-productivity-curve
510 comments
I've been writing Rust code for a while and generally if it compiles, it works. There are occasional deadlocks and higher-level ordering issues from time-to-time, but modulo bugs, the compiler succeeding generally means it'll run a decent amount of your project.
Though my code complexity is far FAR from what you've been writing it has been a similar experience for me. There are a few footguns and a bug in chrono I still have to find the energy to report or fix; which has been causing a bi-yearly issue, but apart from that happy lil programmer.
I would be curious to know if you've looked at `jiff`. Does it resolve your bug/footgun issues with chrono?
It's a lot like Haskell in that respect. Once you get something to compile, it tends to work more often than not.
Reviews like yours are increasing my interested towards Rust. Apparently the tools and ecosystem are great, build on solid concepts and foundation.
Rust has 3 major issues:
- compile times
- compile times
- long compile times
It isn't that big of a deal in small projects, but if you pull dependencies or have a lot of code you need to think about compilation units upfront.
- compile times
- compile times
- long compile times
It isn't that big of a deal in small projects, but if you pull dependencies or have a lot of code you need to think about compilation units upfront.
How is Rust in terms of incremental compile time? Is incrementally recompiling on file in a large project quick? Hopefully link times aren't that bad.
One thing I like about the JVM is hot code reloading. Most of the time, changes inside a method/function takes effect immediately with hot code reloading.
One thing I like about the JVM is hot code reloading. Most of the time, changes inside a method/function takes effect immediately with hot code reloading.
Link times are the worst part but solveable with mold[1]/sold. Incremental compilations are usually an order of magnitude (or even two) faster than clean compiles but tbh that can still feel slow. Helped by using something like sccache[2] or even cranelift[3] when debugging. Still not as fast as having a hot-reloadable language but it gets you to a relatively pleasant speed still IME
[1] https://github.com/rui314/mold [2] https://github.com/mozilla/sccache [3] https://github.com/rust-lang/rustc_codegen_cranelift
[1] https://github.com/rui314/mold [2] https://github.com/mozilla/sccache [3] https://github.com/rust-lang/rustc_codegen_cranelift
I've never been successful in getting sccache to really speed up projects, but then again only release builds have _really_ been impossible for me, and that's only when I was working on Deno which was absolutely massive.
sccache sped up my clean compiles by 2x on some projects, but it's a very YMMV solution most of the time
We had issues with long compile times at deno. Release builds were brutal, debug builds were OK as long as they were incremental. It was likely one of the largest open-source rust applications, but we were still quite productive.
Most likely you'll have years before it's an issue and there are mitigations.
Most likely you'll have years before it's an issue and there are mitigations.
I think Rust is awesome and I agree with that part of the article.
What I disagree with is that it's the fault of Typescript that the href assignment bug is not caught. I don't think that has anything to do with Typescript. The bug is that it's counter-intuitive that setting href defers the location switch until later. You could imagine the same bug in Rust if Rust had a `set_href` function that also deferred the work:
What I disagree with is that it's the fault of Typescript that the href assignment bug is not caught. I don't think that has anything to do with Typescript. The bug is that it's counter-intuitive that setting href defers the location switch until later. You could imagine the same bug in Rust if Rust had a `set_href` function that also deferred the work:
set_href('/foo');
if (some_condition) {
set_href('/bar');
}
Objection your honor ;)
A 'setter' should never ever cause an action to be triggered, and especially not immediately inside the setter.
At the least change the naming, like `navigate_to(href)`.
But in the browser environment it's also perfectly clear why it is not happening immediately, your entire JS code is essentially just a callback which serves the browser event loop and tells it what to do next. A function which never returns to the caller doesn't fit into the overall picture.
A 'setter' should never ever cause an action to be triggered, and especially not immediately inside the setter.
At the least change the naming, like `navigate_to(href)`.
But in the browser environment it's also perfectly clear why it is not happening immediately, your entire JS code is essentially just a callback which serves the browser event loop and tells it what to do next. A function which never returns to the caller doesn't fit into the overall picture.
That’s a good point. I actually modified my comment because I assumed everyone would take for granted that no work should be done in a setter :)
> A function which never returns to the caller doesn't fit into the overall picture.
Hmm, not sure about this. On the node side, you can process.exit() out of a callback. If setting href worked like that, I think it would be less confusing.
> A function which never returns to the caller doesn't fit into the overall picture.
Hmm, not sure about this. On the node side, you can process.exit() out of a callback. If setting href worked like that, I think it would be less confusing.
> If setting href worked like that, I think it would be less confusing.
How do you imagine this would interact with try-finally being used to clean up resources, release locks, close files, and so forth?
How do you imagine this would interact with try-finally being used to clean up resources, release locks, close files, and so forth?
try-finally is leaky in JavaScript, in any case. If your `try` block contains an `await` point, its finaliser may never run. The browser also has the right to stop running your tab’s process partway through a JavaScript callback without running any finalisers (for example, because the computer running the browser has been struck by lightning).
For this reason, try-finally is at best a tool for enforcing local invariants in your code. When a function like process.exit() completely retires the current JavaScript environment, there’s no harm in skipping `finally` blocks.
For this reason, try-finally is at best a tool for enforcing local invariants in your code. When a function like process.exit() completely retires the current JavaScript environment, there’s no harm in skipping `finally` blocks.
Thanks! I should have clarified a bit better that example.
The point I was trying to make is that Rust's ownership model would allow you to design an api where calling `window.set_href('/foo')` would take ownership of `window`. So you would not be able to call it twice. This possibility doesn't exist at all in TypeScript, because it doesn't track lifetimes.
Of course, TypeScript can't do anything here either way. Even if it had knowledge of lifetimes, the JavaScript API already existed before and it would not be possible to introduce an ownership model on top of it, because there are just too many global variables and APIs.
I wanted more to demonstrate how Rust's whole set of features neatly fits together and that it would be hard to get the same guarantees with "just types".
The point I was trying to make is that Rust's ownership model would allow you to design an api where calling `window.set_href('/foo')` would take ownership of `window`. So you would not be able to call it twice. This possibility doesn't exist at all in TypeScript, because it doesn't track lifetimes.
Of course, TypeScript can't do anything here either way. Even if it had knowledge of lifetimes, the JavaScript API already existed before and it would not be possible to introduce an ownership model on top of it, because there are just too many global variables and APIs.
I wanted more to demonstrate how Rust's whole set of features neatly fits together and that it would be hard to get the same guarantees with "just types".
I'm not as familiar with Rust, but isn't there still a gap? For instance, if we modified window.set_href to have move semantics, wouldn't this still work (i.e. not produce an error)?
In fact, Typescript does have a way to solve this problem - just make `setHref` return never[1]! Then subsequent calls to `setHref`, or in fact anything else at all, will be an error. If I understand correctly, this is similar to how `!` works in Rust.
So maybe TS is not so bad after all :)
[1]: https://www.typescriptlang.org/play/?ssl=9&ssc=1&pln=9&pc=2#...
let win = window.set_href("/foo")
win.set_href("/bar")
In fact, Typescript does have a way to solve this problem - just make `setHref` return never[1]! Then subsequent calls to `setHref`, or in fact anything else at all, will be an error. If I understand correctly, this is similar to how `!` works in Rust.
So maybe TS is not so bad after all :)
[1]: https://www.typescriptlang.org/play/?ssl=9&ssc=1&pln=9&pc=2#...
Your Rust example would not work, because `window.set_href("/foo")` would not return anything (it would return the unit type "()" aka void). And you can't call `set_href()` again on "()". This is a common pattern in Rust, allow certain functions to only be called once on specific objects.
I really like your TypeScript solution! This actually perfectly solves the issue. I just wish that this was the ONLY way to actually do it, so I would not have experience the issue in the first place.
I really like your TypeScript solution! This actually perfectly solves the issue. I just wish that this was the ONLY way to actually do it, so I would not have experience the issue in the first place.
Thanks for the explanation! That's a very nice pattern.
> I just wish that this was the ONLY way to actually do it
I completely agree.
> I just wish that this was the ONLY way to actually do it
I completely agree.
Just to add what the other comment said, take a look and run these two examples to see the errors you could get:
https://play.rust-lang.org/?version=stable&mode=debug&editio...
https://play.rust-lang.org/?version=stable&mode=debug&editio...
https://play.rust-lang.org/?version=stable&mode=debug&editio...
https://play.rust-lang.org/?version=stable&mode=debug&editio...
The Rust example was interesting but the Typescript example doesn't show if TS would or would not be good for a big project.
I'm scared of Ruby because I catch bugs at runtime all the time, but here's the thing: it ends up working before a commit and it was easy enough to get there and it's satisfying to read and edit the code. Now wether I can keep going like this if the project become bigger is the question.
The location.href issue is really a javascript problem that has been inherited by TS. Because JS allows to modify attributes, the browser kind of has to take the change into account. But it's not like Ruby's exit keyword. The page is still there until the next page loads and this makes total sense once you know it.
I'm scared of Ruby because I catch bugs at runtime all the time, but here's the thing: it ends up working before a commit and it was easy enough to get there and it's satisfying to read and edit the code. Now wether I can keep going like this if the project become bigger is the question.
The location.href issue is really a javascript problem that has been inherited by TS. Because JS allows to modify attributes, the browser kind of has to take the change into account. But it's not like Ruby's exit keyword. The page is still there until the next page loads and this makes total sense once you know it.
Technically Rust could hint at the semantics, based on whether `set_href` returned `()` or `!`. However the “erroneous” usage would not be surfaced in the case of a conditional redirect indeed (for a non-conditional one you may notice that the following code is not dead).
That is not a repo of the code in the article. The article's code is effectively
The browser does not start a process when you set `window.location.href`. It starts a process after your code exits and lets the event loop run other tasks. The `await` in the example code is what allow other tasks to run, including the task to load a new page, (or quit an app, etc..) That task that was added when you set `window.location.href`
If that's not clear
set_href('/foo');
let future = doSomethingElse()
block_on(future)
if (some_condition) {
set_href('/bar');
}
The browser does not start a process when you set `window.location.href`. It starts a process after your code exits and lets the event loop run other tasks. The `await` in the example code is what allow other tasks to run, including the task to load a new page, (or quit an app, etc..) That task that was added when you set `window.location.href`
If that's not clear
// task 1
window.location.href = '/foo' // task2 (queues task2 to load the page)
let content = await response.json(); // adds task3 to load json
// which will add task4
// to continue when finished
// task4
if (content.onboardingDone) {
window.location.href = "/dashboard";
} else {
window.location.href = "/onboarding";
}
No, I think you misunderstand how it works. The problem is that task 4, as you call it, runs after the navigation triggered by the redirect value.
The the author expects the side-effect -- navigation to a new page -- of the window.location.href setter to abort the code running below it. This obviously won't happen because there is no return in the first if-statement.
The the author expects the side-effect -- navigation to a new page -- of the window.location.href setter to abort the code running below it. This obviously won't happen because there is no return in the first if-statement.
There is a return, it's disguised as "await"
*simplified*, the symantics of "await" are just syntactic sugar
*simplified*, the symantics of "await" are just syntactic sugar
const value = await someFunction()
console.log(value);
return someFunction().then(function(value) {
// this gets executed after the return IF
// something else didn't remove all events like
// loading a new page
console.log(value);
});Yeah, the problem is that some old web APIs have been clearly hacked up haphazardly in the '90s, probably in a hurry, and now we have to live with the consequences of that. This is not unique with the Web though, it's basically the same with the entirety of the WinAPI and most libc functions in my experience
So, your argument is that Rust is better because better programers use Rust.
I specifically mean this part: "Rust would never have such a dumb library design".
One could then also say that Rust programmers would never make such a cyclical argument.
I specifically mean this part: "Rust would never have such a dumb library design".
One could then also say that Rust programmers would never make such a cyclical argument.
If you want to be more charitable, you could say "Rust library design is superior to the Web API library design", and I'd say you were right - particularly for crufty stuff like .href which was designed decades ago.
Code written below your line gets executed if you don't return early. More breaking news at 8.
Seriously, why would you think that assigning a value would stop your script from executing? Maybe the Typescript example is missing some context, but it seems like such a weird case to present as a "data race".
Seriously, why would you think that assigning a value would stop your script from executing? Maybe the Typescript example is missing some context, but it seems like such a weird case to present as a "data race".
Assigning to `window.location.href` has a side effects. The side effect is that your browser will navigate to wherever you assigned, as if you had clicked a link. This is already a surprising behaviour, but given that this assignment is effectively loading a new page in-place, kind of like how `execve` does for a process, I can totally see how someone would think that JS execution would stop immediately after a link is clicked.
It's obviously not a good idea to rely on such assumptions when programming, and when you find yourself having such a hunch, you should generally stop and verify what the specification actually says. But in this case, the behaviour is weird, and all bets are off. I am not at all surprised that someone would fall for this.
It's obviously not a good idea to rely on such assumptions when programming, and when you find yourself having such a hunch, you should generally stop and verify what the specification actually says. But in this case, the behaviour is weird, and all bets are off. I am not at all surprised that someone would fall for this.
Part of the problem is that we unknowingly make a million little assumptions every day in the course of software development. Many of them are reasonable, some of them are technically unreasonable but fine in practice, and some of them are disasters waiting to happen. And it's genuinely hard to not only know which are which, but to notice even a fraction of them in the first place.
I'm sure I knew the href thing at one point. It's probably even in the documentation. But the API itself leaves a giant hole for this kind of misunderstanding, and it's almost certainly a mistake that a huge number of people have made. The more pieces of documentation we need to keep in our heads in order to avoid daily mistakes, the exponentially more likely it is we're going to make them anyway.
Good software engineering is, IMHO, about making things hard to hold the wrong way. Strong types, pure functions without side effects (when possible), immutable-by-default semantics, and other such practices can go a long way towards forming the basis of software that is hard to misuse.
I'm sure I knew the href thing at one point. It's probably even in the documentation. But the API itself leaves a giant hole for this kind of misunderstanding, and it's almost certainly a mistake that a huge number of people have made. The more pieces of documentation we need to keep in our heads in order to avoid daily mistakes, the exponentially more likely it is we're going to make them anyway.
Good software engineering is, IMHO, about making things hard to hold the wrong way. Strong types, pure functions without side effects (when possible), immutable-by-default semantics, and other such practices can go a long way towards forming the basis of software that is hard to misuse.
This is actually mostly related to a language's expressivity, which can simultaneously be used for good and for obscure stuff. (Also, JS having a rough evolution from a badly designed scripting language with hacky injection points to the browser, to being an industrial language at the core of the modern web, with strong backwards compatibility)
This can be made into an extreme (e.g. C/Zig tries to make every line understandable locally - on the other extreme we have overloading any symbols, see Haskell/Scala).
This can be made into an extreme (e.g. C/Zig tries to make every line understandable locally - on the other extreme we have overloading any symbols, see Haskell/Scala).
Honestly, the href thing feels like a totally reasonable assumption to me. I think the API design is unfortunate, but given that the API is designed as it is, it stands to reason that the script would also halt execution upon hitting that line.
For me, that's exactly the kind of thing that I tend to be paranoid about and handle defensively by default. I couldn't have confidently told you before today what the precise behavior of setting location.href was without looking it up, but I can see that code I wrote years ago handled it correctly regardless, because it cost me nothing at the time to proactively throw in a return statement.
As in this example, defensiveness can often prevent frustrating heisenbugs. (Not just from false assumptions, but also due to correct assumptions that are later invalidated by third-party changes.) Even when technically unnecessary, it can still be a valid stylistic choice that improves readability by reducing ambiguity.
For me, that's exactly the kind of thing that I tend to be paranoid about and handle defensively by default. I couldn't have confidently told you before today what the precise behavior of setting location.href was without looking it up, but I can see that code I wrote years ago handled it correctly regardless, because it cost me nothing at the time to proactively throw in a return statement.
As in this example, defensiveness can often prevent frustrating heisenbugs. (Not just from false assumptions, but also due to correct assumptions that are later invalidated by third-party changes.) Even when technically unnecessary, it can still be a valid stylistic choice that improves readability by reducing ambiguity.
> because it cost me nothing at the time to proactively throw in a return statement
This is how I’ve generally always handled redirects, be it server or client - if I’m redirecting the user somewhere else, my expectation is that nothing else on this page or in this script _should_ run. Will it? Maybe, JavaScript is weird. To avoid the possibility, I’m going to return instead of just hoping that my expectations are met.
This is how I’ve generally always handled redirects, be it server or client - if I’m redirecting the user somewhere else, my expectation is that nothing else on this page or in this script _should_ run. Will it? Maybe, JavaScript is weird. To avoid the possibility, I’m going to return instead of just hoping that my expectations are met.
> when you find yourself having such a hunch, you should generally stop and verify what the specification actually says
It greatly heartens me that we've made it to the point where someone writing Javascript for the browser is recommended to consult a spec instead of a matrix of browsers and browser versions.
However, that said, why would a person embark on research instead of making a simple change to the code so that it relies on fewer assumptions, and so that it's readable and understandable by other programmers on their team who don't know the spec by heart?
It greatly heartens me that we've made it to the point where someone writing Javascript for the browser is recommended to consult a spec instead of a matrix of browsers and browser versions.
However, that said, why would a person embark on research instead of making a simple change to the code so that it relies on fewer assumptions, and so that it's readable and understandable by other programmers on their team who don't know the spec by heart?
Is this a JavaScript wart or a browser wart though? JavaScript is communicating to the browser via an API and rust would need to do the same.
exit(), execve(), and friends do immediately stop execution—I could understand why you'd think a redirect would as well.
Exactly. Given that JavaScript runs in the context of a page, redirecting off of the page seems like it should act like a "noreturn" function...but it doesn't. That seems like a very easy mistake to make.
Until they don't. A common issue is not checking if the execve() actually worked and thinking nothing after the execve() will execute, which is an assumption that it not always true.
See, that's what they meant about making assumptions upthread:
https://man7.org/linux/man-pages/man3/atexit.3.html
https://man7.org/linux/man-pages/man3/atexit.3.html
The redirect is an assignment. In no language has a variable assignment ever stopped execution.
$ python3
Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class MagicRedirect:
... def __setattr__(self, name, value):
... if name == "href":
... print(f"Redirecting to {value}")
... exit()
...
>>> location = MagicRedirect()
>>> location.href = "https://example.org/"
Redirecting to https://example.org/
$You're overloading a setter here. It's cute, I did it in JS as well, but I don't really think it's a counterexample. It would be odd to consider this the norm (per the thought process of the original blog post).
This is not some weird thing. Here is a run of the mill example where python can have properties settting do anything at all. And it's designed like that.
import sys
class Foo:
@property
def bar(self):
return 10
@bar.setter
def bar(self, value):
print("bye")
sys.exit()
foo = Foo()
foo.bar = 10
using System;
class Foo
{
public int Bar
{
get { return 10; }
set
{
Console.WriteLine("bye.");
Environment.Exit(0);
}
}
}
class Program
{
static void Main()
{
Foo obj = new Foo();
obj.Bar = 10;
}
}
You're also overriding a setter. Maybe I'm going against the grain here, but it's absolutely esoteric. The assignment operator is not supposed to have side-effects, and maybe this is the logician in me, but the implication that we should be aware that weird stuff might be happening when we do `x = 5` is fundamentally bonkers.
You started with "In no language has a variable assignment ever stopped execution", and now you're saying "The assignment operator is not supposed to have side-effects". location.href is a counterexample, and there are many counterexamples throughout various tools and languages and libraries. Deciding how you think things should work does not affect how things do work, and it's important to understand the latter. (I do agree it's bad practice, but it happens and people do not always fully control the environments they must work with.)
And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous.
That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.
And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous.
That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.
> You started with "In no language has a variable assignment ever stopped execution",
The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).
The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).
The entire discussion is about a property assignment. Which in colloquial usage is also called variable assignment. Which is obvious since nobody corrected you on that. You now trying to do a switcheroo is honestly ridiculous.
The entire discussion is about “=“ doing weird stuff, which in 99.9% of cases it does not do. And my point was that no language, without doing weird stuff (like overloading), does not let “=“ do weird stuff (and thus is pure). The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.
> The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.
That sounds like a recipe for having problems every time you encounter a nonstandard contract. Are you actually saying you willfully decide never to account for the possibility, or are you conflating "ought not to be" with "isn't"?
If I'm programming in a language that has the possibility of properties, it's absolutely a potential expectation at any time. Which is one reason I don't enjoy programming in such languages as much.
To give a comparable example: if I'm coding in C, "this function might actually be a macro" is always a possibility to be on guard against, if you do anything that could care about the difference (e.g. passing the function's name as a function pointer).
That sounds like a recipe for having problems every time you encounter a nonstandard contract. Are you actually saying you willfully decide never to account for the possibility, or are you conflating "ought not to be" with "isn't"?
If I'm programming in a language that has the possibility of properties, it's absolutely a potential expectation at any time. Which is one reason I don't enjoy programming in such languages as much.
To give a comparable example: if I'm coding in C, "this function might actually be a macro" is always a possibility to be on guard against, if you do anything that could care about the difference (e.g. passing the function's name as a function pointer).
So, with anything that isn't a primitive type (e.g. int, bool, etc), there's a chance that assignment is going to require memory allocation or something similar. If that's the case then there's a chance of bad things happening (e.g. a out of memory error and the program being killed).
More commonly, if you look at things like c++'s unique_ptr, assignment will do a lot of things in the background in order to keep the unique_ptr properties consistent. Rust and other languages probably do similar things with certain types due to semantic guarantees.
More commonly, if you look at things like c++'s unique_ptr, assignment will do a lot of things in the background in order to keep the unique_ptr properties consistent. Rust and other languages probably do similar things with certain types due to semantic guarantees.
Technically no. Producing side effects from a setter is not unexpected, even if it often the best idea to have a setter have a lot of unexpected side effects. However producing side effects from getters is definitely unexpected and should not be done. Interestingly it's one of the areas where rust is really useful, it forces you express your intent in terms of mutability and is able to enforce these expectations we have.
Overloading assignment operators to maintain an invariant is one thing, but this particular case of it running off and effectively doing ionis weird to me coming from an embedded c++ background. I don't like operator overloading and think it should be avoided, just to make my bias obvious. I don't code c++ anymore either, rust and no looking back for a few years now.
But it doesn't run off and do I/O ... that's the bug! The OP assumed that setting the variable causes the new page to be loaded but it doesn't--it just says what page should be loaded. The page doesn't get loaded until the app goes idle. So this whole discussion about setters and side effects is completely off kilter.
> Interestingly it's one of the areas where rust is really useful, it forces you express your intent in terms of mutability and is able to enforce these expectations we have.
Though Rust only cares about mutability, it doesn't track whether you are going to launch the nukes or format the hard disk.
Though Rust only cares about mutability, it doesn't track whether you are going to launch the nukes or format the hard disk.
True. But I would not expect any programming language to do that.
Rust provides safeguards and helps you to enforce mutability and ownership at the language level, but how you leverage those safeguards is still up to you.
If you really want it you can still get Rust to mutate stuff when you call a non mutable function after all. Like you could kill someone with a paper straw
Rust provides safeguards and helps you to enforce mutability and ownership at the language level, but how you leverage those safeguards is still up to you.
If you really want it you can still get Rust to mutate stuff when you call a non mutable function after all. Like you could kill someone with a paper straw
Assignment is by definition a side effect.
This whole discussion is completely off kilter by all parties because setting the variable doesn't terminate the script--that's the bug; it simply sets the variable (that is, it sets a property in a globally accessible structure). Rather, some time later the new page is loaded from the variable that was set.
Aside from that, your comments are riddled with goalpost moving and other unpleasant fallacies and logic errors.
FWIW I grew up in the days (well, actually I was already an adult who had been programming for a decade) when storing values in the I/O page of PDP-11 memory directly changed the hardware devices that mapped their operation registers to those memory addresses. That was the main reason for the C `volatile` keyword.
This whole discussion is completely off kilter by all parties because setting the variable doesn't terminate the script--that's the bug; it simply sets the variable (that is, it sets a property in a globally accessible structure). Rather, some time later the new page is loaded from the variable that was set.
Aside from that, your comments are riddled with goalpost moving and other unpleasant fallacies and logic errors.
FWIW I grew up in the days (well, actually I was already an adult who had been programming for a decade) when storing values in the I/O page of PDP-11 memory directly changed the hardware devices that mapped their operation registers to those memory addresses. That was the main reason for the C `volatile` keyword.
> The assignment operator is not supposed to have side-effects,
Memory mapped I/O disagrees with this. Writing a value can trigger all sorts of things.
Memory mapped I/O disagrees with this. Writing a value can trigger all sorts of things.
assignments are side effects, even more so when they are done through a setter on an object / class instance
But window.location.href is already an overloaded setter. It schedules a page navigation.
> The redirect is an assignment. In no language has a variable assignment ever stopped execution.
Many languages support property assignment semantics which are defined in terms of a method invocation. In these languages, the method invoked can stop program execution if the runtime environment allows it to do so.
For example, source which is defined thusly:
Many languages support property assignment semantics which are defined in terms of a method invocation. In these languages, the method invoked can stop program execution if the runtime environment allows it to do so.
For example, source which is defined thusly:
foo.bar = someValue
foo.setBar (someValue)Try this in C:
*(int*)0 = 0;
Modern C compilers could require you to complicate this enough to confuse them, because their approach to UB is weird, if they saw an UB they could do anything. But in olden days such an assignment led consistently to SIGSEGV and a program termination.
*(int*)0 = 0;
Modern C compilers could require you to complicate this enough to confuse them, because their approach to UB is weird, if they saw an UB they could do anything. But in olden days such an assignment led consistently to SIGSEGV and a program termination.
Unless you were on systems that mapped address 0 to a writable but always zero value so they could do load and store speculation without worry.
IBM did this for a long time
IBM did this for a long time
My favourite were older embedded systems where 0 was an address you actually do interact with. So for some portion of the code you WANT null pointer access. I can't remember the details but I do remember jumping to null to reset the system being pretty common.
[deleted]
In Wasm you can read/write whatever to address zero of linear memory.
It's still UB as far as clang is concerned so you C code can do whatever. But it won't “crash” on the spot.
It's still UB as far as clang is concerned so you C code can do whatever. But it won't “crash” on the spot.
You could overload operator=() in C++ with a call to exit(), which fulfills "variable assignment that halts the program".
And for a Rust contrived example, making += terminate execution,
use std::ops::AddAssign;
use std::process;
#[derive(Debug, Copy, Clone, PartialEq)]
struct Point {
x: i32,
y: i32,
}
impl AddAssign for Point {
fn add_assign(&mut self, other: Self) {
*self = Self {
x: self.x + other.x,
y: self.y + other.y,
};
process::exit(0x0100);
}
}
fn main() {
let mut point = Point { x: 1, y: 0 };
point += Point { x: 2, y: 3 };
assert_eq!(point, Point { x: 3, y: 3 });
}I was ignoring these kinds of fancy overload cases, but even in JS you can mess with setters to get some unexpected behavior (code below).
That doesn't seem that obvious to me. You could have a setter that just calls exit and terminates the whole program.
Yeah, this is actually a good point, could have a custom setter theoretically that simply looks like assignment, but does some fancy logic.
const location = {
set current(where) {
if (where == "boom") {
throw new Error("Uh oh"); // Control flow breaks here
}
}
};
location.current = "boom" // exits control flow, though it looks like assignment, JS is dumb lolIn Blink setHref is automatically bound to C++ code [1]. I think it's fair to say that anything goes.
[1]: https://source.chromium.org/chromium/chromium/src/+/main:thi...
[1]: https://source.chromium.org/chromium/chromium/src/+/main:thi...
It seems weird to shame someone for talking about their own experience?
Whether you think that or not is not the issue - the fix is very obvious once pointed out to you. The arguement the author is making is that a bug like that TS issue can be very difficult and time consuming to track down and is not picked up on by the compiler.
Whenever someone talks about a surprising paper cut like this you always see misguided "this is obvious" comments.
No shit. It's obvious because you literally just read a blog post explaining it. The point is if you sprinkle dozens of "obvious" things through a large enough code based, one of them is going to bite you sooner or later.
It's better if the language helps you avoid them.
No shit. It's obvious because you literally just read a blog post explaining it. The point is if you sprinkle dozens of "obvious" things through a large enough code based, one of them is going to bite you sooner or later.
It's better if the language helps you avoid them.
> Seriously, why would you think that assigning a value would stop your script from executing?
This assignment has a significant side-effect of leaving the page, assuming this is immediate rather than a scheduled asynchronous action is not unfair (I’m pretty sure I assumed the same when I saw or did that).
This assignment has a significant side-effect of leaving the page, assuming this is immediate rather than a scheduled asynchronous action is not unfair (I’m pretty sure I assumed the same when I saw or did that).
This is more a control flow issue than a data race issue. I've seen this countless times. And it is often a sign that you don't spend too much time writing JavaScript/Typescript. You get shot in the foot by this very often. And some linters will catch this - most do actyally
OP thought the redirect was synchronous, not that it would stop the script from executing
No, you're mistaken. Read the other comments under the parent. If it were synchronous then it would have stopped the script from executing, much the way POSIX exec() works. If the OP didn't think that the script would stop, then why would he let execution fall through to code that should not execute ... which he fixed by not letting it fall through?
I see, thanks
Don't most of the benefits just come down to using a statically typed and thus compiled language? Be it Java, Go or C++; TypeScript is trickier, because it compiles to JavaScript and inherits some issues, but it's still fine.
I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read
I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read
To a large extent yes, but Rust adds more dimensions to the type system: ownership, shared vs exclusive access, thread safety, mutually-exclusive fields (sum types).
Ownership/borrowing clarifies whether function arguments are given only temporarily to view during the call, or whether they're given to the function to keep and use exclusively. This ensures there won't be any surprise action at distance when the data is mutated, because it's always clear who can do that. In large programs, and when using 3rd party libraries, this is incredibly useful. Compare that to that golang, which has types for slices, but the type system has no opinion on whether data can be appended to a slice or not (what happens depends on capacity at runtime), and you can't lend a slice as a temporary read-only view (without hiding it behind an abstraction that isn't a slice type any more).
Thread safety in the type system reliably catches at compile time a class of data race errors that in other languages could be nearly impossible to find and debug, or at very least would require catching at run time under a sanitizer.
Ownership/borrowing clarifies whether function arguments are given only temporarily to view during the call, or whether they're given to the function to keep and use exclusively. This ensures there won't be any surprise action at distance when the data is mutated, because it's always clear who can do that. In large programs, and when using 3rd party libraries, this is incredibly useful. Compare that to that golang, which has types for slices, but the type system has no opinion on whether data can be appended to a slice or not (what happens depends on capacity at runtime), and you can't lend a slice as a temporary read-only view (without hiding it behind an abstraction that isn't a slice type any more).
Thread safety in the type system reliably catches at compile time a class of data race errors that in other languages could be nearly impossible to find and debug, or at very least would require catching at run time under a sanitizer.
What annoys me about borrowing is, that my default mode of operating is to not mutate things if I can avoid it, and I go to some length in avoiding it, but Rust then forces me to copy or clone, to be able to use things, that I won't mutate anyway, after passing them to another procedure. That creates a lot of mental and syntactical overhead. While in an FP language you are passing values and the assumption is already, that you will not mutate things you pass as arguments and as such there is no need to have extra stuff to do, in order to pass things and later still use them.
Basically, I don't need ownership, if I don't mutate things. It would be nice to have ownership as a concept, in case I do decide to mutate things, but it sucks to have to pay attention to it, when I don't mutate and to carry that around all the time in the code.
Basically, I don't need ownership, if I don't mutate things. It would be nice to have ownership as a concept, in case I do decide to mutate things, but it sucks to have to pay attention to it, when I don't mutate and to carry that around all the time in the code.
It sounds like you may not actually know Rust then because non-owning borrow and ownership are directly expressible within the type system:
Non-owning non mutating borrow that doesn’t require you to clone/copy:
Non-owning non mutating borrow that doesn’t require you to clone/copy:
fn foo(v: &SomeValue)
fn foo(v: SomeValue)
fn foo(mut v: SomeValue)
Can you give examples of the calls for these procedures? Because in my experience when I pass a value (not a reference), then I must borrow the value and cannot use it later in the calling procedure. Passing a reference of course is something different. That comes with its own additional syntax that is needed for when you want to do something with the thing that is referred to.
> Because in my experience when I pass a value (not a reference), then I must borrow the value and cannot use it later in the calling procedure.
Ah, you are confused on terminology. Borrowing is a thing that only happens when you make references. What you are doing when you pass a non-copy value is moving it.
Generally, anything that is not copy you pass to a function should be a (non-mut) reference unless it's specifically needed to be something else. This allows you to borrow it in the callee, which means the caller gets it back after the call. That's the workflow that the type system works best with, thanks to autoref having all your functions use borrowed values is the most convenient way to write code.
Note that when you pass a value type to a function, in Rust that is always a copy. For non-copy types, that just means move semantics meaning you also must stop using it at the call site. You should not deal with this in general by calling clone on everything, but instead should derive copy on the types for which it makes sense (small, value semantics), and use borrowed references for the rest.
Ah, you are confused on terminology. Borrowing is a thing that only happens when you make references. What you are doing when you pass a non-copy value is moving it.
Generally, anything that is not copy you pass to a function should be a (non-mut) reference unless it's specifically needed to be something else. This allows you to borrow it in the callee, which means the caller gets it back after the call. That's the workflow that the type system works best with, thanks to autoref having all your functions use borrowed values is the most convenient way to write code.
Note that when you pass a value type to a function, in Rust that is always a copy. For non-copy types, that just means move semantics meaning you also must stop using it at the call site. You should not deal with this in general by calling clone on everything, but instead should derive copy on the types for which it makes sense (small, value semantics), and use borrowed references for the rest.
It is not possible then to pass a value (not a reference) and not implement or derive Copy or Clone, if I understand you correctly. That was my impression earlier. Other languages let you pass a value, and I just don't mutate that, if I can help it. I usually don't want to pass a reference, as that involves syntactical "work" when wanting to use the referenced thing in the callee. In many other languages I get that at no syntactical cost. I pass the thing by its name and I can use it in the callee and in the caller after the call.
What I would prefer is, that Rust only cares about whether I use it in the caller after the call, if I pass a mutable value, because in that case, of course it could be unsafe, if the callee mutates it.
Sometimes Copy cannot be derived and then one needs to implement it or Clone. A few months ago I used Rust again for a short duration, and I had that case. If I recall correctly it was some Serde struct and Copy could not be derived, because the struct had a String or &str inside it. That should a be fairly common case.
What I would prefer is, that Rust only cares about whether I use it in the caller after the call, if I pass a mutable value, because in that case, of course it could be unsafe, if the callee mutates it.
Sometimes Copy cannot be derived and then one needs to implement it or Clone. A few months ago I used Rust again for a short duration, and I had that case. If I recall correctly it was some Serde struct and Copy could not be derived, because the struct had a String or &str inside it. That should a be fairly common case.
You can pass a value that is neither copy or clone, but then it gets moved into the callee, and is no longer available in the caller.
Note that calling by value is expensive for large types. What those other languages do is just always call by reference, which you seem to confuse for calling by value.
Rust can certainly not do what you would prefer. In order to typecheck a function, Rust only needs the code of that function, and the type defitions of everything else, the contents of the functions don't matter. This is a very good rule, which makes code much easier to read.
Note that calling by value is expensive for large types. What those other languages do is just always call by reference, which you seem to confuse for calling by value.
Rust can certainly not do what you would prefer. In order to typecheck a function, Rust only needs the code of that function, and the type defitions of everything else, the contents of the functions don't matter. This is a very good rule, which makes code much easier to read.
Is it expensive in Rust? Normally only data in stack gets copied. Heap data is untouched
Yes, but if you have a large value type it will be on the stack unless you manually box it. Passing by value can get quite expensive quite fast, especially if the value keeps being passed up and down the call chain.
Is this really true? What do you mean by value types? The types that implement copy or any struct types? Because I think struct types only get moved
Move and copy are both the same operation under the hood, move just means that the old version is marked invalid and not available for use anymore.
For large structs (or enums), move and copy both compile into memcpy. If the structures are large, this can take a lot of time.
For large structs (or enums), move and copy both compile into memcpy. If the structures are large, this can take a lot of time.
Yes, Rust will not automatically turn a value into a reference for you. A reference is the semantic you desire. If you have a value, you’re gonna have to toss & on it. That’s the idiomatic way to do this, not to pass a value and clone it.
&str is Copy, String is not.
&str is Copy, String is not.
> Other languages let you pass a value, and I just don't mutate that, if I can help it
How do they do that without either taking a reference or copying/cloning automatically for you? Would be helpful if you provide an example.
How do they do that without either taking a reference or copying/cloning automatically for you? Would be helpful if you provide an example.
I did not state, that they don't automatically copy or clone things.
I might be wrong what they actually do though. It seems I merely dislike the need to specify & for arguments and then having to deal with the fact, that inside procedures I cannot treat them as values, but need to stay aware, that they are merely references.
I might be wrong what they actually do though. It seems I merely dislike the need to specify & for arguments and then having to deal with the fact, that inside procedures I cannot treat them as values, but need to stay aware, that they are merely references.
C++ auto copies as well, it's just a feature of value semantics. References must be taken manually - versus Java or C#, where we assume reference and then have to explicitly say copy. Rust, I believe, usually moves by default - not copy, but close - for most types.
The nice thing about value semantics is they are very safe and can be very performant. Like in PHP, if we take array that's a copy. But not really - it's secretly COW under the hood. So it's actually very fast if we don't mutate, but we get the safety of value semantics anyway.
The nice thing about value semantics is they are very safe and can be very performant. Like in PHP, if we take array that's a copy. But not really - it's secretly COW under the hood. So it's actually very fast if we don't mutate, but we get the safety of value semantics anyway.
Rust will transparently copy values for types that declare the Copy trait. But the default is move which is probably what C++ would have chosen had they had the 30+ years of language research to experiment with that Rust did + some other language to observe what worked and what didn't.
The pattern you're looking for is:
``` fn operate_on_a(a: A) -> A { // do whatever as long as this scope still owns A a } ```
``` fn operate_on_a(a: A) -> A { // do whatever as long as this scope still owns A a } ```
If all you're doing is immutable access, you are perfectly free to immutably borrow the value as many times as you want (even in a multithreaded environment provided T is Send):
But otherwise I'm not clear what ownership semantics you're trying to express - would be helpful if you could give an example.
let v = SomeValue { ... }
foo(&v);
foo(&v);
eprintln!("{}", v.xyz);
But otherwise I'm not clear what ownership semantics you're trying to express - would be helpful if you could give an example.
I share the same pet peeve, it's not that it's not possible. It's that I would prefer copy and or move to be the default when assigning stuff. Kind of like the experience you get using STL stuff in c++.
Copy can’t be for types that aren’t copyable because there could be huge performance cliffs hiding (eg copying a huge vector which is the default in c++).
But Rust always moves by default when assigning so I’m not sure what your complaint is. If the type declares it implements Copy then Rust will automatically copy it on assignment if there’s conflicting ownership.
But Rust always moves by default when assigning so I’m not sure what your complaint is. If the type declares it implements Copy then Rust will automatically copy it on assignment if there’s conflicting ownership.
I have been thinking about how to express it.
My complaint is that because moves are the default, member access and container element access typically involves borrowing, and I don't like dealing with borrowed stuff.
It's a personal preference thing, I would prefer that all types were copy and only types marked as such were not.
I get why the rust devs went the other way and it makes sense given their priorities. But I don't share them.
Ps: most of the time I write python where references are the default but since I don't have to worry about lifetimes, the borrow checker, or leaks. I am much happier with that default.
My complaint is that because moves are the default, member access and container element access typically involves borrowing, and I don't like dealing with borrowed stuff.
It's a personal preference thing, I would prefer that all types were copy and only types marked as such were not.
I get why the rust devs went the other way and it makes sense given their priorities. But I don't share them.
Ps: most of the time I write python where references are the default but since I don't have to worry about lifetimes, the borrow checker, or leaks. I am much happier with that default.
You're not talking about copying values. You want it to be easy to have smart references and copy them around like you do in Python and Java, but it's more complicated in Rust because it doesn't have a GC like Python and Java.
In Rust, "Copy" means that the compiler is safe to bitwise copy the value. That's not safe for something like String / Vec / Rc / Arc etc where copying the bits doesn't copy the underlying value (e.g. if you did that to String you'd get a memory safety violation with two distinct owned Strings pointing to the same underlying buffer).
It could be interesting if there were an "AutoClone" trait that acted similarly to Copy where the compiler knew to inject .clone when it needed to do so to make ownership work. That's probably unlikely because then you could have something implement AutoClone that then contains a huge Vector or huge String and take forever to clone; this would make it difficult to use Rust in a systems programming context (e.g. OS kernel) which is the primary focus for Rust.
BTW, in general Rust doesn't have memory leaks. If you want to not worry about lifetimes or the borrow checker, you would just wrap everything in Arc<Mutex<T>> (when you need the reference accessed by multiple threads) / Rc<RefCell<T>> (single thread). You could have your own type that does so and offers convenient Deref / DerefMut access so you don't have to borrow/lock every time at the expense of being slower than well-written Rust) and still have Python-like thread-safety issues (the object will be internally consistent but if you did something like r.x = 5; r.y = 6 you could observe x=5/y=old value or x=5/y=6). But you will have to clone explicitly the reference every time you need a unique ownership.
In Rust, "Copy" means that the compiler is safe to bitwise copy the value. That's not safe for something like String / Vec / Rc / Arc etc where copying the bits doesn't copy the underlying value (e.g. if you did that to String you'd get a memory safety violation with two distinct owned Strings pointing to the same underlying buffer).
It could be interesting if there were an "AutoClone" trait that acted similarly to Copy where the compiler knew to inject .clone when it needed to do so to make ownership work. That's probably unlikely because then you could have something implement AutoClone that then contains a huge Vector or huge String and take forever to clone; this would make it difficult to use Rust in a systems programming context (e.g. OS kernel) which is the primary focus for Rust.
BTW, in general Rust doesn't have memory leaks. If you want to not worry about lifetimes or the borrow checker, you would just wrap everything in Arc<Mutex<T>> (when you need the reference accessed by multiple threads) / Rc<RefCell<T>> (single thread). You could have your own type that does so and offers convenient Deref / DerefMut access so you don't have to borrow/lock every time at the expense of being slower than well-written Rust) and still have Python-like thread-safety issues (the object will be internally consistent but if you did something like r.x = 5; r.y = 6 you could observe x=5/y=old value or x=5/y=6). But you will have to clone explicitly the reference every time you need a unique ownership.
No, I fully understand the difference. I am just saying since I don't have a GC, I would rather have the system do copies instead of dealing with references.
At least as long as I can afford it performance wise. Then borrowing it is. But I would prefer the default semantics to be copying.
At least as long as I can afford it performance wise. Then borrowing it is. But I would prefer the default semantics to be copying.
> At least as long as I can afford it performance wise. Then borrowing it is. But I would prefer the default semantics to be copying.
How could/would the language know when you can and can't afford it? Default semantics can't be "copying" because in Rust copying means something very explicit that in C++ would map to `is_trivially_copyable`. The default can't be that because Rust isn't trying to position as an alternative for scripting languages (even though in practice it does appear to be happening) - it's remarkable that people accept C++'s "clone everything by default" approach but I suspect that's more around legacy & people learning to kind of make it work. BTW in C++ you have references everywhere, it just doesn't force you to be explicit (i.e. void foo(const Foo&) and void foo(Foo) and void foo(Foo&) all accepts an instance of Foo at the call site even though very different things happen).
But basically you're argument boils down to "I'd like Rust without the parts that make it Rust" and I'm not sure how to square that circle.
How could/would the language know when you can and can't afford it? Default semantics can't be "copying" because in Rust copying means something very explicit that in C++ would map to `is_trivially_copyable`. The default can't be that because Rust isn't trying to position as an alternative for scripting languages (even though in practice it does appear to be happening) - it's remarkable that people accept C++'s "clone everything by default" approach but I suspect that's more around legacy & people learning to kind of make it work. BTW in C++ you have references everywhere, it just doesn't force you to be explicit (i.e. void foo(const Foo&) and void foo(Foo) and void foo(Foo&) all accepts an instance of Foo at the call site even though very different things happen).
But basically you're argument boils down to "I'd like Rust without the parts that make it Rust" and I'm not sure how to square that circle.
Borrowing isn't for mutability, but for memory management and limiting data access to a static scope. It just happens that there's an easy syntax for borrowing as shared or exclusive at the same time.
Owned objects are exclusively owned by default, but wrapping them in Rc/Arc makes them shared too.
Shared mutable state is the root of all evil. FP languages solve it by banning mutation, but Rust can flip between banning mutation or banning sharing. Mutable objects that aren't shared can't cause unexpected side effects (at least not any more than Rust's shared references).
Owned objects are exclusively owned by default, but wrapping them in Rc/Arc makes them shared too.
Shared mutable state is the root of all evil. FP languages solve it by banning mutation, but Rust can flip between banning mutation or banning sharing. Mutable objects that aren't shared can't cause unexpected side effects (at least not any more than Rust's shared references).
> While in an FP language you are passing values
By passing values do you mean 'moving'? Like not passing reference?
By passing values do you mean 'moving'? Like not passing reference?
Yes, I guess in Rust terms, that is called moving. However, when I have some code that "moves" the value into another procedure, then the code after that call, can no longer use the moved value.
So I want to move a value, but also be able to use it after moving it, because I don't mutate it in that other function, where it got moved to. So it is actually more like copying, but without making a copy in memory.
It would be good, if Rust realized, that I don't have mutating calls anywhere and just lets me use the value. When I have a mutation going on, then of course the compiler should throw error, because that would be unsafe business.
So I want to move a value, but also be able to use it after moving it, because I don't mutate it in that other function, where it got moved to. So it is actually more like copying, but without making a copy in memory.
It would be good, if Rust realized, that I don't have mutating calls anywhere and just lets me use the value. When I have a mutation going on, then of course the compiler should throw error, because that would be unsafe business.
I'm not sure how what you're describing is different from passing an immutable/shared reference.
If you call `foo(&value)` then `value` remains available in your calling scope after `foo` returns. If you don't mutate `value` in foo, and foo doesn't do anything other than derive a new value from `value`, then it sounds like a shared reference works for what you're describing?
Rust makes you be explicit as to whether you want to lend out the value or give the value away, which is a design decision, and Rust chooses that the bare syntax `value` is for moving and the `&value` syntax is for borrowing. Perhaps you're arguing that a shared immutable borrow should be the default syntax.
Apologies if I'm misunderstanding!
If you call `foo(&value)` then `value` remains available in your calling scope after `foo` returns. If you don't mutate `value` in foo, and foo doesn't do anything other than derive a new value from `value`, then it sounds like a shared reference works for what you're describing?
Rust makes you be explicit as to whether you want to lend out the value or give the value away, which is a design decision, and Rust chooses that the bare syntax `value` is for moving and the `&value` syntax is for borrowing. Perhaps you're arguing that a shared immutable borrow should be the default syntax.
Apologies if I'm misunderstanding!
Couldn't you just pass a reference to your value (i.e. `&T`)? If you absolutely _need_ ownership the function you call could return back the owned value or you could use one of the mechanisms for shared ownership like `Rc<T>`. In a GC'd functional language, you're effectively getting the latter (although usually a different form of GC instead of reference counting)
I think I could. But then I would need to put & in front of every argument in every procedure definition and also deal with working with references inside the procedure, with the syntax that brings along.
Fair to be annoyed by this, but not very interesting: This is just a minor syntactical pattern that exists for a very good reason.
Syntax is generally the least interesting/important part of languages.
Syntax is generally the least interesting/important part of languages.
When you pass &variable, I don't think it affects the syntax inside the called function, does it?
Correct. If you then want to subsequently re-reference or dereference that reference (this happens sometimes), you'll need to accordingly `&` or `*` it, but if you're just using it as is, the bare syntactical `name` (whatever it happens to be) already refers to a reference.
Also, Rust does implicit dereferencing, so it's not that much of an issue in practice.
Ownership serves another important purpose: it determines when a value is freed.
I guess it is then a necessary complication of the language, as it doesn't have garbage collection, and as such doesn't notice, when values go out of scope of all closures that reference them?
Yes, but it’s more subtle than that. What Rust does is track when the object goes out of scope, and will make sure that any closures that reference it live for a shorter time than that. Sort of backwards of what you’re asking.
The borrow checker is a compile-time garbage collector. If you think about it in that sense, you can understand a lot of the ways it restricts you.
Depends on the FP language though, they are only values in the logic sense, they can be reference as well, hence the various ways to do equality.
Readers would benefit from distinguishing effects systems from type systems - error handling, async code, ownership, pointers escaping, etc. are all better understood as effects because they pertain to usage of a value/type (though the usage constraints can depend on the type properties).
Similarly, Java sidesteps many of these issues in mostly using reference types, but ends up with a different classes of errors. So the C/pointer family static analysis can be quite distinct from that for JVM languages.
Swift is roughly on par with Rust wrt exclusivity and data-race safety, and is catching up on ownership.
Rust traits and macros are really a distinguishing feature, because they enable programmer-defined constraints (instead of just compiler-defined), which makes the standard library smaller.
Similarly, Java sidesteps many of these issues in mostly using reference types, but ends up with a different classes of errors. So the C/pointer family static analysis can be quite distinct from that for JVM languages.
Swift is roughly on par with Rust wrt exclusivity and data-race safety, and is catching up on ownership.
Rust traits and macros are really a distinguishing feature, because they enable programmer-defined constraints (instead of just compiler-defined), which makes the standard library smaller.
Swift has such a long way to go in general ergonomics of its type system, it's so far behind compared to Rust. The fact that the type checker will just churn until it times out and asks the user to refactor so that it can make progress is such a joke to me, I don't understand how they shipped that with a straight face.
There's nothing wrong with this in principle, every type system must reject some valid programs. There's no such thing as a "100%" type system that will both accept all valid code and reject all non-valid code.
I'm not questioning the principle, I'm critiquing the implementation versus the competition. Swift doesn't do a good job, it throws up its hands too often.
If you solve 80% of the problems by spending 20% of the time, is it worth spending the 80% to solve 20% of the problems? Or even if it is, is it more valuable to ship the 80% complete solution first to get it into the hands of users while you work on the thornier version?
If someone else ships a 100% solution, or a solution that doesn't have the problems your potentially half-baked "80% solution" does, then you might be in trouble.
There's a fine line here: it matters a lot whether we're talking about a "sloppy" 80% solution that later causes problems and is incredibly hard to fix, or if it's a clean minimal subset, which restricts you (by being the minimal thing everyone agrees on) but doesn't have any serious design flaws.
There's a fine line here: it matters a lot whether we're talking about a "sloppy" 80% solution that later causes problems and is incredibly hard to fix, or if it's a clean minimal subset, which restricts you (by being the minimal thing everyone agrees on) but doesn't have any serious design flaws.
Sure. And I'm not sure the type checker failing on certain corner cases and asking you to alter the code to be friendlier is a huge roadblock if it rarely comes up in practice for the vast majority of developers.
Swift even if catching up a bit is probably not going to impose strict border between safe and unsafe.
I think tagged unions with exhaustive type checking and no nulls are the two killer features for correctness
Apologies for the non sequitur
Do you think Zig is a valid challenger to Rust for this kind of programming?
Do you think Zig is a valid challenger to Rust for this kind of programming?
Zig's trying to be a "nicer C" that's easy to learn and fast to compile. It's a great language with a lot of neat design, and definitely setting itself up to be a "valid challenger" in a lot of the systems-y, performance-focused domains Rust targets. But it's not trying to compete with Rust on the safety/program correctness front.
Almost none of the Rust features discussed in this subthread are present in Zig, such as ownership, borrowing, shared vs. exclusive access, lifetimes, traits, RAII, or statically checked thread safety.
Almost none of the Rust features discussed in this subthread are present in Zig, such as ownership, borrowing, shared vs. exclusive access, lifetimes, traits, RAII, or statically checked thread safety.
Thank you
I might suspect that if you are lumping all statically-typed languages into a single bucket without making particular distinction among them, then you might not have fully internalized the implications of union (aka Rust enum aka sum) typed data structures combined with exhaustive pattern matching.
I like to call it getting "union-pilled" and it's really hard to accept otherwise statically-typed languages once you become familiar.
I like to call it getting "union-pilled" and it's really hard to accept otherwise statically-typed languages once you become familiar.
Or the fact that Rust's type system includes things like Send and Sync, which aren't tracked and enforced in many otherwise-statically-typed languages.
C is statically typed, but its type system tracks much less.
C is statically typed, but its type system tracks much less.
My interpretation is, that C doesn't have data types, but memory layout types.
Arguably hardly even that, as memory layout for many in-built types are target and/or compiler-specific.
enums + match expressions + tagged unions are the secret sauce of Rust.
Like this code snippet?
(* Expressions *)
type Exp =
UnMinus of Exp
| Plus of Exp * Exp
| Minus of Exp * Exp
| Times of Exp * Exp
| Divides of Exp * Exp
| Power of Exp * Exp
| Real of float
| Var of string
| FunCall of string * Exp
| Fix of string * Exp
;;
let rec tokenizer s =
let (ch, chs) = split s in
match ch with
' ' -> tokenizer chs
| '(' -> LParTk:: (tokenizer chs)
| ')' -> RParTk:: (tokenizer chs)
| '+' -> PlusTk::(tokenizer chs)
| '-' -> MinusTk::(tokenizer chs)
| '*' -> TimesTk::(tokenizer chs)
| '^' -> PowerTk::(tokenizer chs)
| '/' -> DividesTk::(tokenizer chs)
| '=' -> AssignTk::(tokenizer chs)
| ch when (ch >= 'A' && ch <= 'Z') ||
(ch >= 'a' && ch <= 'z') ->
let (id_str, chs) = get_id_str s
in (Keyword_or_Id id_str)::(tokenizer chs)
| ch when (ch >= '0' && ch <= '9') ->
let (fl_str, chs) = get_float_str s
in (RealTk (float (fl_str)))::(tokenizer chs)
| '$' -> if chs = "" then [] else raise (SyntaxError (""))
| _ -> raise (SyntaxError (SyntErr ()))
;;
Yes, the secret of Rust is that it offers both a) some important but slightly subtle language features from the late '70s that were sadly not present in Algol '52 and are therefore missing from popular lineages b) a couple of party tricks, in particular the ability to outperform C on silly microbenchmarks; b) is what leads people to adopt it and a) is what makes it non-awful to program in. Yes it's a damning indictment of programming culture than people did not adopt pre-Rust ML-family languages, but it could be worse, they could be not adopting Rust either.
>important but slightly subtle language features from the late '70s
Programming-language researchers didn't start investigating linear (or affine) types till 1989. Without the constraint that vectors, boxes, strings, etc, are linear, Rust cannot deliver its memory-safety guarantees (unless Rust were radically changed to rely on a garbage collecting runtime).
>it's a damning indictment of programming culture than people did not adopt pre-Rust ML-family languages
In pre-Rust ML-family languages, it is harder to reason about CPU usage, memory usage and memory locality than it is in languages like C and Rust. One reason for that is the need in pre-Rust ML-family langs for a garbage collector.
In summary, there are good reasons ML, Haskell, etc, never got as popular as Rust.
Programming-language researchers didn't start investigating linear (or affine) types till 1989. Without the constraint that vectors, boxes, strings, etc, are linear, Rust cannot deliver its memory-safety guarantees (unless Rust were radically changed to rely on a garbage collecting runtime).
>it's a damning indictment of programming culture than people did not adopt pre-Rust ML-family languages
In pre-Rust ML-family languages, it is harder to reason about CPU usage, memory usage and memory locality than it is in languages like C and Rust. One reason for that is the need in pre-Rust ML-family langs for a garbage collector.
In summary, there are good reasons ML, Haskell, etc, never got as popular as Rust.
> Programming-language researchers didn't start investigating linear (or affine) types till 1989.
Sure, but as ModernMech said, the vast majority of Rust's benefits come from having sum types and pattern matching.
> In pre-Rust ML-family languages, it is harder to reason about CPU usage, memory usage and memory locality than it is in languages like C and Rust.
Marginally harder for the first two and significantly harder for the last, sure. None of which is enough to matter in the overwhelming majority of cases where Rust is seeing use.
Sure, but as ModernMech said, the vast majority of Rust's benefits come from having sum types and pattern matching.
> In pre-Rust ML-family languages, it is harder to reason about CPU usage, memory usage and memory locality than it is in languages like C and Rust.
Marginally harder for the first two and significantly harder for the last, sure. None of which is enough to matter in the overwhelming majority of cases where Rust is seeing use.
> Sure, but as ModernMech said, the vast majority of Rust's benefits come from having sum types and pattern matching.
Doubt. There were lots of languages giving you just that, and they never had this amount of hype. See Scala, OCaml, Haskell, etc.
Rust has one unique ability, and many shared by other languages. It's quite clearly popular for the former (though languages are a packages, so of course it's a well put together language all around).
Doubt. There were lots of languages giving you just that, and they never had this amount of hype. See Scala, OCaml, Haskell, etc.
Rust has one unique ability, and many shared by other languages. It's quite clearly popular for the former (though languages are a packages, so of course it's a well put together language all around).
Scala, OCaml, and Haskell all approach programming from a functional-first perspective. What no other language did before Rust was to bring those features to such a well-designed imperative core.
And while this was necessary to Rust's success, I don't think it was sufficient, insofar as it also needed a good deal of corporate backing, a great and welcoming community, and luck to be at the right place at the right time.
Haskell never tried to be more than a academic language targeting researchers. OCaml never had a big community or corporate backing. Scala never really had a niche; the most salient reason to use it is if you're already in the Java ecosystem and you want to write functional code. The value propositions for each are very different, so these language didn't receive the same reaction as Rust despite offering similar features.
And while this was necessary to Rust's success, I don't think it was sufficient, insofar as it also needed a good deal of corporate backing, a great and welcoming community, and luck to be at the right place at the right time.
Haskell never tried to be more than a academic language targeting researchers. OCaml never had a big community or corporate backing. Scala never really had a niche; the most salient reason to use it is if you're already in the Java ecosystem and you want to write functional code. The value propositions for each are very different, so these language didn't receive the same reaction as Rust despite offering similar features.
Scala is distinctively a mixed FP and OOP language. There are functional proponents doing full monads and whatnot, but there is just as much follower of a more balanced approach (see Li Haoyi's libs). Though Scala definitely had/have quite a niche around it.
Well I think Scala's main problem here is it can still have runtime errors with null values, so it doesn't really have the same runtime safety guarantees pattern matching brings Rust / Haskell / OCaml. For example, this will cause a runtime panic in Scala:
https://scastie.scala-lang.org/fnquHxAcThGn7Z8zistthw
This wouldn't compile in Rust. Scala is an okay language, its main benefit as far as I can tell is its a way to write JVM code without having to write Java.
https://scastie.scala-lang.org/fnquHxAcThGn7Z8zistthw
This wouldn't compile in Rust. Scala is an okay language, its main benefit as far as I can tell is its a way to write JVM code without having to write Java.
Scala 3 has a compiler flag that makes `null` its separate type, making it completely null-safe.
This would e.g. make
``` val a: String | Null = someLegacyJavaCodeReturningNullableString()
```
and explicit null check would only make the non-nullable string continue onward.
This would e.g. make
``` val a: String | Null = someLegacyJavaCodeReturningNullableString()
```
and explicit null check would only make the non-nullable string continue onward.
That's a theoretical problem, not a practical one. Scala programmers and Scala libraries don't use null and usually have a linter that will reject code like that. (You can hit null in Scala because you didn't check an FFI call properly, but that happens in Rust too)
> There were lots of languages giving you just that, and they never had this amount of hype. See Scala, OCaml, Haskell, etc.
They weren't hyped because they didn't have a silly party trick like microbenchmark performance. But they give you all the practical benefits of Rust and more.
They weren't hyped because they didn't have a silly party trick like microbenchmark performance. But they give you all the practical benefits of Rust and more.
> Yes it's a damning indictment of programming culture than people did not adopt pre-Rust ML-family languages, but it could be worse, they could be not adopting Rust either.
I'll say for a long time I've been quite pleased on the general direction of the industry in terms of language design and industry trends around things like memory safety. For a good many years we've seen functional features being integrated into popular imperative languages, probably since map/reduce became a thing thanks to Google. So I'll us all credit for coming around eventually.
I'm more dismayed by the recent AI trend of asking an AI to write Python code and then just going with whatever it outputs. I can't say that seems like a step forward.
I'll say for a long time I've been quite pleased on the general direction of the industry in terms of language design and industry trends around things like memory safety. For a good many years we've seen functional features being integrated into popular imperative languages, probably since map/reduce became a thing thanks to Google. So I'll us all credit for coming around eventually.
I'm more dismayed by the recent AI trend of asking an AI to write Python code and then just going with whatever it outputs. I can't say that seems like a step forward.
C only got to its performance state, when optimizing compilers taking advantage of UB started being common thing, during the 8 and 16 bit home computer days they were hardly any better than writing Assembly by hand, hence why books like Zen of Assembly Language left such a mark.
So if we are speaking of optimizing compilers there is MLton, while ensuring that the application doesn't blow up in strange ways.
The problem is not people getting to learn these features from Rust, glad that they do, the issue is that they think Rust invented them.
So if we are speaking of optimizing compilers there is MLton, while ensuring that the application doesn't blow up in strange ways.
The problem is not people getting to learn these features from Rust, glad that they do, the issue is that they think Rust invented them.
> the issue is that they think Rust invented them
Sorry, my post wasn't to imply Rust invented those things. My point was Rust's success as a language is due to those features.
Of course there's more to it, but what Rust really does right is blend functional and imperative styles. The "match" statement is a great way to bring functional concepts to imperative programmers, because it "feels" like a familiar switch statement, but with super powers. So it's a good "gateway drug" if you will, because the benefit is quickly realized ("Oh, it caught that edge case for me before it became a problem at runtime, that would have been a headache...").
From there, you can learn how to use match as an expression, and then you start to wonder why "if" isn't an expression in every language. After that you're hooked.
Sorry, my post wasn't to imply Rust invented those things. My point was Rust's success as a language is due to those features.
Of course there's more to it, but what Rust really does right is blend functional and imperative styles. The "match" statement is a great way to bring functional concepts to imperative programmers, because it "feels" like a familiar switch statement, but with super powers. So it's a good "gateway drug" if you will, because the benefit is quickly realized ("Oh, it caught that edge case for me before it became a problem at runtime, that would have been a headache...").
From there, you can learn how to use match as an expression, and then you start to wonder why "if" isn't an expression in every language. After that you're hooked.
I mean, "fearless concurrency", while a hyped-up phrase that is definitely exaggerated, compared to the C-world where you are already blowing off your leg in single-threaded code, let alone thinking of multiple threads Rust is an insanely huge win. And it shows on e.g. the small Unix tool rewrites.
Sure, rewrites are most often better on simply being a rewrite, but the kind of parallel processing they do may not be feasible in C.
Sure, rewrites are most often better on simply being a rewrite, but the kind of parallel processing they do may not be feasible in C.
Maybe I need to read it again, but I remember the Rust book saying… you can use enums like C, but what if instead you used them in this more concise way? (Match on members, without the container.) Ok, was able to proceed but don’t feel like I understand what they really are.
Afaik they aren't true unions but sum types, which have different implications.
And fwiw I've used unions in typescript extensively and I'm not convinced that they're a good idea. They give you a certain flexibility to writing code, yes, does that flexibility lead to good design choices, idk.
And fwiw I've used unions in typescript extensively and I'm not convinced that they're a good idea. They give you a certain flexibility to writing code, yes, does that flexibility lead to good design choices, idk.
TypeScript unions are very different from Rust enums, and they lead to different design decisions. IMO Rust-style tagged unions are essential in any new language coming out today, it's really a pity that people didn't pick up on this in the 70s.
What differences do they lead to? I just find union types more flexible, with the perceived downside of losing some semantics on success/error results (but I don't think it's a problem personally). But I wouldn't say I'm super knowledgeable about Rust outside of writing some toy programs.
You could create your own Result<T, Error> type in TS but people don't really do that outside of ecosystems like Effect because there isn't usually a reason to.
You could create your own Result<T, Error> type in TS but people don't really do that outside of ecosystems like Effect because there isn't usually a reason to.
The core difference between sums and unions is that sum types have cardinality |A+B| = |A| + |B|, whereas union types have cardinality |A∪B| = |A| + |B| - |A∩B|. As you noted, type systems with union types, such as Typescript, also support sum types because you can create disjoint wrapper types (like Ok and Err) and their union type will be semantically equivalent to a sum type, since the intersection is an empty set. In this sense, union types are strictly more powerful than sum types.
The downside is that union types require some notion of subtyping, since otherwise A∩B is always empty for distinct A and B. Unfortunately, subtyping is apparently very difficult to implement in HM-like type systems (like Rust and ML) such that it plays well with type inference.[0] Hence, the downside of having union types in a language is that users have to write out types more often.
Unlike kibwen, I don't think Rust's type system is particularly essential for new languages. It's a design choice where one side has more powerful types but the other side has more powerful type inference.
[0] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
The downside is that union types require some notion of subtyping, since otherwise A∩B is always empty for distinct A and B. Unfortunately, subtyping is apparently very difficult to implement in HM-like type systems (like Rust and ML) such that it plays well with type inference.[0] Hence, the downside of having union types in a language is that users have to write out types more often.
Unlike kibwen, I don't think Rust's type system is particularly essential for new languages. It's a design choice where one side has more powerful types but the other side has more powerful type inference.
[0] https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
I'm way late to think of this and circle back here, but if you don't mind briefly switching languages to F#, I first grasped these concepts via "Designing with types: Making illegal states unrepresentable"
https://fsharpforfunandprofit.com/posts/designing-with-types...
... and I would suggest actively playing around with the code examples, extending them, breaking them intentionally etc. somewhere like https://dotnetfiddle.net/
I think the article is brilliant but as I recall I wasn't able to grasp the concepts from reading alone.
That same website has a separate article on building a calculator (in code) that I recall was also excellent.
https://fsharpforfunandprofit.com/posts/designing-with-types...
... and I would suggest actively playing around with the code examples, extending them, breaking them intentionally etc. somewhere like https://dotnetfiddle.net/
I think the article is brilliant but as I recall I wasn't able to grasp the concepts from reading alone.
That same website has a separate article on building a calculator (in code) that I recall was also excellent.
One other major factor I'd throw on the heap: traits / implementation traits. They act as both an interface system and as a sort of Extension Method system (as seen in c#).
But where-as with interfaces, typically they require you early define what your class implements. Rust gives you a late-bound-ish (still compile time but not defined in the original type) / Inversion of Control way to take whatever you've got and define new things for it. In most languages what types a thing has are defined by the library, but Rust not just allows but is built entirely around taking very simple abstract thing and constructing bigger and bigger toolkits of stuff around them. Very Non-zero sum in ways that languages rarely are.
There's a ton of similarity to Extension Methods, where more can get added to the type. But traits / impls are built much more deeply into rust, are how everything works. Extension Methods are also, afaik, just methods, where-as with Rust you really adding new types that an existing defined-elsewhere thing can express.
I find it super shocking (and not because duh) that Rust's borrow checking gets all the focus. Because the type system is such a refreshing open ended late-defined reversal of type system dogma, of defining everything ahead of time. It seems like such a superpower of Rust that you can keep adding typiness to a thing, keep expanding what a thing can do. The inversion here is, imo, one of the real largely unseen sources of glory for why Rust keeps succeeding: you don't need to fully consider the entire type system of your program ahead of time, you can layer in typing onto existing types as you please, as fits, as makes sense, and that is a far more dynamic static type system than the same old highly constrained static type dreck we've suffered for decades. Massive break forward: static, but still rather dynamic (at compile time).
But where-as with interfaces, typically they require you early define what your class implements. Rust gives you a late-bound-ish (still compile time but not defined in the original type) / Inversion of Control way to take whatever you've got and define new things for it. In most languages what types a thing has are defined by the library, but Rust not just allows but is built entirely around taking very simple abstract thing and constructing bigger and bigger toolkits of stuff around them. Very Non-zero sum in ways that languages rarely are.
There's a ton of similarity to Extension Methods, where more can get added to the type. But traits / impls are built much more deeply into rust, are how everything works. Extension Methods are also, afaik, just methods, where-as with Rust you really adding new types that an existing defined-elsewhere thing can express.
I find it super shocking (and not because duh) that Rust's borrow checking gets all the focus. Because the type system is such a refreshing open ended late-defined reversal of type system dogma, of defining everything ahead of time. It seems like such a superpower of Rust that you can keep adding typiness to a thing, keep expanding what a thing can do. The inversion here is, imo, one of the real largely unseen sources of glory for why Rust keeps succeeding: you don't need to fully consider the entire type system of your program ahead of time, you can layer in typing onto existing types as you please, as fits, as makes sense, and that is a far more dynamic static type system than the same old highly constrained static type dreck we've suffered for decades. Massive break forward: static, but still rather dynamic (at compile time).
An approach that is done in Standard ML with functors.
Any good articles or blog posts that go deeper on this? Sounds very interesting
I mean, is that not just [1] type classes? They are not a new concept, they could be grandparents!
[1] not trying to take away anything from the designers, getting it right in combination with all the other features is a huge feat!
[1] not trying to take away anything from the designers, getting it right in combination with all the other features is a huge feat!
> statically typed and thus compiled
Statically typed does not imply compiled. You can interpret a statically typed language, for instance. And not every compiled language is all that static.
For example, C is statically typed, but also has the ability to play pointer typecasting trickery. So how much can the compiler ever guarantee anything, really? It can't, and we've seen the result is brittle artifacts from C.
Rust is statically-typed and it has all kinds of restrictions on what you can do with those types. You can't just pointer cast one thing to another in Rust, that's going to be rejected by the compiler outright. So Rust code has to meet a higher bar of "static" than most languages that call themselves "static".
Type casting is just one way Rust does this, other ways have been mentioned. They all add up and the result is Rust artifacts are safter and more secure.
Statically typed does not imply compiled. You can interpret a statically typed language, for instance. And not every compiled language is all that static.
For example, C is statically typed, but also has the ability to play pointer typecasting trickery. So how much can the compiler ever guarantee anything, really? It can't, and we've seen the result is brittle artifacts from C.
Rust is statically-typed and it has all kinds of restrictions on what you can do with those types. You can't just pointer cast one thing to another in Rust, that's going to be rejected by the compiler outright. So Rust code has to meet a higher bar of "static" than most languages that call themselves "static".
Type casting is just one way Rust does this, other ways have been mentioned. They all add up and the result is Rust artifacts are safter and more secure.
> You can't just pointer cast one thing to another in Rust, that's going to be rejected by the compiler
You can't safely do this yourself. That is, you couldn't write safe Rust which performs this operation for two arbitrary things. But Rust of course does do this, actually quite a lot, because if we're careful it's entirely safe.
That famous Quake 3 Arena "Fast inverse square root" which involves type puns? You can just write that in safe Rust and it'll work fine. You shouldn't - on any even vaguely modern hardware the CPU can do this operation faster anyway - but if you insist it's trivial to write it, just slower.
Why can you do that? Well, on all the hardware you'd realistically run Rust on the 32-bit integer types and the 32-bit floating types are the exact same size (duh), same bit order and so on. The CPU does not actually give a shit whether this 32-bit aligned and 32-bit sized value "is" an integer or a floating point number, so "transforming" f32 to u32 or u32 to f32 emits zero CPU instructions, exactly like the rather hairier looking C. So all the Rust standard library has to do is promise that this is OK which on every supported Rust platform it is. If some day they adopted some wheezing 1980s CPU where that can't work they'd have to write custom code for that platform, but so would John Carmack under the same conditions.
You can't safely do this yourself. That is, you couldn't write safe Rust which performs this operation for two arbitrary things. But Rust of course does do this, actually quite a lot, because if we're careful it's entirely safe.
That famous Quake 3 Arena "Fast inverse square root" which involves type puns? You can just write that in safe Rust and it'll work fine. You shouldn't - on any even vaguely modern hardware the CPU can do this operation faster anyway - but if you insist it's trivial to write it, just slower.
Why can you do that? Well, on all the hardware you'd realistically run Rust on the 32-bit integer types and the 32-bit floating types are the exact same size (duh), same bit order and so on. The CPU does not actually give a shit whether this 32-bit aligned and 32-bit sized value "is" an integer or a floating point number, so "transforming" f32 to u32 or u32 to f32 emits zero CPU instructions, exactly like the rather hairier looking C. So all the Rust standard library has to do is promise that this is OK which on every supported Rust platform it is. If some day they adopted some wheezing 1980s CPU where that can't work they'd have to write custom code for that platform, but so would John Carmack under the same conditions.
> because if we're careful it's entirely safe.
The thesis of Rust is that in aggregate, everyone can't be careful, therefore allowing anyone to do it (by default) is entirely unsafe.
Of course you can do unsafe things in Rust, but relegating that work to the room at the back of the video store labeled "adults only" has the effect of raising code quality for everyone. It turns out if you put up some hoops to jump through before you can access the footguns, people who shouldn't be wielding them don't, and average code quality goes up.
The thesis of Rust is that in aggregate, everyone can't be careful, therefore allowing anyone to do it (by default) is entirely unsafe.
Of course you can do unsafe things in Rust, but relegating that work to the room at the back of the video store labeled "adults only" has the effect of raising code quality for everyone. It turns out if you put up some hoops to jump through before you can access the footguns, people who shouldn't be wielding them don't, and average code quality goes up.
> So how much can the compiler ever guarantee anything, really?
Well, the compiler is guaranteed that no mistakes will happen. It's the programmer who looses his guarantees in this case.
Well, the compiler is guaranteed that no mistakes will happen. It's the programmer who looses his guarantees in this case.
> Don't most of the benefits just come down to using a statically typed and thus compiled language?
Doesn't have to be compiled to be statically typed... but yeah, probably.
> Be it Java, Go or C++;
Lol! No. All static type systems aren't the same.
TypeScript would be the only one of your examples that brings the same benefit. But the entire system is broken due to infinite JS Wats it has to be compatible with.
> it's harder to learn and arguably to read
It's easier to learn it properly, harder to vibe pushing something into it until it seems to works. Granted, vibe pushing code into seemingly working is a huge part of initial learning to code, so yeah, don't pick Rust as your first language.
It's absolutely not harder to read.
Doesn't have to be compiled to be statically typed... but yeah, probably.
> Be it Java, Go or C++;
Lol! No. All static type systems aren't the same.
TypeScript would be the only one of your examples that brings the same benefit. But the entire system is broken due to infinite JS Wats it has to be compatible with.
> it's harder to learn and arguably to read
It's easier to learn it properly, harder to vibe pushing something into it until it seems to works. Granted, vibe pushing code into seemingly working is a huge part of initial learning to code, so yeah, don't pick Rust as your first language.
It's absolutely not harder to read.
No. Other languages don't prevent concurrency related bugs like the one in the article. Rust has reference aliasing rules and lifetimes and send and sync traits. These things do not exist in Java and others, so will not prevent such bugs
> Don't most of the benefits just come down to using a statically typed and thus compiled language? Be it Java, Go or C++; TypeScript is trickier, because it compiles to JavaScript and inherits some issues, but it's still fine.
Yes. The type systems of these modern compiled languages are more sound than anything that Javascript and Typescript can ever provide.
Anyone using such languages that have a totally weak type system and a dynamic typing system as well is going to run into hundreds of headaches - hence why they love properly typed-systems such as Rust which actually is a well designed language.
Yes. The type systems of these modern compiled languages are more sound than anything that Javascript and Typescript can ever provide.
Anyone using such languages that have a totally weak type system and a dynamic typing system as well is going to run into hundreds of headaches - hence why they love properly typed-systems such as Rust which actually is a well designed language.
Not all static type systems are equally expressive/safe/consistent - Java falls back to `Object` and runtime casts frequently, Go doesn't have enums, and C++ variants come with significant footguns and ergonomics issues since they were hacked on and aren't first class language features (i.e. safe access requires using `try/except` which is exclusive with other control structures).
> Java falls back to `Object` and runtime casts frequently
Is it frequently? Generics are definitely not as nice as they could be, but they are surprisingly "sufficient" for almost any library, e.g. a full on type-safe SQL DSL like JOOQ. Unsafe casts are very rare, and where you do need Object and stuff are very dynamic stuff where it's impossible to extend compile-time guarantees even theoretically (e.g. runtime code generation, dynamic code loading, etc - people often forget about these use cases, not everything can work in a closed universe)
Is it frequently? Generics are definitely not as nice as they could be, but they are surprisingly "sufficient" for almost any library, e.g. a full on type-safe SQL DSL like JOOQ. Unsafe casts are very rare, and where you do need Object and stuff are very dynamic stuff where it's impossible to extend compile-time guarantees even theoretically (e.g. runtime code generation, dynamic code loading, etc - people often forget about these use cases, not everything can work in a closed universe)
jOOQ's internals are full of unsafe casts, though.
Well, you have basically implemented a Java type-system level type checker for SQL. I don't believe there is any type system strong enough to express the whole thing without the escape hatches (casts), besides Lean, Coq and alia.
Not sure what you mean. I meant that without declaration site variance, ("pragmatic") unsafe casting is everywhere in jOOQ's internals. Without being able to capture wildcards in local type variables, ("pragmatic") rawtypes are everywhere as well (check Collections.swap() for an illustration)
Yes, all four of them will have some checks that won't be present in a dynamic language, but the differences between them are large enough to be significant. Riding a bike and driving a car are both much faster than going on foot, but if you only view this as a "benefit that comes down to using wheels", you're missing some pretty meaningful details.
Yes. What Rust adds is a better type system. Statically typed is as good as your Type system (which is why TypeScript still sucks).
The concurrency/safety/memory story is only valid in a few rare cases and I wish people didn't try to sell Rust for these features.
The concurrency/safety/memory story is only valid in a few rare cases and I wish people didn't try to sell Rust for these features.
Neither Go, Java or C++ would catch that concurrency bug.
C# would catch the bug at compile time, just like Rust.
https://www.rocksolidknowledge.com/articles/locking-asyncawa...
https://www.rocksolidknowledge.com/articles/locking-asyncawa...
I don't know C# but it looks like they added a specific check just for locks, which is far less powerful than Rust's Send/Sync.
It's almost as if this post was written in direct response to TFA to brag about how far ahead C# has been for over a decade.
The C# is basically showing the Monitor pattern, which was also a thing in Java last century.
The Rust Mutex is an Owning Mutex which is a different feature whose benefit is that you need to take the lock to get at the protected data, which averts situations where you forget in some code but not others and create sync problems - in C# those may go undetected or may trigger a runtime exception, no guarantees.
But perhaps even more importantly, and why other languages which could do the Owning Mutex often do not, Rust's borrow checking means the compiler will spot mistakes where you gave back the lock but retained access to the data it was protecting. So you're protected both ways - you can't forget to take the lock, and you also can't give it back without also giving back the access.
Monitors prevent only the second (and only partly), an Owning Mutex in most languages prevents the first, but Rust prevents both.
The Rust Mutex is an Owning Mutex which is a different feature whose benefit is that you need to take the lock to get at the protected data, which averts situations where you forget in some code but not others and create sync problems - in C# those may go undetected or may trigger a runtime exception, no guarantees.
But perhaps even more importantly, and why other languages which could do the Owning Mutex often do not, Rust's borrow checking means the compiler will spot mistakes where you gave back the lock but retained access to the data it was protecting. So you're protected both ways - you can't forget to take the lock, and you also can't give it back without also giving back the access.
Monitors prevent only the second (and only partly), an Owning Mutex in most languages prevents the first, but Rust prevents both.
> Neither Go, Java or C++ would catch that concurrency bug.
That is incorrect. Java enforces that a monitor lock (or Lock) must be released by the same thread that acquired it. Attempting to unlock from a different thread throws IllegalMonitorStateException.
That is incorrect. Java enforces that a monitor lock (or Lock) must be released by the same thread that acquired it. Attempting to unlock from a different thread throws IllegalMonitorStateException.
At runtime instead of compile time, which is the point of the thread.
> Don't most of the benefits just come down to using a statically typed and thus compiled language? Be it Java, Go or C++; TypeScript is trickier, because it compiles to JavaScript and inherits some issues, but it's still fine.
No. You have to have a certain amount of basic functionality in your type system; in particular, sum types, which surprisingly many languages still lack.
(Note that static typing does not require compilation or vice versa)
> I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read
ML-family languages are generally easier to learn and read if you start from them. It's just familiarity.
No. You have to have a certain amount of basic functionality in your type system; in particular, sum types, which surprisingly many languages still lack.
(Note that static typing does not require compilation or vice versa)
> I know that Rust provides some additional compile-time checks because of its stricter type system, but it doesn't come for free - it's harder to learn and arguably to read
ML-family languages are generally easier to learn and read if you start from them. It's just familiarity.
Rust is way more productive than any of the listed languages.
Extraordinary claims require.. at least some kind of evidence.
There is very little research comparing PL productivity, because it is very hard to do them properly.
There is very little research comparing PL productivity, because it is very hard to do them properly.
Try it.
IMO, most of the terse syntax in Rust comes from the sugar they've added for error handling.
You ask a question in your first paragraph which you answer in the second.
Yes, but more importantly writing a program that compiles in Rust guarantees you a front page spot on HN.
Though it's not the only benefit, I enjoy rust and fsharp's typesystems most when refactoring code. Fearless refactoring is the right expression here.
The only issue with it is that Rust's aversion to half-baked code means that you can't have "partially working code" during the refactor: you either finish it or bail on it, without the possibility to have inconsistent codebase state. This is particularly annoying for exploratory code.
On the other hand, that strictness is precisely what leads people to end up with generally reasonable code.
On the other hand, that strictness is precisely what leads people to end up with generally reasonable code.
I find a healthy dose of todo!() is excellent for this.
match foo {
(3...=5, x, BLABLABLA) => easy(x),
_ => todo!("I should actually implement this for non-trivial cases"),
}
The thing is I want an equivalent to `todo!()` for the type-system. A mode of operation where if you have some compile errors, you can still run tests. Like for example, if you have
Same thing for the borrow-checker.
fn foo() -> impl Display {
NotDisplay::new()
}
fn foo() -> impl Display {
panic!("`NotDisplay` doesn't `impl Display`")
}
Same thing for the borrow-checker.
Sounds like 'Typed Holes'[1] in the Haskell ecosystem.
[1]: https://downloads.haskell.org/~ghc/7.10.3-rc1/users_guide/ty...
[1]: https://downloads.haskell.org/~ghc/7.10.3-rc1/users_guide/ty...
So maybe a proc macro which lets you #[dummy(Clone,Eq,PartialEq)] instead of #[derive(Clone,Eq,PartialEq)] ?
Although you said "mode of operation" and I can't get behind that idea, I think the choice to just wrap overflow by default for the integer types in release builds was probably a mistake. It's good that I can turn it off, but it shouldn't have been the default.
Although you said "mode of operation" and I can't get behind that idea, I think the choice to just wrap overflow by default for the integer types in release builds was probably a mistake. It's good that I can turn it off, but it shouldn't have been the default.
What's the advantage of that over putting `return todo!();` at the top of `foo()`? You do have to go through and mark the places where you have further work to do, but you don't have to finish the refactor.
I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should. Think borrow checking, for example. If it could be changed automatically to Arc<Mutex<T>> from &T, when running the test you could say not only the borrow checker error, but also point at the specific runtime case that the borrow checker protected you from if any test exercises it.
Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
And these strategies are things that people need to be taught about, individually. I'm not saying that the current state is terrible, just that there might be things we can do to make them better.
Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
And these strategies are things that people need to be taught about, individually. I'm not saying that the current state is terrible, just that there might be things we can do to make them better.
> I'm proposing this not as a specific feature but as a general strategy: everything the compiler can conceivably recover from in a way that allows the rest of the application to run, should.
I do think that'd be useful in a variety of cases, especially for testsuites. I don't think I'd want to go as far as trying to guess how to substitute `Arc`/`Mutex`/`RwLock` for a failed borrow, but there are a few different strategies that do seem reasonably safe.
In addition to the automatic todo!() approach, there's the approach of compile-time tainting of branches of the item tree that failed to compile. If something doesn't compile, turn it into an item that when referenced makes the item referencing it also fail to compile. That would then allow any items that do compile to get tested in the testsuite.
> Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
Not in the fully general case, but ! does implement Display, so it would work in the case you posted.
I do think that'd be useful in a variety of cases, especially for testsuites. I don't think I'd want to go as far as trying to guess how to substitute `Arc`/`Mutex`/`RwLock` for a failed borrow, but there are a few different strategies that do seem reasonably safe.
In addition to the automatic todo!() approach, there's the approach of compile-time tainting of branches of the item tree that failed to compile. If something doesn't compile, turn it into an item that when referenced makes the item referencing it also fail to compile. That would then allow any items that do compile to get tested in the testsuite.
> Adding `return todo!()` works well enough for some cases, but not all, because it can't confirm against impl Trait return types.
Not in the fully general case, but ! does implement Display, so it would work in the case you posted.
can't you just put the panic in foo()? That returns !
It's a tradeoff, reminds me of Go not compiling if you have an unused variable; the strictness is a feature and basically locks out sloppy / half baked code.
I personally see Rust as an ideal "second system" language, that is, you solve a business case in a more forgiving language first, then switch (parts) to Rust if the case is proven and you need the added performance / reliability.
I personally see Rust as an ideal "second system" language, that is, you solve a business case in a more forgiving language first, then switch (parts) to Rust if the case is proven and you need the added performance / reliability.
Fsharp's type inference is great in that regard. Function types are inferred too, in contrast with rust.
I find fsharp fit for exploratory code, and its type inference is probably the enabler.
I find the Zig example to be shocking.
It's just so brittle. How can anyone think this is a good idea?
It's just so brittle. How can anyone think this is a good idea?
I assume it's a bug. However because this is an auteur language if you want the bug fixed it will be important to ensure the auteur also thinks it is a bug. If they get it into their head that it's supposed to be like this, they'll double down and regardless of how many people are annoyed they're insist on it.
Tbh you would just use ErrorTypeName.ErrorKind to check equality and not error.ErrorKind if you are worried about this.
It is a tradeoff between making some things easier. And probably compiler is not mature enough to catch this mistake yet but it will be at some point.
Zig being an auteur language is a very good thing from my perspective, for example you get this new IO approach which is amazing and probably wouldn’t happen if Andrew Kelley wasn’t in the position he is in.
I have been using Rust to write storage engines past couple years and it’s async and io systems have many performance mistakes. Whole ecosystem feels like it is basically designed for writing web servers.
An example is a file format library using Io traits everywhere and using buffered versions for w/e reason. Then you get a couple extra memcopy calls that are copying huge buffers. Combined with global allocation everywhere approach, it generates a lot of page faults which tanks performance.
Another example was, file format and just compute libraries using asyncio traits everywhere which forces everything to be send+sync+’static which makes it basically impossible to use in single thread context with local allocators.
Another example is a library using vec everywhere even if they know what size they’ll need and generating memcopies as vec is getting bigger. Language just makes it too easy.
I’m not saying Rust is bad, it is a super productive ecosystem. But it is good that Zig is able to go deeper and enable more things. Which is possible because one guy can just say “I’ll break the entire IO API so I can make it better”.
It is a tradeoff between making some things easier. And probably compiler is not mature enough to catch this mistake yet but it will be at some point.
Zig being an auteur language is a very good thing from my perspective, for example you get this new IO approach which is amazing and probably wouldn’t happen if Andrew Kelley wasn’t in the position he is in.
I have been using Rust to write storage engines past couple years and it’s async and io systems have many performance mistakes. Whole ecosystem feels like it is basically designed for writing web servers.
An example is a file format library using Io traits everywhere and using buffered versions for w/e reason. Then you get a couple extra memcopy calls that are copying huge buffers. Combined with global allocation everywhere approach, it generates a lot of page faults which tanks performance.
Another example was, file format and just compute libraries using asyncio traits everywhere which forces everything to be send+sync+’static which makes it basically impossible to use in single thread context with local allocators.
Another example is a library using vec everywhere even if they know what size they’ll need and generating memcopies as vec is getting bigger. Language just makes it too easy.
I’m not saying Rust is bad, it is a super productive ecosystem. But it is good that Zig is able to go deeper and enable more things. Which is possible because one guy can just say “I’ll break the entire IO API so I can make it better”.
> if you are worried about this
Obviously nobody knows they've made this mistake, that's why it is important for the compiler to reject the mistake and let you know.
I don't want to use an auteur language, the fact is Andrew is wrong about some things - everybody is, but because it's Andrew's language too bad that's the end of the discussion in Zig.
I like Rust's `break 'label value`. It's very rarely the right thing, but sometimes, just sometimes, it's exactly what you needed and going without is very annoying. However IIUC for some time several key Rust language people hated this language feature, so it was blocked from landing in stable Rust. If Rust was an auteur language, one person's opinion could doom that feature forever.
Obviously nobody knows they've made this mistake, that's why it is important for the compiler to reject the mistake and let you know.
I don't want to use an auteur language, the fact is Andrew is wrong about some things - everybody is, but because it's Andrew's language too bad that's the end of the discussion in Zig.
I like Rust's `break 'label value`. It's very rarely the right thing, but sometimes, just sometimes, it's exactly what you needed and going without is very annoying. However IIUC for some time several key Rust language people hated this language feature, so it was blocked from landing in stable Rust. If Rust was an auteur language, one person's opinion could doom that feature forever.
Knowing how the Zig developers operate it's 100% not a bug and it's exactly the case you described.
Andrew actually agrees with the general sentiment.
And this will be made into a compile error.
What's happening is that compiler knows the two errors come from disjoint error set, but it promotes them both to anyerror
Details at https://github.com/ziglang/zig/issues/25046
What's happening is that compiler knows the two errors come from disjoint error set, but it promotes them both to anyerror
Details at https://github.com/ziglang/zig/issues/25046
I'm smirking big time reading this :), well said
(To be clear to others, it's not even that this is 100% a bad thing, but people love to shit on "design by committee" so much, it helps to have a bit of the opposite)
(To be clear to others, it's not even that this is 100% a bad thing, but people love to shit on "design by committee" so much, it helps to have a bit of the opposite)
Why would you assume that? It's very intentional design decision.
Because it's a foot gun. People are going to shoot themselves in the foot with this feature, and I'm generous enough to assume that was not desired which makes it a bug.
As others have noted, this is not idiomatic usage. But again, this is the design ... there's no bug. Languages are full of design decisions that may not be optimal in all usages ... that's different from bugs. Footguns breed bugs.
Here's a page of non-bugs: https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7l...
Here's a page of non-bugs: https://www.reddit.com/r/ProgrammingLanguages/comments/1hd7l...
Every language has questionable design decisions that lead to brittle code, although some more than others.
Like, how can anyone think that requiring the user to always remember to explicitly write `mutex.unlock()` or `defer mutex.unlock()` instead of just allowing optional explicit unlock and having it automatically unlock when it goes out of scope by default is a good idea? Both Go and Zig have this flaw. Or, how can anyone think that having a cast that can implicitly convert from any numeric type to any other in conjunction with pervasive type inference is a good idea, like Rust's terrible `as` operator? (I once spent a whole day debugging a bug due to this.)
Like, how can anyone think that requiring the user to always remember to explicitly write `mutex.unlock()` or `defer mutex.unlock()` instead of just allowing optional explicit unlock and having it automatically unlock when it goes out of scope by default is a good idea? Both Go and Zig have this flaw. Or, how can anyone think that having a cast that can implicitly convert from any numeric type to any other in conjunction with pervasive type inference is a good idea, like Rust's terrible `as` operator? (I once spent a whole day debugging a bug due to this.)
You are right, but it doesn't mean we can't complain about it :)
As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition.
As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition.
As much as I hate 'as' and try to avoid it, it also covers several things that are impossible otherwise (integer <-> float casts are impossible without it, e.g.). I've found that sometimes just being able to express a coerce-to-type-damn-the-consequences is useful.
Another painful bugbear is when I'm converting to/from usize and I know that it is really either going to be a u64 or maybe u32 in a few cases, and I don't care about breaking usize=u128 or usize=u16 code. Give me a way to say that u32 is Into<usize> for my code!
Another painful bugbear is when I'm converting to/from usize and I know that it is really either going to be a u64 or maybe u32 in a few cases, and I don't care about breaking usize=u128 or usize=u16 code. Give me a way to say that u32 is Into<usize> for my code!
> As a side note, I hate the `as` cast in Rust. It's so brittle and dangerous it doesn't even feel like a part of the language. It's like a JavaScript developer snuck in and added it without anyone noticing. I hope they get rid of it in an edition.
Rust language hat on: I hope so too. We very much want to, once we've replaced its various use cases.
Rust language hat on: I hope so too. We very much want to, once we've replaced its various use cases.
As a Rust user, I hope that "as" never goes away. It's way too useful to get rid of, e.g. deliberately truncating numbers to a smaller number of bits. Can you do that in other ways? Absolutely. But they are all less ergonomic than "as". At most I would be ok with restricting "as" to an unsafe block, though that isn't a perfect solution because unsafe isn't really meant to apply to such cases.
I'm hoping that we provide ergonomic alternatives for all the individual use cases. The brevity of `as` is a major reason we haven't removed it yet.
We have `.into()` for lossless conversions like u32 to u64.
We need to fix the fact that `usize` doesn't participate in lossless conversions (e.g. even on 64-bit you can't convert `usize` to `u64` via `.into()`).
We need to fix the fact that you can't write `.into::<u64>()` to disambiguate types.
And I'm hoping we add `.trunc()` for lossy conversion.
And eventually, after we provide alternatives for all of those and some others, we've talked about changing `as` to be shorthand for `.into()`.
We have `.into()` for lossless conversions like u32 to u64.
We need to fix the fact that `usize` doesn't participate in lossless conversions (e.g. even on 64-bit you can't convert `usize` to `u64` via `.into()`).
We need to fix the fact that you can't write `.into::<u64>()` to disambiguate types.
And I'm hoping we add `.trunc()` for lossy conversion.
And eventually, after we provide alternatives for all of those and some others, we've talked about changing `as` to be shorthand for `.into()`.
A method call like `.trunc()` is still going to be abysmally less ergonomic than `as`. It relies on inference or turbofish to pick a type, and it has all the syntactic noise of a function call on top of that.
Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless).
Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless).
> A method call like `.trunc()` is still going to be abysmally less ergonomic than `as`. It relies on inference or turbofish to pick a type, and it has all the syntactic noise of a function call on top of that.
If `as` gets repurposed for safe conversions (e.g. u32 to u64), there's some merit to the more hazardous conversions being slightly noisier. I'm all for them being no noisier than necessary, but even in my most conversion-heavy code (which has to convert regularly between usize and u64), I'd be fine writing `.into()` or `.trunc()` everywhere, as long as I don't have to write `.try_into()?` or similar.
> Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless).
I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions.
If `as` gets repurposed for safe conversions (e.g. u32 to u64), there's some merit to the more hazardous conversions being slightly noisier. I'm all for them being no noisier than necessary, but even in my most conversion-heavy code (which has to convert regularly between usize and u64), I'd be fine writing `.into()` or `.trunc()` everywhere, as long as I don't have to write `.try_into()?` or similar.
> Not to mention this sort of proliferation of micro-calls for what should be <= 1 instruction has a cost to debug performance and/or compile times (though this is something that should be fixed regardless).
I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions.
> I'd be fine writing `.into()` or `.trunc()`
Yes, this is specifically what I'm disagreeing with.
> I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions.
That's the cost to compile time I mentioned.
Yes, this is specifically what I'm disagreeing with.
> I fully expect that such methods will be inlined, likely even in debug mode (e.g. `#[inline(always)]`), and compile down to the same minimal instructions.
That's the cost to compile time I mentioned.
Many things in the language theoretically go through a trait as well, except that we have special cases in the compiler to handle those traits more efficiently. If this were a performance issue, there's no reason we couldn't do the same for `.trunc()` or `.into()`.
> We need to fix the fact that you can't write `.into::<u64>()` to disambiguate types.
Yes, that would be great. In the meantime, if you can't wait but want something like this, you can DIY it via an extension trait.
It's very easy to write it yourself, this is all it takes:
Yes, that would be great. In the meantime, if you can't wait but want something like this, you can DIY it via an extension trait.
It's very easy to write it yourself, this is all it takes:
pub trait To {
fn to<T>(self) -> T where Self: Into<T> {
<Self as Into<T>>::into(self)
}
}
> We need to fix the fact that you can't write `.into::<u64>()` to disambiguate types.
This confused me too at first. You have to do `u64::from(_)` right? It makes sense in a certain way, similar to how you have to do `Vec::<u64>::new()` rather than `Vec::new::<u64>()`, but it is definitely more annoying for `into`.
This confused me too at first. You have to do `u64::from(_)` right? It makes sense in a certain way, similar to how you have to do `Vec::<u64>::new()` rather than `Vec::new::<u64>()`, but it is definitely more annoying for `into`.
Yeah, you either need `u64::from` or `let x: u64 = expr.into()` or similar.
It does "make sense" but it's obnoxious, and we should have something better.
It does "make sense" but it's obnoxious, and we should have something better.
If only we had type ascription on expressions... ducks
> And eventually, after we provide alternatives for all of those and some others, we've talked about changing `as` to be shorthand for `.into()`.
Whoa, that could be awesome. It's always felt a bit unfortunate that you can't write `val.into::<SomeExplicitType>::()`—because the type parameter is on the trait, not the method. Of course, `SomeExplicitType::from` works, but sometimes that slightly upsets the flow of code.
Having just `val as SomeExplicitType` might be really nice for that common case. I do wonder if it'd feel too magic… but I'm optimistic to see what the lang team comes up with.
Whoa, that could be awesome. It's always felt a bit unfortunate that you can't write `val.into::<SomeExplicitType>::()`—because the type parameter is on the trait, not the method. Of course, `SomeExplicitType::from` works, but sometimes that slightly upsets the flow of code.
Having just `val as SomeExplicitType` might be really nice for that common case. I do wonder if it'd feel too magic… but I'm optimistic to see what the lang team comes up with.
How are people supposed to use a language, that changes syntax?
Rust's edition system allows the language frontend to be changed every few years.
In particular, note that new Rust compiles code with both old and new editions. Upgrading Rust does not require you to move to the new edition. And one project can pull in crates from multiple editions.
(Imagine if Python 3 let you import Python 2 modules seamlessly.)
(Imagine if Python 3 let you import Python 2 modules seamlessly.)
That's nice, but I think at some point they will cut the old implementation, as otherwise they would end with hundreds of versions.
And it doesn't exactly help to compile newer software on an older OS.
And it doesn't exactly help to compile newer software on an older OS.
No, there's a commitment to not cut old editions. A new edition/frontend comes out every 3 years, so Rust (and maybe humanity) is probably going to be completely dead long before it has hundreds of versions.
To elaborate on what sunshowers said, because editions only impact the early parts of the compiler, most of the code isn’t edition specific, which makes maintenance easy.
As someone working with bitfields and enums-to-ints a lot, you can take ``as`` out of my cold dead hands.
I would like a language where your call stack can't be bigger than two/three.
You can call functions inside your function Main, but these function can't call any functions anymore (exception being flat helper functions defined inside your function).
I think it would save a huge chunk of time by just having all programs really nice and flat. You'd naturally gravitate towards mechanisms that make programs flat.
You can call functions inside your function Main, but these function can't call any functions anymore (exception being flat helper functions defined inside your function).
I think it would save a huge chunk of time by just having all programs really nice and flat. You'd naturally gravitate towards mechanisms that make programs flat.
Also allows founding of: The Flat Program Society.
I didn't even see the error after the first glance until I read your comment.
I saw this comment first and then read the zig and still couldn’t find the error until I read the explanation below it. This has to be a bug.
Yeah, I had to do a double take while reading the article because I missed the error completely while looking at the code.
Can't a linter catch that you're referring to an error that doesn't exist anywhere else in your system and warn you about that and suggest you use switch instead of if?
I would've assumed the error set is generated based on function signatures. Sick stuff.
>The code will compile just fine. The Zig compiler will generate a new number for each unique 'error.*'
This is wild. I assume there's at least the tooling to catch this kind of errors right?
This is wild. I assume there's at least the tooling to catch this kind of errors right?
There's no special tooling to catch this, because nobody catches an error with if-else—it's simply not idiomatic. Everyone uses switch statements in the catch block, and I've never seen anybody using anything other than switch, when catching an error.
Both the Zig standard library as well as several third party projects do check errors like this.
I already commented on Zig compiler/stdlib code itself, but here's Tigerbeetle and Bun, the two biggest(?) Zig codebases:
https://github.com/search?q=repo%3Atigerbeetle%2Ftigerbeetle...
https://github.com/search?q=repo%3Aoven-sh%2Fbun%20%22%3D%3D...
I already commented on Zig compiler/stdlib code itself, but here's Tigerbeetle and Bun, the two biggest(?) Zig codebases:
https://github.com/search?q=repo%3Atigerbeetle%2Ftigerbeetle...
https://github.com/search?q=repo%3Aoven-sh%2Fbun%20%22%3D%3D...
Ok, while it's cool that the TigerBeetle link now shows no matches (down from two) the comment now feels wrong. Anyways, you guys left in the `!= error.` checks, so here's some snapshots that hopefully won't be invalidated :P
https://github.com/tigerbeetle/tigerbeetle/blob/b173fdc82700...
https://github.com/tigerbeetle/tigerbeetle/blob/b173fdc82700... (different file, same check.)
https://github.com/tigerbeetle/tigerbeetle/blob/b173fdc82700...
https://github.com/tigerbeetle/tigerbeetle/blob/b173fdc82700... (different file, same check.)
Good catch of != thanks!
But why?
If I just need to check for 1 specific error and do something why do I need a switch?
In Rust you have both "match" (like switch) and "if let" which just pattern matches one variant but both are properly checked by the compiler to have only valid values.
If I just need to check for 1 specific error and do something why do I need a switch?
In Rust you have both "match" (like switch) and "if let" which just pattern matches one variant but both are properly checked by the compiler to have only valid values.
“There’s no specific tooling to catch this, because nobody[…]”. So? This is a standard library/language feature, which is usually the first place people go for features in the language. To say that nobody uses it is stupid.
The example is a bit dubious. Sure, it compiles just fine, because the author is not using errors properly in zig. Here, he uses the global error set with `error. AccessDenid`, and as stated, it compiles just fine because when you reach the global error set, it's integers all the way down.
If the author had written `FileError.AccessDenid`, this would not have compiled, as it would be comparing with the `FileError` error set.
The global error set is pretty much never used, except when you want to allow a user to provide his own errors, so you allow the method to return `anyerror`.
If the author had written `FileError.AccessDenid`, this would not have compiled, as it would be comparing with the `FileError` error set.
The global error set is pretty much never used, except when you want to allow a user to provide his own errors, so you allow the method to return `anyerror`.
You say never, but even the Zig stdlib does this occasionally.
Like here in `std/tar.zig`: https://github.com/ziglang/zig/blob/50edad37ba745502174e49af...
Or here in `main.zig`: https://github.com/ziglang/zig/blob/50edad37ba745502174e49af...
And in a bunch of other places: https://github.com/search?q=repo%3Aziglang%2Fzig+%22%3D%3D+e...
Like here in `std/tar.zig`: https://github.com/ziglang/zig/blob/50edad37ba745502174e49af...
Or here in `main.zig`: https://github.com/ziglang/zig/blob/50edad37ba745502174e49af...
And in a bunch of other places: https://github.com/search?q=repo%3Aziglang%2Fzig+%22%3D%3D+e...
All examples of this type come down to "the user made a mistake", but that is kind of the the entire point. It is not possible to make that mistake in rust.
I'm not saying that zig has the same level of safety than rust, i'm just saying that grabbing a knife by the blade is not an argument for using a spoon.
The error presented in this example would not be written by any zig developer. Heck, before this example i didn't even knew that you could compare directly to the global error set, and i maintain a small library.
zig and rust do not have the same scope. I honestly do not think they should be compared. Zig is better compared to C, and rust is better compared to C++.
The error presented in this example would not be written by any zig developer. Heck, before this example i didn't even knew that you could compare directly to the global error set, and i maintain a small library.
zig and rust do not have the same scope. I honestly do not think they should be compared. Zig is better compared to C, and rust is better compared to C++.
Rust and Zig are the two most prominent new systems programming languages. It's only natural for people to compare them, from perspectives such as "I'm starting a project and need to choose what language to use".
The languages are very different in scope, scale, and design goals; yes. That means there's tradeoffs that might make one language or the other more suitable for a particular person or project, and that means it can be interesting and worthwhile to talk about those tradeoffs.
In particular, Rust's top priority is program correctness -- the language tries hard not to let you write "you're holding it wrong" bugs, whereas Zig tends to choose simplicity and explicitness instead. That difference in design goals is the whole point of the article, not a reason to dismiss it.
The languages are very different in scope, scale, and design goals; yes. That means there's tradeoffs that might make one language or the other more suitable for a particular person or project, and that means it can be interesting and worthwhile to talk about those tradeoffs.
In particular, Rust's top priority is program correctness -- the language tries hard not to let you write "you're holding it wrong" bugs, whereas Zig tends to choose simplicity and explicitness instead. That difference in design goals is the whole point of the article, not a reason to dismiss it.
Sure. Did i dismiss the article? Or was I only saying that the example was bad?
I was specifically responding to the statement "Zig and rust do not have the same scope. I honestly do not think they should be compared".
I don't know enough Zig to have a qualified opinion on the particular example (besides being very surprised it compiled). However, I thought this post from the front page the other day had more practical and thoughtful examples of this kind of thing: https://www.openmymind.net/Im-Too-Dumb-For-Zigs-New-IO-Inter...
I don't know enough Zig to have a qualified opinion on the particular example (besides being very surprised it compiled). However, I thought this post from the front page the other day had more practical and thoughtful examples of this kind of thing: https://www.openmymind.net/Im-Too-Dumb-For-Zigs-New-IO-Inter...
> The error presented in this example would not be written by any zig developer.
No True Scotsman fallacy. It was written by the Zig developer who wrote it.
No True Scotsman fallacy. It was written by the Zig developer who wrote it.
No True Scotsman is only a fallacy when it involves changing your definitions after counterexamples are presented. But it can also be insisting on a non-standard definition.
E.g., "No true Scotsman would hate haggis!" "You're wrong, my friend Angus hates haggis, and he's a Scotsman through and through." "Well, if he hates haggis, then he isn't a true Scotsman!"
The first speaker isn't changing his definitions, so he's not actually engaging in the fallacy. Rather, he's insisting on his own idiosyncratic definition of what standards you must meet to be considered a "true" Scotsman, and insisting that Angus doesn't meet his standard.
But that's enough digression on "No True Scotsman". We now return you to your regularly-scheduled arguing over code. :-)
E.g., "No true Scotsman would hate haggis!" "You're wrong, my friend Angus hates haggis, and he's a Scotsman through and through." "Well, if he hates haggis, then he isn't a true Scotsman!"
The first speaker isn't changing his definitions, so he's not actually engaging in the fallacy. Rather, he's insisting on his own idiosyncratic definition of what standards you must meet to be considered a "true" Scotsman, and insisting that Angus doesn't meet his standard.
But that's enough digression on "No True Scotsman". We now return you to your regularly-scheduled arguing over code. :-)
> is only a fallacy when it involves changing your definitions after counterexamples are presented
That is false.
Edit: The fact is that we have the counterexample: the piece of code written by a zig developer who somehow isn't actually a zig developer. Where the counterexample comes from, who presents it, and when isn't relevant to whether this is a fallacy. The Wikipedia article overstresses the order of things, but that is never an issue with a fallacy. There are thousands upon thousands of examples where, e.g., someone claims that people aren't Christians because they don't follow Christ's teachings and that claim is called out as a No True Scotsman fallacy--it implicitly redefines what "Christian" is for the sake of denying that a Christian actually is a Christian, in order to preserve some claim of some virtue of Christianity in the face of clear evidence to the contrary.
That is false.
Edit: The fact is that we have the counterexample: the piece of code written by a zig developer who somehow isn't actually a zig developer. Where the counterexample comes from, who presents it, and when isn't relevant to whether this is a fallacy. The Wikipedia article overstresses the order of things, but that is never an issue with a fallacy. There are thousands upon thousands of examples where, e.g., someone claims that people aren't Christians because they don't follow Christ's teachings and that claim is called out as a No True Scotsman fallacy--it implicitly redefines what "Christian" is for the sake of denying that a Christian actually is a Christian, in order to preserve some claim of some virtue of Christianity in the face of clear evidence to the contrary.
Then you might want to update the Wikipedia article which claims that it's a fallacy "in which one modifies a prior claim in response to a counterexample by asserting the counterexample is excluded by definition", citing three links to support that: https://iep.utm.edu/fallacy/, http://www.fallacyfiles.org/scotsman.html, and https://archive.org/details/godphilosophy0000flew/page/104/m....
To say "No true Scotsman would dislike haggis" is to assert "If A, then B": If you are a true Scotsman, then you will like haggis. The response "Angus doesn't like haggis" is asserting "not B". To which the response "therefore he's not a true Scotsman" is asserting "not A". But "if A, then B" logically implies "if not B, then not A". Therefore when the person's definitions don't change, *it is not a fallacy*. It might be wrong — his definition of a "true" Scotsman might be a false premise — but the conclusion logically follows from the premise, so it is not a fallacy.
To say "No true Scotsman would dislike haggis" is to assert "If A, then B": If you are a true Scotsman, then you will like haggis. The response "Angus doesn't like haggis" is asserting "not B". To which the response "therefore he's not a true Scotsman" is asserting "not A". But "if A, then B" logically implies "if not B, then not A". Therefore when the person's definitions don't change, *it is not a fallacy*. It might be wrong — his definition of a "true" Scotsman might be a false premise — but the conclusion logically follows from the premise, so it is not a fallacy.
To reply to your edit: the fact that he wrote this in an example does not mean that he would write this in actual code. Examples are often contrived. The guy you're replying to clearly meant "no Zig developer would write this in actual code", which may have been wrong but this counterexample isn't a case of writing it in actual code.
As for the second part of your edit, arguing about definitions of who fits into the group is commonly mistaken as "no true Scotsman". For example, just because you call yourself a Scotsman doesn't necessarily make you one: if you have no Scottish ancestry, do not live in Scotland, and do not hold a Scottish passport, few people would agree with you that you are a Scotsman just because you assert that you are. They would insist on some standard for calling you a Scotsman that goes beyond "I say that I am one, therefore I clearly am one". Or, to use the example of Christians: millions of people around the world would say "no true Christian would deny the divinity of Christ: it's a fundamental teaching of Christianity". That is not a "no true Scotsman" argument, despite the presence of people who call themselves Christians who do deny the divinity of Christ. It is, rather, saying "You call yourself a Scotsman but you do not measure up to the commonly-accepted standard of being a Scotsman".
OTOH, your example of people saying "He's not really a Christian because he doesn't live up to Christ's teaching" is a "no true Scotsman" fallacy, attempting to redefine the commonly-accepted standard. Because nearly every Christian knows that we (I'm a Christian myself) never fully live up to Christ's teaching, and can always do better. So trying to say "He's not a true Christian because he doesn't measure up" is to redefine the standard in a way that would exclude pretty much everybody, and that's not at all what it means.
Short version: membership in certain groups can have standards (you're not a Zig developer if you've never written a single line of Zig code), and asserting those standards is not necessarily this fallacy, even if those standards are disputed by some people. (E.g., the case of groups that call themselves Christian while denying the divinity of Christ, which everyone NOT part of those groups would say is a fundamental part of the standard for being a true Christian).
*EDIT:* In my last sentence I wrote "everyone NOT part of those groups"; I should say "every Christian NOT part of those groups" if I wanted to be fully accurate. Because many non-Christians would deny that accepting the divinity of Christ is part of the definition, but pretty much all Christians who do accept that Christ was indeed God in human form will agree that that doctrine is one of the fundamental requirements, and that if you deny it you can't truthfully call yourself a Christian. (Hopefully I phrased that in a way that's both accurate and comprehensible.)
As for the second part of your edit, arguing about definitions of who fits into the group is commonly mistaken as "no true Scotsman". For example, just because you call yourself a Scotsman doesn't necessarily make you one: if you have no Scottish ancestry, do not live in Scotland, and do not hold a Scottish passport, few people would agree with you that you are a Scotsman just because you assert that you are. They would insist on some standard for calling you a Scotsman that goes beyond "I say that I am one, therefore I clearly am one". Or, to use the example of Christians: millions of people around the world would say "no true Christian would deny the divinity of Christ: it's a fundamental teaching of Christianity". That is not a "no true Scotsman" argument, despite the presence of people who call themselves Christians who do deny the divinity of Christ. It is, rather, saying "You call yourself a Scotsman but you do not measure up to the commonly-accepted standard of being a Scotsman".
OTOH, your example of people saying "He's not really a Christian because he doesn't live up to Christ's teaching" is a "no true Scotsman" fallacy, attempting to redefine the commonly-accepted standard. Because nearly every Christian knows that we (I'm a Christian myself) never fully live up to Christ's teaching, and can always do better. So trying to say "He's not a true Christian because he doesn't measure up" is to redefine the standard in a way that would exclude pretty much everybody, and that's not at all what it means.
Short version: membership in certain groups can have standards (you're not a Zig developer if you've never written a single line of Zig code), and asserting those standards is not necessarily this fallacy, even if those standards are disputed by some people. (E.g., the case of groups that call themselves Christian while denying the divinity of Christ, which everyone NOT part of those groups would say is a fundamental part of the standard for being a true Christian).
*EDIT:* In my last sentence I wrote "everyone NOT part of those groups"; I should say "every Christian NOT part of those groups" if I wanted to be fully accurate. Because many non-Christians would deny that accepting the divinity of Christ is part of the definition, but pretty much all Christians who do accept that Christ was indeed God in human form will agree that that doctrine is one of the fundamental requirements, and that if you deny it you can't truthfully call yourself a Christian. (Hopefully I phrased that in a way that's both accurate and comprehensible.)
comparing these examples to “grabbing a knife by the blade” equates writing code that looks right to picking up a sharp and jagged object with your hands that would obviously hurt and will hurt once you hold it.
It’s more like picking up a fork and being surprised to find out that it’s burning hot without any visible difference.
It’s more like picking up a fork and being surprised to find out that it’s burning hot without any visible difference.
Why does the compiler decay the FileError and the global error set to an integer? If they were unique types, the if statement would not have compiled.
`FileError.AccessDenied` is a unique value in a unique error set. `error.AccessDenid` has not been defined anywhere and hence is just given an integer value at some point by the compiler.
As I stated before, this error wouldn't even exist in the first place in no codebase ever: look how the method that fails returns a `FileError` and not an `anyerror`
It could be rightly argued that it still shouldn't compile though.
As I stated before, this error wouldn't even exist in the first place in no codebase ever: look how the method that fails returns a `FileError` and not an `anyerror`
It could be rightly argued that it still shouldn't compile though.
This is compiler bug, the code should not compile (see issue #25046)
I vibe with this entirely.
Rust to me makes a lot more sense. The compiler gives reasonable errors, the code structure is clean and it's obvious where everything should go.
I just can't deal with Typescript at all. There is a sense of uncertainty in TypeScript that is just unbearable. It is really hard to be confident about the code.
Rust to me makes a lot more sense. The compiler gives reasonable errors, the code structure is clean and it's obvious where everything should go.
I just can't deal with Typescript at all. There is a sense of uncertainty in TypeScript that is just unbearable. It is really hard to be confident about the code.
Rust caught the lock being held across an await boundary, but without further context I'd hedge there's still a concurrency issue there if the solution was to release the lock before the await.
Presumably the lock is intended to be used for blocking until the commit is created, which would only be guaranteed after the await. Releasing the lock after submitting the transaction to the database but before getting confirmation that it completed successfully would probably result in further edge cases. I'm unfamiliar with rust's async, but is there a join/select that should be used to block, after which the lock should be unlocked?
Presumably the lock is intended to be used for blocking until the commit is created, which would only be guaranteed after the await. Releasing the lock after submitting the transaction to the database but before getting confirmation that it completed successfully would probably result in further edge cases. I'm unfamiliar with rust's async, but is there a join/select that should be used to block, after which the lock should be unlocked?
If you need to hold a lock across an await point, you can switch to an async-aware mutex. Both the futures crate and the tokio crate have implementations of async-aware mutexes. You usually only want this if you're holding it across an await point because they're more expensive than blocking mutexes (the other reason to use this is if you expect the mutex to be held for a significant amount of time, so an async-aware lock will allow other tasks to progress while waiting to take the lock).
You can use a async-aware mutex if you require it to be held across await points. For example, if using the Tokio runtime: https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html.
> Assigning a value to 'window.location.href' doesn't immediately redirect you, like I thought it would.
That's not a "Typescript" or language issue, that's a DOM/browser API weirdness
That's not a "Typescript" or language issue, that's a DOM/browser API weirdness
You could argue that the DOM API being weird is partially because typescript didn't exist when they came up with the API, so the API wasn't designed with typescript in mind. If the DOM API was written against Rust, the API could have been designed against Rust's type system to make this error more difficult.
Jeeze, why should attribute assignment have side-effects, anyway? That'd be gross!
I think it's unavoidable for any sufficiently complicated object or variable. Think of c++'s unique_ptr that guarantees that only a single reference to memory exists so that that the memory can be free'd safely when it goes out of scope. Or thing of a complicated object that has references to allocated memory. You either allocate a bunch of memory and copy values over or have two objects refer to the same bit of allocated memory. Each solution potentially has major downsides. Your objects don't even have to be all that exotic, think of a vector holding 1024 fp64 values or a 8kb long string.
Yikes, sharing the same bit of memory seems like a Demeter violation! Is it really all that common? Maybe I am too OOP-pilled to grok the sense of it.
*though it could have been fixed by typescript had they cared.
How could Typescript have fixed this?
they could have provided a seperate api over top of this and error’d on use? It’s a clearly error-prone api.
I genuinely don't understand - how could Typescript provide a separate API on top of this? I usually do not expect Typescript to start generating code and APIs for me.
Also, Typescript is adding types on top of the JavaScript language, not the DOM API.
Also, Typescript is adding types on top of the JavaScript language, not the DOM API.
No they shouldn't have done. The Browser API Implementation doesn't exist in TypeScript. It exists in the browser. TypeScript shouldn't be fixing how the browser behaves.
Think about what is happening. When you build to the browser as a target, TSC basically transpiles the TypeScript code to JavaScript. The Browser APIs that Typescript provides are a bunch of type definitions. When it transpiles the code the only thing it can really do is check the types match up.
Think about what is happening. When you build to the browser as a target, TSC basically transpiles the TypeScript code to JavaScript. The Browser APIs that Typescript provides are a bunch of type definitions. When it transpiles the code the only thing it can really do is check the types match up.
The first save is from a failure of Rust's own making: async Rust. It's an awful footgun of a concept that is made vaguely bearable by the rest of the type system.
(but is still one of the most capable languages for async programming)
Maybe. I think async as a concept is kind of bad in general, but if you want it, GC makes it more ergonomic.
I think one of the most useful places for async is embedded - Embassy is amazing & you can't use GC there. Rust async almost seems like it was designed more for that than for the high level web stuff that lots of people use it for.
They definitely could have made it more ergonomic though. Pin is super confusing and there are a disappointing number of footguns, e.g. it's very easy to mess up loop/select and that's super common.
They definitely could have made it more ergonomic though. Pin is super confusing and there are a disappointing number of footguns, e.g. it's very easy to mess up loop/select and that's super common.
I encourage every one to at least stop writing code in Python.
People who recommend that other people stop using one of the best documented languages on the planet with a huge library ecosystem, a friendly user base, a clean syntax, excellent reference documentation, intuitive function names, readable tracebacks, superb editor and AI support.
Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?
The accessibility of Python is overrated. It's a language with warts and issues just like the others. Also the lack of static typing is a real hindrance (yes I know about mypy).
The accessibility of Python is overrated. It's a language with warts and issues just like the others. Also the lack of static typing is a real hindrance (yes I know about mypy).
> Intuitive function names like __new__() and __init__()? Or id() and pickle.dumps()?
I use python for some basic scripting and I don't write anything huge. Most of these do roughly what I would expect.
> __new__ is a static method that’s responsible for creating and returning a new instance (object) of the class. It takes the class as its first argument followed by additional arguments.
> In Python, __init__ is an instance method that initializes a newly created instance (object). It takes the object as its first argument followed by additional arguments
> Python id() function returns the “identity” of the object. The identity of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.
The pickel.dumps() is the only one that is a bit odd until to find out what the pickle module does.
> The accessibility of Python is overrated.
The accessibility isn't overrated. Python has something that is missing from a lot of languages that isn't often talked about. It is really good a RAD (Rapid Application Development). You can quickly put something together that works reasonably well, it also is enough of the proper language that you can build bigger things in it.
> It's a language with warts and issues just like the others.
Like every other one.
I use python for some basic scripting and I don't write anything huge. Most of these do roughly what I would expect.
> __new__ is a static method that’s responsible for creating and returning a new instance (object) of the class. It takes the class as its first argument followed by additional arguments.
> In Python, __init__ is an instance method that initializes a newly created instance (object). It takes the object as its first argument followed by additional arguments
> Python id() function returns the “identity” of the object. The identity of an object is an integer, which is guaranteed to be unique and constant for this object during its lifetime.
The pickel.dumps() is the only one that is a bit odd until to find out what the pickle module does.
> The accessibility of Python is overrated.
The accessibility isn't overrated. Python has something that is missing from a lot of languages that isn't often talked about. It is really good a RAD (Rapid Application Development). You can quickly put something together that works reasonably well, it also is enough of the proper language that you can build bigger things in it.
> It's a language with warts and issues just like the others.
Like every other one.
The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.
A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
>The difference between new and init is not knowable from reading their names. The same is true of pickle. By definition, that makes them unintuitive.
By that standard nothing is. At some point if you are using a programming language you are going to have to RTFM. None of things you cherry-picked would be used by a novice either.
Every example you gave are what I call are "Ronsil" (https://en.wikipedia.org/wiki/Does_exactly_what_it_says_on_t...).
Even the pickle.dumps() example is obvious when you read the description for the module and works exactly the same to json.dumps(), which works similarly to dumps() methods and terminology in other programming languages.
I feel like I am repeating myself.
> A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
Nonsense. None of those I would say are RAD. JavaScript literally has no standard lib and requires node/npm these days and that can be a complete rigmarole in itself. C# these relies heavily on DI. I have no idea about Clojure so won't comment.
All the RAD stuff in C# and JS is heavily reliant on third party scripts and templates, that have all sorts of annoying quirks and bloat your codebase. That isn't the case with Python at all
By that standard nothing is. At some point if you are using a programming language you are going to have to RTFM. None of things you cherry-picked would be used by a novice either.
Every example you gave are what I call are "Ronsil" (https://en.wikipedia.org/wiki/Does_exactly_what_it_says_on_t...).
Even the pickle.dumps() example is obvious when you read the description for the module and works exactly the same to json.dumps(), which works similarly to dumps() methods and terminology in other programming languages.
I feel like I am repeating myself.
> A lot of languages work for RAD including Clojure, C#, and JavaScript. This is nothing special about Python.
Nonsense. None of those I would say are RAD. JavaScript literally has no standard lib and requires node/npm these days and that can be a complete rigmarole in itself. C# these relies heavily on DI. I have no idea about Clojure so won't comment.
All the RAD stuff in C# and JS is heavily reliant on third party scripts and templates, that have all sorts of annoying quirks and bloat your codebase. That isn't the case with Python at all
R.E. scaffolding in C#, with upcoming .NET 10, it's really simple:
- Write code to myfile.cs
- `dotnet run myfile.cs`
That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
And since we're talking about RAD, Python can't even compare to Clojure. Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
[1]: https://github.com/babashka/scittle
That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
And since we're talking about RAD, Python can't even compare to Clojure. Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
[1]: https://github.com/babashka/scittle
> R.E. scaffolding in C#, with upcoming .NET 10, it's really simple: - Write code to myfile.cs - `dotnet run myfile.cs`
> That doesn't need scaffolding either. And the standard library is huge too; you could even add dependencies in that file.
I've just had a quick look at some of this and they've basically just moved stuff in to the cs file from the proj file. I remember them saying this was on the roadmap when I was doing a .NET 8 refresher.
> And since we're talking about RAD, Python can't even compare to Clojure.
I am unlikely to ever use Clojure, I certainly won't be able to use it at work.
> Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
All sounds very complicated and is the sort of thing I am trying to get away from. I find all of this stuff more of a hinderance than anything else.
I've just had a quick look at some of this and they've basically just moved stuff in to the cs file from the proj file. I remember them saying this was on the roadmap when I was doing a .NET 8 refresher.
// app.cs
#:package Humanizer@2.*
using Humanizer;
> And since we're talking about RAD, Python can't even compare to Clojure.
I am unlikely to ever use Clojure, I certainly won't be able to use it at work.
> Having a separate REPL "server" that you interact with from your text editor with access to the JVM's ecosystem and standard library inside of a "living" environment and structural navigation from being a LISP is pure RAD. Heck, I often start a REPL "server" inside chrome's devtools with scittle[1] if I need to rapidly and programmatically interact with a website and/or to script something; I haven't been able to do that anywhere else. Even pure JS.
All sounds very complicated and is the sort of thing I am trying to get away from. I find all of this stuff more of a hinderance than anything else.
> By that standard nothing is.
Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
> Even the pickle.dumps() example is obvious
Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
> Even the pickle.dumps() example is obvious
Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
> Okay, and? I didn't make the claim that some other language was all that. I was dispelling the claim that Python is.
I believe that people should RTFM. Any arguments that is predicated on not reading the documentation for the language, and then pretending that it is somehow opaque, I am going to dismiss to be quite honest.
> Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
You are still cherry-picking things to attempt to prove a point. I don't find this convincing.
> The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
I didn't say that you can't do RAD with libraries. You didn't understand what I was saying at all.
I can get up and running with Python in mere minutes. It doesn't require a application templates/scaffolding apps to get started (like C# and JS/TS). You just need a text editor and a terminal. Doing that is still quicker and easier to get something working than all the gumpf you have to do with the other languages. I BTW was a JS/TS and .NET for about 15 years
I just wish there were more Python and Go jobs in the UK.
I believe that people should RTFM. Any arguments that is predicated on not reading the documentation for the language, and then pretending that it is somehow opaque, I am going to dismiss to be quite honest.
> Well, we've so far been restricted to function names which is what the claim was. There are plenty of cryptic other names in Python like ABCMeta, deriving from `object`, MRO, slots, dir, spec, etc.
You are still cherry-picking things to attempt to prove a point. I don't find this convincing.
> The idea you can't do RAD with libraries is insane. Games are developed rapidly, and a lot of game engines use C#. The fact that you're using Unity, a very large dependency, means nothing regarding whether you can do RAD, which is more about having the right architecture, tooling, and development cycle.
I didn't say that you can't do RAD with libraries. You didn't understand what I was saying at all.
I can get up and running with Python in mere minutes. It doesn't require a application templates/scaffolding apps to get started (like C# and JS/TS). You just need a text editor and a terminal. Doing that is still quicker and easier to get something working than all the gumpf you have to do with the other languages. I BTW was a JS/TS and .NET for about 15 years
I just wish there were more Python and Go jobs in the UK.
C# does not require scaffolding any more than Python does. It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too. How much setup you need really depends on what you are trying to do; if you are using Django, there will be an insignificant amount of that, and some of the most complicated setups I've seen have been with Pylons/Pyramid. If you're just making a CLI app, well I don't see how it's any less setup with Python than with Node. And anyway, RAD isn't about setup time, it's about iteration time.
I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
> C# does not require scaffolding any more than Python does.
They've changed so much in the last few years I honestly don't know anymore. Which is part of the entire problem.
The last time I bothered writing anything with C# / .NET was .NET 8. They definitely had scaffolding tools for popular project types. Setting stuff up from a blank project wasn't straight forward.
> It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too.
I find dealing with C++ and CMake/Make (I hobby program Vulkan/OpenGL) easier than dealing with Node JS and NPM. People think I am being hyperbolic when I say this, I am not. Which show you how insane the JS ecosystem is.
I am honestly fed up of both C# and JS. There are far more headaches with both (especially if you are using TypeScript).
If you use TypeScript and don't want to use babel, until recently you have to basically use tsx or tsnode . You then have to wrangle a magic set of options in the tsconfig.json to have some popular libraries work.
.NET after 5 has absolute DI madness in ASP.NET and none of it seems documented properly anywhere (or I can't find it) and it seems to change subtly every time they update .NET or ASP.NET.
I ended up resorting to pulling down the entire source code to see what the Startup was doing. C# now has total language and syntactic sugar overload.
I have almost none of these headaches with Python and Go.
> And anyway, RAD isn't about setup time, it's about iteration time.
It is both. I find Python quicker, easier and less headaches that either JS or .NET. I am well versed in C# and JS.
I know less Python than .NET and JS/TS, yet I find it easier.
> I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
That is true. I am sure most Go jobs advertised in the UK are in London.
They've changed so much in the last few years I honestly don't know anymore. Which is part of the entire problem.
The last time I bothered writing anything with C# / .NET was .NET 8. They definitely had scaffolding tools for popular project types. Setting stuff up from a blank project wasn't straight forward.
> It comes with a large standard library (aka .NET). Even the NodeJS standard library is quite large now too.
I find dealing with C++ and CMake/Make (I hobby program Vulkan/OpenGL) easier than dealing with Node JS and NPM. People think I am being hyperbolic when I say this, I am not. Which show you how insane the JS ecosystem is.
I am honestly fed up of both C# and JS. There are far more headaches with both (especially if you are using TypeScript).
If you use TypeScript and don't want to use babel, until recently you have to basically use tsx or tsnode . You then have to wrangle a magic set of options in the tsconfig.json to have some popular libraries work.
.NET after 5 has absolute DI madness in ASP.NET and none of it seems documented properly anywhere (or I can't find it) and it seems to change subtly every time they update .NET or ASP.NET.
I ended up resorting to pulling down the entire source code to see what the Startup was doing. C# now has total language and syntactic sugar overload.
I have almost none of these headaches with Python and Go.
> And anyway, RAD isn't about setup time, it's about iteration time.
It is both. I find Python quicker, easier and less headaches that either JS or .NET. I am well versed in C# and JS.
I know less Python than .NET and JS/TS, yet I find it easier.
> I feel you on the lack of Go jobs. It seems like they aren't very well globally distributed...
That is true. I am sure most Go jobs advertised in the UK are in London.
It doesn't solve all the problems at library boundaries, but pyright is fairly new and vastly vastly better than mypy.
With it Python feels about at the type safety level of Typescript - not as good as a language that had types the whole time, but much much better than nothing if enforced with strict rules in CI.
With it Python feels about at the type safety level of Typescript - not as good as a language that had types the whole time, but much much better than nothing if enforced with strict rules in CI.
On the other hand, TS is terrible. The type system is ridiculously complex in order to support all the weird stuff you can do in JS, I frequently get insane error messages with 20+ lines of archaic type gibberish and when I figure out the solution it's usually very clear that the sparse information i managed to glean from reading the error message was nothing but a distraction.
I don't like JS but after having used TS intermittently for a number of years I'm starting to think JS is the better option. At least there I don't get tricked by typed objects being something other than what they claim to be, or waste time trying to declare the right types for some code that would work perfectly without TS.
TS is too much work for too little reward. I'd rather just make simple frontends with as little logic as possible and do the real programming in a real programming language on the backend.
I don't like JS but after having used TS intermittently for a number of years I'm starting to think JS is the better option. At least there I don't get tricked by typed objects being something other than what they claim to be, or waste time trying to declare the right types for some code that would work perfectly without TS.
TS is too much work for too little reward. I'd rather just make simple frontends with as little logic as possible and do the real programming in a real programming language on the backend.
Dunders keep them out of the public namespace on purpose.
Mypy is shit, but Pyright is actually very good so you can write Python with a pretty good static type experience. Almost on par with Typescript.
The problem is you will spend your whole life unsuccessfully trying to get your lazy colleagues to actually use them.
The problem is you will spend your whole life unsuccessfully trying to get your lazy colleagues to actually use them.
> one of the best documented languages
Are we talking about the same Python? Have you seen the Python documentation? There's a reason it ranks so badly on Google.
Also you forgot the abysmal performance and laughably janky tooling (until uv saved us from that clusterfuck anyway).
Are we talking about the same Python? Have you seen the Python documentation? There's a reason it ranks so badly on Google.
Also you forgot the abysmal performance and laughably janky tooling (until uv saved us from that clusterfuck anyway).
Yeah, I would never know it is impossible to write anything larger than 1k LOC in Python if I would not visit HN.
The benefits realized can be mostly attributed to strong type checking.
I'm a rust dev full time. And I agree with everything here. But I also want people to realize it's not "Just Rust" that does this.
In case anyone gets FOMO.
I'm a rust dev full time. And I agree with everything here. But I also want people to realize it's not "Just Rust" that does this.
In case anyone gets FOMO.
Do you know a language other than Rust that has alternative for docs.rs? In JavaScript and Python they never bother to have any documentation or reference, one notable example that gets me frustrated these days is the openai SDK for TypeScript. There is no documentation for it. I have to go look at the source code to figure out what the hell goes on.
> In JavaScript and Python they never bother to have any documentation or reference
Please, main Python libraries have much richer docs than almost anything from Rust ecosystem.
Please, main Python libraries have much richer docs than almost anything from Rust ecosystem.
javadoc.io is similar to (but not as good as) docs.rs for the Java ecosystem. It pulls the JavaDoc out of packages that are published to the Maven Central repository. It doesn't have good discoverability like docs.rs, though, and it's dependent on the publishers actually including the javadoc files.
javadoc.io is similar in the fact that it lists things I guess? It looks worse (objective) but is also depended on a lot less so is just by default going to be a second thought. It’s also not auto-generated like docs.rs like you said.
These days isn't the solution to this just "ask <insert LLM of choice here>" to read the code and write the documentation"?
Yes, you can have Claude Code go through the code and make an .md file with documentation for all the public APIs. I do that for everything that doesn't provide llms.txt.
If you want to not reliably know anything about the code, sure. But if you want to have useful knowledge, using a stochastically unreliable tool isn't going to cut it.
Pythons power is in the REPL. It's good for when you want to do something ad-hoc that's too much for Bash or a graphing calculator. It has a large enough ecosystem that you can make a PoC for basically anything in a day.
It's really, really good for <1000 LoC day projects that you won't be maintaining. (And, if you're writing entirely in the REPL, you probably won't even be saving the code in the first place.)
It's really, really good for <1000 LoC day projects that you won't be maintaining. (And, if you're writing entirely in the REPL, you probably won't even be saving the code in the first place.)
the problem is that when you write enough <1kloc projects, a couple of them are useful enough to stay used in which case you are now maintaining python in prod.
Yes but the alternative is "not having those projects at all" not "having them in a 'better' language"
Of course not, the alternate is writing these projects in a more maintainable language
Or writing them in whatever language gets you going quickly and rewrite the "successful" ones in a more safe language like Rust. Of course write test cases for those ones first and then use LLM help to migrate them, including tests, to a safer language. Problem happens when the velocity of changes is too much and/or there is no appetite for migration - those are a different category of problem.
The ideal scenario is what you are saying but most of the time it boils down to deadline vs familiarity/skill (of the developer and the team) trade-off.
The ideal scenario is what you are saying but most of the time it boils down to deadline vs familiarity/skill (of the developer and the team) trade-off.
I feel like this is exaggerated. If you spent a couple days building a POC in python and found that it was useful then you can spend a couple days re-building it in a better language. You already know what you're making, probably have a decent plan for how to implement it, should be simple and straight forward to replicate it.
It's not exaggerated. You can spend a couple of days rebuilding it in a better language (and I have done that!), but what actually happens is people want new features far more than they want you to rebuild it in a better language. So in most cases it gradually grows and gradually gets more unmanageable and it gradually becomes more difficult to justify a rewrite. There's never a solid point where you have to do a rewrite so it grows and grows until you really really wish that you had but it's also way way too late.
Happens all the time in my experience. It goes so far that big companies like Facebook, Google and Dropbox have all ended up writing their own Python/PHP runtimes or even entirely new languages like Hack and Google's new C++ thing rather than rewrite, because rewrites become impossible very quickly.
That's why - despite people saying language doesn't matter - it is very important to pick the right language from the start (if you can).
Happens all the time in my experience. It goes so far that big companies like Facebook, Google and Dropbox have all ended up writing their own Python/PHP runtimes or even entirely new languages like Hack and Google's new C++ thing rather than rewrite, because rewrites become impossible very quickly.
That's why - despite people saying language doesn't matter - it is very important to pick the right language from the start (if you can).
That's fair. I wasn't really defending the idea of using python for prototyping. Personally I'd just start with C# for pretty much any project and try to do it right from the beginning.
I suppose most of my point was that in the case described one should jump to the rewrite sooner rather than later, to avoid the situation you describe.
I suppose most of my point was that in the case described one should jump to the rewrite sooner rather than later, to avoid the situation you describe.
I don't think that's inevitable, you can just not do that. I've been doing this for 15 years and it hasn't happened to me.
Here is some actual useful advice:
Use a type checker! Pyright can get you like 80% of Rust's type safety.
Use a type checker! Pyright can get you like 80% of Rust's type safety.
I've not tried Pyright, but mypy on any realistic, real-world codebase I've thrown at it emits ~80k errors. It's hard to get started with that.
mypy's output is, AFAICT, also non-deterministic, and doesn't support a programmatic format that I know of. This makes it next to impossible to write a wrapper script to diff the errors to, for example, show only errors introduced by the change one is making.
Relying on my devs to manually trawl through 80k lines of errors for ones they might be adding in is a lost cause.
Our codebase also uses SQLAlchemy extensively, which does not play well with typecheckers. (There is an extension to aid in this, but it regrettably SIGSEGVs.)
Also this took me forever to understand:
mypy's output is, AFAICT, also non-deterministic, and doesn't support a programmatic format that I know of. This makes it next to impossible to write a wrapper script to diff the errors to, for example, show only errors introduced by the change one is making.
Relying on my devs to manually trawl through 80k lines of errors for ones they might be adding in is a lost cause.
Our codebase also uses SQLAlchemy extensively, which does not play well with typecheckers. (There is an extension to aid in this, but it regrettably SIGSEGVs.)
Also this took me forever to understand:
from typing import Dict
JsonValue = str | Dict[str, "JsonValue"]
def foo() -> JsonValue:
x: Dict[str, str] = {"a": "b"}
return x
x: JsonValue = foo()
example.py:7: error: Incompatible return value type (got "dict[str, str]", expected "str | dict[str, JsonValue]") [return-value]Everyone stubs their toe on container invariance once, then figures it out and moves on. It's not unique to Python and developers should understand the nuances of variance.
I don't use mypy so I can't comment on it but at least from what I have seen pyright is deterministic in it's output and get output json.
Regarding the ~80k errors. Yeah, nothing to do here besides slowly grinding away and adding type annotations and fixes until it's resolved.
For the code example pyright gives some hint towards variance but yes it can be confusing.
https://pyright-play.net/?pyrightVersion=1.1.403&code=GYJw9g...
Regarding the ~80k errors. Yeah, nothing to do here besides slowly grinding away and adding type annotations and fixes until it's resolved.
For the code example pyright gives some hint towards variance but yes it can be confusing.
https://pyright-play.net/?pyrightVersion=1.1.403&code=GYJw9g...
I recommend first starting with pyflakes and later ruff on a huge old Python project.
Do file by file.
When done, do typing similarly.
When done, do typing similarly.
I used mypy just fine for a previous job. If you are getting 80k errors, that means you are either starting very late to use the type checker and have done many dubious things before, or you didn't exclude your venv from being type checked by mypy.
> There is an extension to aid in this, but it regrettably SIGSEGVs.
Love this.
Love this.
I don't agree that Python can be saved by a type checker. The language itself is flawed irreversibly, as well as its ecosystem. It's a big big mess. Can't build reliable software in Python.
Is this rage-bait? A language alone doesn't dictate reliability. There are tons of large scale systems out there running on Python. As for the language being, "flawed irreversibly", I'd be curious to hear you expand on that with examples.
All programming languages are Turing complete and you can arque with that. But you reach similar results with varying pre-knowledge and effort. Sometimes it is even impossible. All programs can be bug-free but most are not, if we reverse the argument.
> A language alone doesn't dictate reliability.
Nobody would claim that. But are you trying to say that the language has no effect on reliability? Because that's obviously nonsense.
Language choice has some effect on reliability, and I would say Python's effect is mediocre-to-bad. Depending on if you use Pyright. Not too bad if you do. Pretty awful if you don't.
Nobody would claim that. But are you trying to say that the language has no effect on reliability? Because that's obviously nonsense.
Language choice has some effect on reliability, and I would say Python's effect is mediocre-to-bad. Depending on if you use Pyright. Not too bad if you do. Pretty awful if you don't.
you can and this is a juvenile position. there is reliable software in any language as popular and widespread as Python. every language is flawed
> every language is flawed
But not equally flawed.
https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...
But not equally flawed.
https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac...
It can't be 100% saved, but like the OP said it's 80% saved.
It's not true you can't build reliable software in python. People have. There's proof of it everywhere. Tons of examples of reliable software written in python which is not the safest language.
I think the real thing here is more of a skill issue. You don't know how to build reliable software in a language that doesn't have full type coverage. That's just your lack of ability.
I'm not trying to be insulting here. Just stating the logic:
It's not true you can't build reliable software in python. People have. There's proof of it everywhere. Tons of examples of reliable software written in python which is not the safest language.
I think the real thing here is more of a skill issue. You don't know how to build reliable software in a language that doesn't have full type coverage. That's just your lack of ability.
I'm not trying to be insulting here. Just stating the logic:
A. You claim python can't build reliable software.
B. Reliable Software for python actually exists, therefore your claim is incorrect
C. You therefore must not have experience with building any software with python and must have your hand held and be baby-sitted by rusts type checker.
If you know some secret behind building reliable software in a programming language without types, with nulls, and with runtime exceptions, I'm all ears. I admit that a blanket statement "can't build reliable software" is going overboard, but the intention was to be dramatic, not factually correct. You can probably build reliable software in Python if you write everything from scratch, but I wouldn't want to do that to myself. I would rather use a programming language that has a type system, etc, and a better cultured ecosystem.
I prefer types too.
But I can build reliable software without types as well. Many people can. This isn’t secret stuff that only I can do. There are thousands and thousands of reliable software built on Python, ruby and JavaScript.
But I can build reliable software without types as well. Many people can. This isn’t secret stuff that only I can do. There are thousands and thousands of reliable software built on Python, ruby and JavaScript.
Indeed, I write very reliable Python every day. A lot faster than the Rust straitjacket too.
We had sentry installed so I know exactly how many exceptions were happening, rare to zero. Lots of tests/constraints on the database as well.
That said I like a nice tight straitjacket at other times. Just not every day. ;-).
P.S. Python doesn’t have the billion-dollar-mistake with nulls. You have to purposely set a variable to None.
We had sentry installed so I know exactly how many exceptions were happening, rare to zero. Lots of tests/constraints on the database as well.
That said I like a nice tight straitjacket at other times. Just not every day. ;-).
P.S. Python doesn’t have the billion-dollar-mistake with nulls. You have to purposely set a variable to None.
OP was needlessly combative. But, if I have to write a program that is correct (i.e. does what I want it do to), I'm going to write it in Rust. Not because you cannot write correct programs in Python. But because it's easier to prove it's correct in Rust.
As a solo dev, I find that I start off in Python, but at a certain project size I find it too unwieldy to manage (i.e. make changes without breaking things) and that's when I implement part or all of the project in Rust.
As a solo dev, I find that I start off in Python, but at a certain project size I find it too unwieldy to manage (i.e. make changes without breaking things) and that's when I implement part or all of the project in Rust.
> have to write a program that is correct
Yes, exactly. It doesn’t happen that often, but it does.
And folks have forgotten, not sure why, but Python was always billed as a prototyping language in the “olden tymes.” Or even “executable pseudocode.” At those it excels.
Yes, exactly. It doesn’t happen that often, but it does.
And folks have forgotten, not sure why, but Python was always billed as a prototyping language in the “olden tymes.” Or even “executable pseudocode.” At those it excels.
[deleted]
lol, Instagram is written in Python.
What exactly? I work at Instagram.
I don’t work at Instagram so I can only go off of what I found online: https://www.pythonpool.com/how-instagram-is-using-django-and...
https://python.plainenglish.io/how-instagram-uses-python-sca...
https://python.plainenglish.io/how-instagram-uses-python-sca...
> 80% of Rust's type safety.
Sort of like closing 80% of a submarine's hatches and then diving.
Sort of like closing 80% of a submarine's hatches and then diving.
Very few bugs are life-threatening.
The problem with an unsound type system like TypeScript's is that once a value of an unexpected type has snuck through a soundness hole, it can end up anywhere in the program, even in code that seems fully safe.
(Also, it means that you don't get any performance benefit from static typing your program.)
(Also, it means that you don't get any performance benefit from static typing your program.)
But they decrease productivity. And I seriously think many teams don’t track the time sunk for fixing bugs / defects properly and they overestimate their productivity, especially the initial productivity boost from not having to think about types.
I would say it's more like 50%. Rust benefits not just from static typing but also a much stronger type system with things like enums, pattern matching, marker traits, ownership, mutability, etc. You don't get any of that with Pyright.
(But if you must use Python then definitely use Pyright.)
(But if you must use Python then definitely use Pyright.)
To be fair, you do get enums and pattern matching from base language.
Exactly! I code in Python every day, I haven't done so without a type checker (usually mypy) for years, I don't push a single change without type-checking it first, it catches stupid mistakes and saves me from breaking production all the time.
Sorry, it's not even close to Rust. Or even C# or Java. It can't provide the same "fearless refactoring". It is better than being blind/having to infer everything manually. That's not saying much.
And that's assuming the codebase and all dependencies have correct type annotations.
And that's assuming the codebase and all dependencies have correct type annotations.
What are the major pros and cons of Pyright and Mypy relative to one another?
What language do you recommend instead for the type of small tasks I write python to solve? Needs to have a good image manipulation library, tools for manipulating binary data and converting it to normal types, good list comprehension tools, the ability to easily be a web client or server and a good REPL
If you're willing to put a bunch of up-front effort into learning it first, Haskell. If not, OCaml.
Bun
isnt that just javascript?
It's JavaScript (TypeScript) that ships as a single executable with lots of stuff in it like bundler, compiler, postgres client, etc. I use it for scripting, e.g., seed database, etc.
This is why I like strong, sound static type systems with interesting features.
I’ve had similar experiences working with a large 1m+ SLOC Haskell codebase. It was straightforward to make large refactors because of the type system.
And we weren’t even using fancy things like linear types. Just plain old Haskell with a sprinkling of dependent types in core, critical sections.
I’ve had similar experiences working with a large 1m+ SLOC Haskell codebase. It was straightforward to make large refactors because of the type system.
And we weren’t even using fancy things like linear types. Just plain old Haskell with a sprinkling of dependent types in core, critical sections.
Comparing anything with JS or TS would make it shine. The biggest problem I personally have with Rust is that there are a hundred ways (not literally ) to do one thing, which throws readability out the window, especially when you have developers at different levels of expertise.
Can you elaborate or maybe give some examples about having too many ways to do one thing? I have never heard this complaint about Rust before.
Rust even has tooling (clippy) that warns about unidiomatic code.
Rust even has tooling (clippy) that warns about unidiomatic code.
I would love to see a web app with an interface where I select two programming languages and it shows me a really clean snippet of code in language A and says "Look how terribly hard and unclean this is to achieve in language B". (and then you could reverse to see where B outshines A).
Languages are a collection of tradeoffs so I'm pretty sure you could find examples for every two languages in existence. It also makes these kinds of comparisons ~useless.
Languages are a collection of tradeoffs so I'm pretty sure you could find examples for every two languages in existence. It also makes these kinds of comparisons ~useless.
For one, snippets is exactly where you don't get good language comparisons.
For example, python is AFAIK the lead language to get something done quickly. At least as per AoC leaderboards. It's a horrible language to have in production though (experienced it with 700k+ LOC).
Rust is also ok to do for AoC, but you will (based on stats I saw) need about 2x time to implement. Which in production software is definitely worth it, because of less cost in fixing stupid mistakes, but a code snippet will not show you that.
For example, python is AFAIK the lead language to get something done quickly. At least as per AoC leaderboards. It's a horrible language to have in production though (experienced it with 700k+ LOC).
Rust is also ok to do for AoC, but you will (based on stats I saw) need about 2x time to implement. Which in production software is definitely worth it, because of less cost in fixing stupid mistakes, but a code snippet will not show you that.
If I might tweak your point a bit: Snippets are fine for showing language differences when programming in the small, but not for programming in the large.
https://en.wikipedia.org/wiki/Programming_in_the_large_and_p...
https://en.wikipedia.org/wiki/Programming_in_the_large_and_p...
Rosetta Code is what you're looking for, I believe: https://rosettacode.org/
Actually, these sorts of comparisons are extremely useful, and an argument based on imagining an unknown case that makes the argument work is fallacious.
Rust is one of a very few languages where I can make a total mess in my code by refactoring, have like 100+ compilation errors in multiple modules, think I’m never going to fix it, yet at the end of the day I eventually get everything to compile fine, I run the tests and… they all pass from the first go. All green. Hard to believe but it happened many times to me.
Same. I often have the experience of seeing my app suddenly work again and thinking "wait... I'm done?"
I always thought that the POSIX threads semantics that forces the thread acquiring the lock to be the same thread that releases it, is too strict and not needed. In certain use cases it forces you to redesign the code in more complicated ways.
It isn't too strict. Releasing a pthread_mutex has the semantics of being a release memory barrier, which means that any writes on that thread will be visible by other threads that issue a subsequent acquire memory barrier (e.g. by acquiring the mutex).
If you want this behavior, it's relatively simple to implement your own mutex on top of futex, but no one is going to expect the behavior it provides.
If you want this behavior, it's relatively simple to implement your own mutex on top of futex, but no one is going to expect the behavior it provides.
I used to think that way, but I've learned that there's one good reason for why the API is designed that way: priority inheritance. Priorities are bound to threads, and, when a high priority threads wants to lock a currently occupied mutex, we want to bump the priority of the current holder. And POSIX requirement makes that easy --- the thread who locked the mutex must be the one holding it.
Related: https://man7.org/linux/man-pages/man2/futex.2.html#:~:text=%...
Related: https://man7.org/linux/man-pages/man2/futex.2.html#:~:text=%...
I had to explain this to my students today using XKCD #1987, that although Python is considered a universally "simple" and "easy to use" language, a lot of the complexity in that ecosystem is paid for on the backend.
With Rust, they frontload the complexity, so it's considered to be "hard to learn". But I've got to say, Rust's "complexities" have allowed me to build a taller software tower than I've ever been able to build before in any other language I've used professionally (C/C++/Java/Swift/Javascript/Python).
And that's the thing a lot of people don't get about Rust, because you can only really appreciate it once you've climbed the steep learning curve.
At this point I've gone through several risky and time-consuming (weeks) refactors of a substantial Rust codebase, and every time it's worked out I'm amazed it wasn't the kind of disaster I've experienced refactoring in other languages, where the refactor has to be abandoned because it got so hairy and everyone lost all hope and motivation.
They don't tell you about that kind of pain in the Python tutorial when they talk about how easy it is to not have to type curly braces and have dynamic types everywhere. And you don't really find that pleasure in Rust until you've built enough experience and code to have to do a substantial refactor. So I can understand why the Rust value proposition is dubious for people who are new to the language and programming in general.
[1] https://xkcd.com/1987
With Rust, they frontload the complexity, so it's considered to be "hard to learn". But I've got to say, Rust's "complexities" have allowed me to build a taller software tower than I've ever been able to build before in any other language I've used professionally (C/C++/Java/Swift/Javascript/Python).
And that's the thing a lot of people don't get about Rust, because you can only really appreciate it once you've climbed the steep learning curve.
At this point I've gone through several risky and time-consuming (weeks) refactors of a substantial Rust codebase, and every time it's worked out I'm amazed it wasn't the kind of disaster I've experienced refactoring in other languages, where the refactor has to be abandoned because it got so hairy and everyone lost all hope and motivation.
They don't tell you about that kind of pain in the Python tutorial when they talk about how easy it is to not have to type curly braces and have dynamic types everywhere. And you don't really find that pleasure in Rust until you've built enough experience and code to have to do a substantial refactor. So I can understand why the Rust value proposition is dubious for people who are new to the language and programming in general.
[1] https://xkcd.com/1987
> I had to explain this to my students today using XKCD #1987, that although Python is considered a universally "simple" and "easy to use" language, a lot of the complexity in that ecosystem is paid for on the backend.
No, that's just an unrelated coincidence. Python happens to be a good language with awful tooling, but there are also good languages with good tooling and awful languages with awful tooling.
No, that's just an unrelated coincidence. Python happens to be a good language with awful tooling, but there are also good languages with good tooling and awful languages with awful tooling.
Most of these productivity gains are achievable in any Standard ML influenced type system.
The main difference between Rust and other languages with a Standard ML influenced type system is that Rust has features that can let you get executive sign off for switching languages.
what is the main advantage of Rust over OCaml for most applications in this respect?
Ecosystem. It's much easier to find libraries for Rust.
opam has plenty of libraries, we should not mix quantity with quality.
Also we don't need leftpad like libraries, which is the direction Rust seems to be going when I try some some basic application that has like 50 crate dependencies.
Also we don't need leftpad like libraries, which is the direction Rust seems to be going when I try some some basic application that has like 50 crate dependencies.
Rust is very difficult for most people, so do you think that this advantage outweighs that disadvantage? Is that really the only meaningful advantage if you’re not writing a driver or internet-facing compressor at scale?
Not really, at my job Scala, F#, Swift and Kotlin are possible, and most likely will never do Rust, other than using JavaScript tools written using Rust, just because.
There is nothing in our domain of distributed systems based on SaaS products, mobile OSes, and managed cloud environments, that would profit from a borrow checker.
There is nothing in our domain of distributed systems based on SaaS products, mobile OSes, and managed cloud environments, that would profit from a borrow checker.
The example that the article gives relies on the borrow checker, which is not part of the usual Standard ML type system.
It is called affine type system, and there are ML descendents with it.
You can even go more crazy with linear types, effects, formal proofs or dependent types.
What Rust has achieved, was definitely make these ideas more mainstream.
You can even go more crazy with linear types, effects, formal proofs or dependent types.
What Rust has achieved, was definitely make these ideas more mainstream.
[deleted]
Can the type system catch such things across translation unit boundaries? I know this is a big limit of C like compilers without whole program compilation.
Ultimately the answer is just "Yes". You know how an array of six integers is a different type from an array of three integers even though they're both arrays of integers ? If you're unclear on that it's worth a moment to go refresh, if your only experience is in C it's a deep dive - no trouble it's valuable knowledge.
In Rust lifetimes for references are part of the type, so &'a str and &'b str could be different types, even though they're both string slice references.
Beyond that, Rust tracks two important "thread safety" properties called Sync and Send, and so if your Thing ends up needing to be Send (because another thread gets given this type) but it's not Send, that's a type error just as surely as if it lacked some other needed property needed for whatever you do with the Thing, like it's not totally ordered (Ord) or it can't be turned into an iterator (IntoIterator)
In Rust lifetimes for references are part of the type, so &'a str and &'b str could be different types, even though they're both string slice references.
Beyond that, Rust tracks two important "thread safety" properties called Sync and Send, and so if your Thing ends up needing to be Send (because another thread gets given this type) but it's not Send, that's a type error just as surely as if it lacked some other needed property needed for whatever you do with the Thing, like it's not totally ordered (Ord) or it can't be turned into an iterator (IntoIterator)
On that graph, both curves should go monotonically down, just one faster than the other.
Fearless refactoring is THE reason I rewrote an internal tool at work from Python to Rust. When the code got sufficiently large and a refactor was in order, I suddenly realized how loose everything is semantically tied together. I understood why so many Python developers like writing so many dumb unit tests. They're compensating for the lack of a strong static type system[1].
This is an internal tool that isn't our main product so I don't see any value in spending extra time writing needless long-winded "did the user pass the right thing" tests or getting a static analyzer going so I just chose a language with as little build system/static analyzer/built-in unit testing/separate runtime installation headaches as possible to get things going easier.
That was three years ago and the tool is about 4x more featureful than when it started.
[1]: https://dmerej.info/blog/post/i-dont-need-types/
This is an internal tool that isn't our main product so I don't see any value in spending extra time writing needless long-winded "did the user pass the right thing" tests or getting a static analyzer going so I just chose a language with as little build system/static analyzer/built-in unit testing/separate runtime installation headaches as possible to get things going easier.
That was three years ago and the tool is about 4x more featureful than when it started.
[1]: https://dmerej.info/blog/post/i-dont-need-types/
Refactoring is a huge problem for all dynamic languages. It’s so easy to break things in ways that do not appear until runtime.
They are very productive for first drafts. Then the code tends to “melt” as more people work on it or you do refactors because there is no static type system to catch obvious problems or enforce any order.
They are very productive for first drafts. Then the code tends to “melt” as more people work on it or you do refactors because there is no static type system to catch obvious problems or enforce any order.
I definitely agree with first drafts. To this day I still fire up Python for quick ideas and one-off scripts because it's just so damn convenient. It wasn't until I tried writing larger programs in it where I first felt how brittle it really is.
This boils down to "dev found out that a static typesystem is usefull".
Its always funny when i see these kinds of posts.
Its always funny when i see these kinds of posts.
My intention with the blog was to show that Rust's lifetime tracking and trait system allow you to catch much more complicated issues than just "one type doesn't match another" errors.
That's the main reason why I chose to compare it with TypeScript, that is also a statically typed language, but just can't catch some issues that Rust can.
That's the main reason why I chose to compare it with TypeScript, that is also a statically typed language, but just can't catch some issues that Rust can.
The notion of a type is not fixed, Rust has a more generous conception of what is a type and what its static type system checks.
The bug you showed had nothing to do with typescript (JS) but the browser API. Typescript is not a good languge, but still a way better option than vanilla JS.
I kind of wish Haxe would have taken TypeScripts place as it is simply a better language overall.
I kind of wish Haxe would have taken TypeScripts place as it is simply a better language overall.
[deleted]
> Its always funny when i see these kinds of posts.
What's funny about it?
What's funny about it?
Basically that you list the obvious benefits we knew since the 70s (in a new blogpost).
Its a form of re-discovery, and im happy people "find" the joy of it.
Rust borrows heavily from the other ml's and thats why many like it, not realizing there is decades of research behind the whys.
Its a form of re-discovery, and im happy people "find" the joy of it.
Rust borrows heavily from the other ml's and thats why many like it, not realizing there is decades of research behind the whys.
The Typescript example given is an obvious bug to me even before I knew how the
window redirect thing works. It was an obvious control flow issue
And I find the event loop vrs concurrency via mutexes to be like an apples to oranges comparison. They both do some form of concurrency but not nearly in the same way
Again, Typescript is hardly considered a language. It is just a tool used to keep javascript under some control on large projects. Again, the comparison between rust and Typescript on a language level is not a great match.
As for fearless refactoring, don't get me started. I experienced this the first time I was porting a vanilla js backend to a typescript version. It was awesome. I won't say it works in much the same way as rust does but man, if you ever ported a rest api written in javascript to Typescript - you'd experience a similar effect.
And I find the event loop vrs concurrency via mutexes to be like an apples to oranges comparison. They both do some form of concurrency but not nearly in the same way
Again, Typescript is hardly considered a language. It is just a tool used to keep javascript under some control on large projects. Again, the comparison between rust and Typescript on a language level is not a great match.
As for fearless refactoring, don't get me started. I experienced this the first time I was porting a vanilla js backend to a typescript version. It was awesome. I won't say it works in much the same way as rust does but man, if you ever ported a rest api written in javascript to Typescript - you'd experience a similar effect.
The javascript browser bug has nothing to do with the language.
It’s just a logic bug.
E.g., the code doesn’t match their own English description of the logic: “If yes, redirect to the specific page. If not, go to the dashboard or onboarding page.”
The code is missing the “if not” (probably best expressed using an “else” clause following the if block).
It’s just a logic bug.
E.g., the code doesn’t match their own English description of the logic: “If yes, redirect to the specific page. If not, go to the dashboard or onboarding page.”
The code is missing the “if not” (probably best expressed using an “else” clause following the if block).
I wouldn't say nothing. I mean, we're essentially talking about a global variable that's specified into the language.
window and window.location aren't part of javascript. They are part of the javascript api that standard browsers provide.
It's fair to point out that browser api is confusing. You might not think of setting a property as kicking off an asynchronous operation, especially if it seems to has instantaneous effect at first.
But the basic control flow logic of that code is wrong. Confusion about whether a side-effect from an api call might bail you out from your error is beside the point.
It's fair to point out that browser api is confusing. You might not think of setting a property as kicking off an asynchronous operation, especially if it seems to has instantaneous effect at first.
But the basic control flow logic of that code is wrong. Confusion about whether a side-effect from an api call might bail you out from your error is beside the point.
I'm curious if Rust (WASM through JS interop?) also has access to `window.location`, and if the API has some more safety mechanisms.
web_sys lets you call window.location, which returns a Location, which has href and set_href methods. They do the same thing the native APIs do, as that is their purpose.
Where exactly?
https://tc39.es/ecma262/multipage/
https://tc39.es/ecma262/multipage/
The typescript/javascript example is a little dishonest. Nothing will save you if you don't know how the runtime/environment/domain semantics work.
I love Typescript but I think I disagree with this. The point of the post seems to be that features of the Rust compiler help enforce that you use certain runtime / environment / domain semantics in ways that eliminate common classes of errors. That's never going to prevent all errors, but preventing large groups of common errors so that you only have to manually remember a smaller set of runtime/environment/domain semantics could have some value.
It isn't typescript's fault. Borrow checker won't save you from bugs in your SQL queries that you send to the DBMS. Typescript doesn't care about the browser just like rust doesn't care about SQL
SeaORM and similar crates in Rust will catch some common SQL bugs through the type system.
Typescript also has ORMs.
The problem is not with TypeScript or even JavaScript but an odd Browser API where mutating some random value of an object results in a redirect on the page, but not synchronously.
Even if the language of the browser were Rust, there's nothing about the type system specifically that would have caught this bug (as far as I can tell, anyways. Presumably there's something in the background periodically reading the value of `href` and updating the page accordingly, but since that background job only would have needed read and not write access to the variable, I don't think the borrow checker would have helped here)
The problem is not with TypeScript or even JavaScript but an odd Browser API where mutating some random value of an object results in a redirect on the page, but not synchronously.
Even if the language of the browser were Rust, there's nothing about the type system specifically that would have caught this bug (as far as I can tell, anyways. Presumably there's something in the background periodically reading the value of `href` and updating the page accordingly, but since that background job only would have needed read and not write access to the variable, I don't think the borrow checker would have helped here)
> Setting the value of href navigates to the provided URL [0]
It would have been caught because this API (setters) is impossible with Rust. At best, you'd have a .set_href(String).await, which would stop the thread until the location has been updated and therefore the value stabilized. At worst, you'd have a public .href variable, but because the setter pattern is impossible, you know there must be some process checking and scheduling updates.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Location/hr...
It would have been caught because this API (setters) is impossible with Rust. At best, you'd have a .set_href(String).await, which would stop the thread until the location has been updated and therefore the value stabilized. At worst, you'd have a public .href variable, but because the setter pattern is impossible, you know there must be some process checking and scheduling updates.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Location/hr...
"I have found that Rust's strong safety guarantees give me much more confidence when touching the codebase. With that extra confidence I'm much more willing to refactor even critical parts of the app, which has a very positive effect on my productivity, and long-term maintainability."
That is usually why you have tests for your code. But if you have no tests a programming language with a strict compiler is of course more helpful. But the best is to write tests. Then you can also refactor code with confidence written in "sloppy" programming languages.
That is usually why you have tests for your code. But if you have no tests a programming language with a strict compiler is of course more helpful. But the best is to write tests. Then you can also refactor code with confidence written in "sloppy" programming languages.
Nope, it's better for properties to be statically proven by the compiler where possible, rather than tested with runtime tests.
Tests should be used where you can't prove correctness statically. But it's better if you can.
The ultimate end point of this is formal verification, where you need very few - if any - runtime tests. But formally verifying software is extremely difficult, so you can't usually do that.
Tests should be used where you can't prove correctness statically. But it's better if you can.
The ultimate end point of this is formal verification, where you need very few - if any - runtime tests. But formally verifying software is extremely difficult, so you can't usually do that.
Even formal verification requires tests though, because there may be bugs on the logic proofs.
True. Well usually. In some cases the property you're writing is so simple you wouldn't need any tests, for example in a compression library you just check decompress(compress(x)) == x. If that is proven there's no need for tests.
But yeah usually it's a good idea to have a few tests anyway. You just need fewer tests the more properties you can prove formally.
But yeah usually it's a good idea to have a few tests anyway. You just need fewer tests the more properties you can prove formally.
In my experience a Rust codebase with no tests warrants more confidence than any practical level of testing seen in sloppy programming languages, at least until you get to SQLite-style "10x as much test code as main code" projects. A decent type system lets you reach a given level of confidence at much lower cost than doing the same thing with tests. A decent type system plus a handful of judiciously chosen tests lets you reach a higher level than you would ever achieve with tests alone.
Agree with your point. Writing good tests & utilizing type system properly should help a lot with catching bugs.
But for some reason writing tests always reminds me with xkcd "Standards" (https://xkcd.com/927/). Instead of "fixing standards by create another standard", now it's catching code bug with more code.
At least for type system, it gets maintained by language maintainers, not project maintainers.
But for some reason writing tests always reminds me with xkcd "Standards" (https://xkcd.com/927/). Instead of "fixing standards by create another standard", now it's catching code bug with more code.
At least for type system, it gets maintained by language maintainers, not project maintainers.
And then each time you refactor your code, your work doubled as you now also need to refactor your tests.
If your tests are testing the structure of your code, then this is true. But if you test for functionality/features of your API then you can freely refactor below that layer of abstraction.
How do you encode the locking issue in the type system, it seems magical? Can you just never hold any locks when calling await, is it smart enough to know that this scheduler might move work between threads?
Presumably the author is using tokio which requires the future constructed (e.g the async function) to be Send (either because of the rules of Rust or annotated as Send) since tokio is a work-stealing runtime and any thread might end up executing a given future (or even start executing and then during a pause move it for completion on another thread). std::sync::MutexGuard intentionally isn't annotated with Send because there are platforms that require the acquiring thread be the one to unlock the mutex.
One caveat though - using a normal std Mutex within an async environment is an antipattern and should not be done - you can cause all sorts of issues & I believe even deadlock your entire code. You should be using tokio sync primitives (e.g. tokio Mutex) which can yield to the reactor when it needs to block. Otherwise the thread that's running the future blocks forever waiting for that mutex and that reactor never does anything else which isn't how tokio is designed).
So the compiler is warning about 1 problem, but you also have to know to be careful to know not to call blocking functions in an async function.
One caveat though - using a normal std Mutex within an async environment is an antipattern and should not be done - you can cause all sorts of issues & I believe even deadlock your entire code. You should be using tokio sync primitives (e.g. tokio Mutex) which can yield to the reactor when it needs to block. Otherwise the thread that's running the future blocks forever waiting for that mutex and that reactor never does anything else which isn't how tokio is designed).
So the compiler is warning about 1 problem, but you also have to know to be careful to know not to call blocking functions in an async function.
> using a normal std Mutex within an async environment is an antipattern and should not be done
This is simply not true, and the tokio documentation says as much:
"Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code."
https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#wh...
This is simply not true, and the tokio documentation says as much:
"Contrary to popular belief, it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code."
https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#wh...
I think that’s a dangerous recommendation and ignores the consequence of doing this within a single threaded reactor (your app will hang permanently if the lock is contended) or assumes you won’t have N threads trying to acquire this lock where N is the size of your thread pool which is entirely possible on a heavily accessed server if the core state that needs to be accessed by every request is locked with said mutex.
If you're using a single threaded reactor you don't need a mutex at all; a Rc<RefCell<_>> will do just fine. And if you want other tasks to yield until you're done holding the borrow, the solution is simple: don't await until you're done. https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html...
there are absolutely situations where tokio's mutex and rwlock are useful, but the vast majority of the time you shouldn't need them
there are absolutely situations where tokio's mutex and rwlock are useful, but the vast majority of the time you shouldn't need them
As you know Rc<RefCell> won't work for a data structure that's being accessed by other threads (e.g. spawn_blocking or explicitly accessed threads). Just because you are using the single-threaded reactor does not mean you don't have other threads to access the data.
It seems like you've found a very specific situation where tokio's Mutex is helpful but it is simply not common to be structuring an async rust application with a single threaded reactor and copious uses of spawn blocking. The advice to go for the std Mutex first is generally good
[deleted]
It can be an issue, but only if you have long enough contention periods for the mutex to matter. A Mutex which is only held for short time periouds can work perfectly fine in an async context. And it's only going to cause deadlocks if it would cause deadlocks in a threaded context, since if Mutexes can only be held between yield points then it'll only ever be running tasks that are contending for them.
Imagine if every thread tries to acquire this mutex on every HTTP request. And then you also lock it in a spawn_blocking. On a heavily contended lock, all the reactor threads will end up stuck waiting for the spawn_blocking to finish and the service will appear hung since even requests that don’t even need that lock can’t get processed. And if spawn_blocking is doing synchronous network I/O or reading a file from a hung NFS mount, you’re completely hosed.
You would be in a similarly bad situation if such a lock was async as well. You want to keep locks as short as possible, regardless, and a hung task with a lock is generally going to propagate issues throughout the system until it's dealt with.
If you have an async lock that can be held across await points, your motivation to spawn_block decreases. Additionally, even though the long running lock would be a problem, APIs that aren't taking that lock continue to work vs the entire HTTP service being hung which is a huge difference (e.g. health monitoring would time out making the service seem unresponsive vs 1 highly contended task just waiting on a lock).
>e.g. health monitoring would time out making the service seem unresponsive vs 1 highly contended task just waiting on a lock
If anything that's a disadvantage. You want your health monitoring to be the canary, not something that keeps on trucking even if the system is no longer doing useful work. (See the classic safety critical software fail of 'I need a watchdog... I'll just feed it regularly in an isolated task')
If anything that's a disadvantage. You want your health monitoring to be the canary, not something that keeps on trucking even if the system is no longer doing useful work. (See the classic safety critical software fail of 'I need a watchdog... I'll just feed it regularly in an isolated task')
I disagree and hope I can convince you. You're assuming that any request has an equal probability of causing this problem so it's kind of OK if the server deadlocks under load so that the failing health check triggers a restart by whatever is watching it. However, let's say you have three API endpoints:
Or do you want the web server responding healthily & rely on metrics and alerts to let you know that /may_deadlock_server is taking a long time to handle requests / impacting performance? Your health monitoring is an absolute last step for automatically mitigating an issue but it'll only help if the bug is some state stuck in a transient state - if it'll restart into the same conditions leading to the starvation then you're just going to be in an infinite reboot loop which is worse.
Healthz is not an alternative to metrics and alerting - it's a last stopgap measure to try to automatically get out of a bad situation. But it can also cause a worse problem if the situation is outside of the state of the service - so generally you want the service to remain available if a reboot wouldn't fix the problem.
/healthz
/very_common_operation
/may_deadlock_server
Or do you want the web server responding healthily & rely on metrics and alerts to let you know that /may_deadlock_server is taking a long time to handle requests / impacting performance? Your health monitoring is an absolute last step for automatically mitigating an issue but it'll only help if the bug is some state stuck in a transient state - if it'll restart into the same conditions leading to the starvation then you're just going to be in an infinite reboot loop which is worse.
Healthz is not an alternative to metrics and alerting - it's a last stopgap measure to try to automatically get out of a bad situation. But it can also cause a worse problem if the situation is outside of the state of the service - so generally you want the service to remain available if a reboot wouldn't fix the problem.
> One caveat though - using a normal std Mutex within an async environment is an antipattern and should not be done - you can cause all sorts of issues & I believe even deadlock your entire code.
True. I used std::mutex with tokio and after a few days my API would not respond unless I restarted the container. I was under the impression that if it compiles, it's gonna just work (fearless concurrency) which is usually the case.
True. I used std::mutex with tokio and after a few days my API would not respond unless I restarted the container. I was under the impression that if it compiles, it's gonna just work (fearless concurrency) which is usually the case.
It sounds like you have a deadlock somewhere in your code and it's unlikely that the choice of Mutex really fixed that
Or you do something super expensive while holding the mutex.
Or your server is heavily contended enough that all worker threads are blocked on this mutex and no reactor can make forward progress.
Or your server is heavily contended enough that all worker threads are blocked on this mutex and no reactor can make forward progress.
[deleted]
Using a Tokio mutex is even more of an antipattern :) come to my RustConf talk about async cancellation next week to find out why!
Most people on this forum are not attending RustConf. It might be helpful to post at least the abstract of your idea.
The big thing is that futures are passive, so any future can be cancelled at any await point by dropping it or not polling it any more. So if you have a situation like this, which in my experience is a very common way to use mutexes:
let guard = mutex.lock().await;
// guard.data is Option<T>, Some to begin with
let data = guard.data.take(); // guard.data is now None
let new_data = process_data(data).await;
guard.data = Some(new_data); // guard.data is Some again
I'm not sure this introduces any new failure though:
let data = mutex.lock().take();
let new_data = process_data(data).await;
*mutex.lock() = Some(new_data);
True! This is the case with std mutexes as well. But holding a std MutexGuard across an await point makes the future not Send, and therefore not typically spawnable on a Tokio runtime [1]. This isn't really an intended design decision, though, as far as I can tell -- just one that worked out to avoid this footgun.
Tokio MutexGuards are Send, unfortunately, so they are really prone to cancellation bugs.
(There's a related discussion about panic-based cancellations and mutex poisoning, which std's mutex has but Tokio's doesn't either.)
[1] spawn_local does exist, though I guess most people don't use it.
Tokio MutexGuards are Send, unfortunately, so they are really prone to cancellation bugs.
(There's a related discussion about panic-based cancellations and mutex poisoning, which std's mutex has but Tokio's doesn't either.)
[1] spawn_local does exist, though I guess most people don't use it.
You argument then is that the requirement to acquire the lock multiple times makes it more likely you'll think about cancellation & keeping it in a valid interim state? Otherwise I'm not sure how MutexGuards being send really makes it any more or less prone to cancellation bugs.
Right, in general a lot of uses of mutexes are to temporarily violate invariants that are otherwise upheld while the mutex is released, something that can usually be reasoned out locally. Reasoning about cancellation at an await point is inherently non-local and so is much harder to do. (And Rust is all about scaling up local reasoning to global correctness, so async cancellation feels like a knife in the back to many practitioners.)
The generally recommended alternative is message passing/channels/"actor model" where there's a single owner of data which ensures cancellation doesn't occur -- or, at least that if cancellation happens the corresponding invalid state is torn down as well. But that has its own pitfalls, such as starvation.
This is all very unsatisfying, unfortunately.
The generally recommended alternative is message passing/channels/"actor model" where there's a single owner of data which ensures cancellation doesn't occur -- or, at least that if cancellation happens the corresponding invalid state is torn down as well. But that has its own pitfalls, such as starvation.
This is all very unsatisfying, unfortunately.
I realize now that you were proposing unlocking and relocking the mutex several times. Generally, if someone unlocks a mutex in the middle, they're already thinking about races with other callers (even if the code isn't cancelled in between).
You can definitely argue that developers should think about await points the same way they think about letting go of the mutex entirely, in case cancellation happens. Are mutexes conducive to that kind of thinking? Practically, I've found this to be very easy to get wrong.
You can definitely argue that developers should think about await points the same way they think about letting go of the mutex entirely, in case cancellation happens. Are mutexes conducive to that kind of thinking? Practically, I've found this to be very easy to get wrong.
Same would be true for any resource that needs cleaned up, right? Referring to stop-polling-future as canceling is probably not good nomenclature. Typically canceling some work requires cleanup, if only to be graceful let alone properly releasing resources.
Yes, this is true of any resource. But Tokio mutexes, being shared mutable state, are inherently likely to run into bugs in production.
In the Rust community, cancellation is pretty well-established nomenclature for this.
Hopefully the video of my talk will be up soon after RustConf, and I'll make a text version of it as well for people that prefer reading to watching.
In the Rust community, cancellation is pretty well-established nomenclature for this.
Hopefully the video of my talk will be up soon after RustConf, and I'll make a text version of it as well for people that prefer reading to watching.
Thank you, I look forward to watching your presentation.
Thank you! It seems so simple
in hindsight to have a type that means "can be moved to another thread safely." But the fact that using a Mutex in your function changes the "type" is really novel. It becoming Send once the lock is released before await is just fantastic.
The way that this fully works together is:
- The return type of Mutex::lock() is a MutexGuard, which is a smart pointer type that 1) implements Deref so it can be dereferenced to access the underlying data, 2) implements Drop to unlock the mutex when the guard goes out of scope, and 3) implements !Send so the compiler knows it is unsafe to send between threads: https://doc.rust-lang.org/std/sync/struct.MutexGuard.html
- Rust's implementation of async/await works by transforming an async function into a state machine object implementing the Future trait. The compiler generates an enum that stores the current state of the state machine and all the local variables that need to live across yield points, with a poll function that (synchronously) advances the coroutine to the next yield point: https://doc.rust-lang.org/std/future/trait.Future.html
- In Rust, a composite type like a struct or enum automatically implements Send if all of its members implement Send.
- An async runtime that can move tasks between threads requires task futures to implement Send.
So, in the example here: because the author held a lock across an await point, the compiler must store the MutexGuard smart pointer as a field of the Future state machine object. Since MutexGuard is !Send, the future also is !Send, which means it cannot be used with an async runtime that moves tasks between threads.
If the author releases the lock (i.e. drops the lock guard) before awaiting, then the guard does not live across yield points and thus does not need to be persisted as part of the state machine object -- it will be created and destroyed entirely within the span of one call to Future::poll(). Thus, the future object can be Send, meaning the task can be migrated between threads.
- The return type of Mutex::lock() is a MutexGuard, which is a smart pointer type that 1) implements Deref so it can be dereferenced to access the underlying data, 2) implements Drop to unlock the mutex when the guard goes out of scope, and 3) implements !Send so the compiler knows it is unsafe to send between threads: https://doc.rust-lang.org/std/sync/struct.MutexGuard.html
- Rust's implementation of async/await works by transforming an async function into a state machine object implementing the Future trait. The compiler generates an enum that stores the current state of the state machine and all the local variables that need to live across yield points, with a poll function that (synchronously) advances the coroutine to the next yield point: https://doc.rust-lang.org/std/future/trait.Future.html
- In Rust, a composite type like a struct or enum automatically implements Send if all of its members implement Send.
- An async runtime that can move tasks between threads requires task futures to implement Send.
So, in the example here: because the author held a lock across an await point, the compiler must store the MutexGuard smart pointer as a field of the Future state machine object. Since MutexGuard is !Send, the future also is !Send, which means it cannot be used with an async runtime that moves tasks between threads.
If the author releases the lock (i.e. drops the lock guard) before awaiting, then the guard does not live across yield points and thus does not need to be persisted as part of the state machine object -- it will be created and destroyed entirely within the span of one call to Future::poll(). Thus, the future object can be Send, meaning the task can be migrated between threads.
Rust's marker traits (Send, Sync, etc.) + RAII is really what makes it so magical to me.
original poster was 'lucky' that he was using a work stealing engine. if the engine was not moving tasks between threads then i think the compiler would have been happy and he could have had the fun of debugging what happens when the same thread tries to lock the same mutex twice. the rust compiler won't save you from this kind of bug.
> The exact behavior on locking a mutex in the thread which already holds the lock is left unspecified. However, this function will not return on the second call (it might panic or deadlock, for example).
> The exact behavior on locking a mutex in the thread which already holds the lock is left unspecified. However, this function will not return on the second call (it might panic or deadlock, for example).
Rust uses the traits “Send” and “Sync” to encode this information, there is a lot of special tooling in the compiler around these.
A type is “Send” if it can be moved from one thread to another, it is “Sync” if it can be simultaneously accessed from multiple threads.
These traits are automatically applied whenever the compiler knows it is safe to do so. In cases where automatic application is not possible, the developer can explicitly declare a type to have these traits, but doing so is unsafe (requires the ‘unsafe’ keyword and everything that entails).
You can read more at rustinomicon, if you are interested: https://doc.rust-lang.org/nomicon/send-and-sync.html
A type is “Send” if it can be moved from one thread to another, it is “Sync” if it can be simultaneously accessed from multiple threads.
These traits are automatically applied whenever the compiler knows it is safe to do so. In cases where automatic application is not possible, the developer can explicitly declare a type to have these traits, but doing so is unsafe (requires the ‘unsafe’ keyword and everything that entails).
You can read more at rustinomicon, if you are interested: https://doc.rust-lang.org/nomicon/send-and-sync.html
Yes Rust has ways of verifying single access to locks through the borrow checker and lifetimes.
Well yes but this seems
more complicated. If the code was executed on a single thread it would be correct. The compiler somehow knows that await might move the work to another thread in which the code would still be correct if it weren't for the pesky undefined behavior. At all points it seems like it would be single access and yet it catches this.
The compiler doesn't know anything about threads.
The compiler knows the Future doesn't implement the Send trait because MutexGuard is not Send and it crosses await points.
Then, tokio the aysnc runtime requires that futures that it runs are Send because it can move them to another thread.
This is how Rust safety works. The internals of std, tokio and other low level libraries are unsafe but they expose interfaces that are impossible to misuse.
The compiler knows the Future doesn't implement the Send trait because MutexGuard is not Send and it crosses await points.
Then, tokio the aysnc runtime requires that futures that it runs are Send because it can move them to another thread.
This is how Rust safety works. The internals of std, tokio and other low level libraries are unsafe but they expose interfaces that are impossible to misuse.
An async function call returns a future which is an object holding the state of the async computation. Multithreaded runtimes like tokio require this future to be `Send`, which means it can be moved from one thread to another. The future generated by the compiler is not Send if there is a local variable crossing an await boundary that is not `Send`.
That comes from the where the tokio task is spawned annotating the future with send.
https://docs.rs/tokio/latest/tokio/task/fn.spawn.html
If you want to run everything on the same thread then localset enables that. See how the spawn function does not include the send bound.
https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html
https://docs.rs/tokio/latest/tokio/task/fn.spawn.html
If you want to run everything on the same thread then localset enables that. See how the spawn function does not include the send bound.
https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html
More the latter. The lock guard is not `Send`, so holding it across the await point makes the `impl Future` returned by the async function also not `Send`. Therefore it can't be passed to a scheduler which does work stealing, since that scheduler is typed to require futures to be `Send`.
Yes, if you use a scheduler that doesn't move work between threads, it will not require the task to be Send, and the example code would compile.
Rust can use that type information and lifetimes to figure out when it's safe and when not.
Rust can use that type information and lifetimes to figure out when it's safe and when not.
That same graph applies to Haskell. You could also exchange the x-axis with
- number of different projects you work on
- time since you last worked on the project
- number of different people working on the project
without the lines changing much.
- number of different projects you work on
- time since you last worked on the project
- number of different people working on the project
without the lines changing much.
I agree with the premise of more sophisticated compilers give you a productivity boost. But compiling with cargo can be very slow, and having a strong workstation can be worth it.
In my experience, people tend to be more annoyed by the time spent writing code and overcoming the obstacles that are not "solving the problems" but will simply zen out the hours spent debugging, refactoring and testing manually with a meditation podcast.
This post mirrors my experience 100%. The effect is even stronger when there are multiple people involved on a project, or when you're maintaining a project that you didn't start. There, the benefits of static typing and domain modelling with ADTs become essential. Take take GHC - a haskell project, not a rust one, but it's been under active development by many different people since 1990 and is still going strong. Is there any doubt that the guarantees provided by Haskell's type system were beneficial to making this possible? Not to say that it's strictly necessary – the linux kernel is an even more impressive project and it's in C – but something that is not necessary for success can still increase your odds of success.
You can ask any professional python programmer how much time they've spent trying to figure out the methods that are callable on the object returned by some pytorch function, and they will all tell you it's a challenge that occurs at least weekly. You can ask any C++ programmer how much time they've spent debugging segfaults. You can ask any java programmer how much time they've spent debugging null pointer exceptions. These are all common problems that waste an incredible amount of time, that simply do not occur to anywhere close to the same extent in Rust.
It's true that you can get some of these benefits by writing tests. But would tests have prevented the issue that OP mentioned in his post, where acquiring a mutex from one thread and releasing it from another is undefined? It's highly doubtful, unless you have some kind of intensive fuzz-testing infrastructure that everyone talks about and no one seems to actually have. And what is more time-efficient: setting up that infrastructure, running it, seeing that it detects undefined behavior at the point of the mutex being released, and realizing that it happened because the mutex was sent to a different thread? Or simply getting a compile error the moment you write the code that says "hey pal, mutex guards can't be moved to a different thread". Plus, everyone who's worked on a codebase with a lot of tests can tell you that you sometimes end up spending more time fixing tests than you do actually writing code. For whatever reason, I spend much less time fixing types than fixing tests.
There is a compounding benefit as well. When you can refactor easily (and unit tests often do not make refactoring much easier...), you can iterate on your code's architecture until you find one that meshes naturally with your domain. And when your requirements change and your domain evolves, you can refactor again. If refactoring is too expensive to attempt, your architecture will become more and more out-of-sync with your domain until your codebase is unmaintainable spaghetti. If you imagine a simple model where every new requirement either forces you into refactoring your code or spaghettifying your code, and assume that each instance of spaghettification induces a 1% dev speed slowdown, you can see that these refactors become basically essential. Because 100 new requirements in the future, the spaghetti coder will be operating at 36% the productivity of the counterfactual person who did all the refactors. Seen this way, it's clear that you have to do the refactors, and then a major component of productivity is whether you can do them quickly. An area where it's widely agreed rust excels at.
There are plenty of places we can look at Rust and find ourselves wanting more. But that doesn't mean we shouldn't be proud of what Rust has accomplished. It has finally brought many of the innovations of ML and Haskell to the masses, and innovated new type-system features on top of that, leading to a very productive and pleasantly-designed language.
(I also left this comment on reddit, and am copying it here.)
You can ask any professional python programmer how much time they've spent trying to figure out the methods that are callable on the object returned by some pytorch function, and they will all tell you it's a challenge that occurs at least weekly. You can ask any C++ programmer how much time they've spent debugging segfaults. You can ask any java programmer how much time they've spent debugging null pointer exceptions. These are all common problems that waste an incredible amount of time, that simply do not occur to anywhere close to the same extent in Rust.
It's true that you can get some of these benefits by writing tests. But would tests have prevented the issue that OP mentioned in his post, where acquiring a mutex from one thread and releasing it from another is undefined? It's highly doubtful, unless you have some kind of intensive fuzz-testing infrastructure that everyone talks about and no one seems to actually have. And what is more time-efficient: setting up that infrastructure, running it, seeing that it detects undefined behavior at the point of the mutex being released, and realizing that it happened because the mutex was sent to a different thread? Or simply getting a compile error the moment you write the code that says "hey pal, mutex guards can't be moved to a different thread". Plus, everyone who's worked on a codebase with a lot of tests can tell you that you sometimes end up spending more time fixing tests than you do actually writing code. For whatever reason, I spend much less time fixing types than fixing tests.
There is a compounding benefit as well. When you can refactor easily (and unit tests often do not make refactoring much easier...), you can iterate on your code's architecture until you find one that meshes naturally with your domain. And when your requirements change and your domain evolves, you can refactor again. If refactoring is too expensive to attempt, your architecture will become more and more out-of-sync with your domain until your codebase is unmaintainable spaghetti. If you imagine a simple model where every new requirement either forces you into refactoring your code or spaghettifying your code, and assume that each instance of spaghettification induces a 1% dev speed slowdown, you can see that these refactors become basically essential. Because 100 new requirements in the future, the spaghetti coder will be operating at 36% the productivity of the counterfactual person who did all the refactors. Seen this way, it's clear that you have to do the refactors, and then a major component of productivity is whether you can do them quickly. An area where it's widely agreed rust excels at.
There are plenty of places we can look at Rust and find ourselves wanting more. But that doesn't mean we shouldn't be proud of what Rust has accomplished. It has finally brought many of the innovations of ML and Haskell to the masses, and innovated new type-system features on top of that, leading to a very productive and pleasantly-designed language.
(I also left this comment on reddit, and am copying it here.)
> I have found that Rust's strong safety guarantees give me much more confidence when touching the codebase. With that extra confidence I'm much more willing to refactor even critical parts of the app, which has a very positive effect on my productivity, and long-term maintainability.
That's great, but the graph at the top shows your productivity more than doubling as the size of the project increases, which seems very dubious. Perhaps this is just intended as visual hyperbole, but it triggers my BS detector.
That's great, but the graph at the top shows your productivity more than doubling as the size of the project increases, which seems very dubious. Perhaps this is just intended as visual hyperbole, but it triggers my BS detector.
100% agree, in Rust things usually just work out on the first try!
Time spent debugging is halved and you can focus on the actual product
Time spent debugging is halved and you can focus on the actual product
Its great that the difficulty of rust actually helps refactor large codebases.
[deleted]
The Rust example that you point out might not trigger compile time warnings in other languages, but most OS mutexes (certainly the ones in Windows and Linux) will complain if you release them on a different thread than you acquired them.
You've misunderstood somehow. The point is that Rust detects the mistake at compile time so you don't get to those runtime errors (which might be very rare or context-dependent).
Using sync locks in an async environment is a code smell, so the Rust code is bad right off the bat. Just stick with async locks and take the tiny performance hit unless you know exactly what you're doing.
If I remember correctly tokio Mutex docs mentions you should use std Mutex unless you are holding the lock across an await
[deleted]
Which is exactly what happens here!
That section looks like a cut out version of a pseudo code more than actual code.
He could have mem::dropped the lock 50 lines before the await point
He could have mem::dropped the lock 50 lines before the await point
I didn't need to hold the lock across the .await point and in that case the official docs recommend a regular lock.
Or you could use Clojure with the immutable data structures where you don't need to lock a mutex when accessing a data structure concurrently.
The graph has no units or scale. What is the project size at the crossover point? The article says "certain size" which is unclear.
Come on, the author is comparing Rust to Typescript, Zig and Python, and then concludes that Rust becomes more productive in larger codebases compared to 'some other language'?
Could it be that those 3 languages were not really designed with large (backend) codebases in mind?
To do a fair analysis the author should have compared with a language like Java, Scala or C#.
About the article itself: the part of wrapping a structure in a mutex because it is accessed concurrently is a bit of a red flag. If you are really working in large codebases, you'd like to avoid having to do that: you'd much rather encapsulate that structure in a service and make sure all access to the structure is queued. Much simpler and less chance for nasty deadlocks.
About the article itself: the part of wrapping a structure in a mutex because it is accessed concurrently is a bit of a red flag. If you are really working in large codebases, you'd like to avoid having to do that: you'd much rather encapsulate that structure in a service and make sure all access to the structure is queued. Much simpler and less chance for nasty deadlocks.
> To do a fair analysis the author should have compared with a language like Java, Scala or C#.
Wouldn't that be unfair to them? They still use null or Nullable. They don't have ADTs, their thread-safe invariant is maintained by docs, etc.
Wouldn't that be unfair to them? They still use null or Nullable. They don't have ADTs, their thread-safe invariant is maintained by docs, etc.
Maybe. But at least these languages were meant for large applications so the outcome of the comparison would be more meaningful.
Apart from that, Scala uses the Option type instead of null, and it has ADT's; And I dont know about C# but in Java and Scala using low level mutexes is considered a code smell, the standard libraries provide higher level concurrent data structures.
On top of that, Scala provides several widely used IO frameworks that make dealing with concurrency and side effect much more simple and less error-prone, it would win the comparison with Rust here.
Apart from that, Scala uses the Option type instead of null, and it has ADT's; And I dont know about C# but in Java and Scala using low level mutexes is considered a code smell, the standard libraries provide higher level concurrent data structures.
On top of that, Scala provides several widely used IO frameworks that make dealing with concurrency and side effect much more simple and less error-prone, it would win the comparison with Rust here.
> On top of that, Scala provides several widely used ...
With Scala is less what you miss, and more what you have.
- Custom operators. Those are great for DSLs and rendering your code to look like utter gibberish, and confuse IDEs.
- SBT. Shudder.
- Scala 2 codebases.
With Scala is less what you miss, and more what you have.
- Custom operators. Those are great for DSLs and rendering your code to look like utter gibberish, and confuse IDEs.
- SBT. Shudder.
- Scala 2 codebases.
Your first 2 are good points. Your last point is of course not relevant when you're considering which language to pick for your new enterprise application.
Anyways, IMO it would have been much more interesting and useful to compare Rust with Scala/Java/C#, whatever the outcome of the comparison would be.
Anyways, IMO it would have been much more interesting and useful to compare Rust with Scala/Java/C#, whatever the outcome of the comparison would be.
> Your last point is of course not relevant when you're considering which language to pick for your new enterprise application.
Sure I might be writing a new app, but what if some dependency is Scala 2.12-?
As for your latter point. I still think Rust would be more productive than all listed. I would expect Scala might give Rust the biggest run for its money. C# could probably be closest to Rust perf wise. Or not. Depends on the workload.
Sure I might be writing a new app, but what if some dependency is Scala 2.12-?
As for your latter point. I still think Rust would be more productive than all listed. I would expect Scala might give Rust the biggest run for its money. C# could probably be closest to Rust perf wise. Or not. Depends on the workload.
Java and Scala certainly have ADTs, while Scala and C# have nullable types support.
Ok, I should have been more specific. By ADT I meant sum types, or, to be even more exact, discriminated union. Everyone and their mother has product types.
Java doesn't have a discriminated union for sure (and C# as of 8.0). It does have a `|` operator that can cast two objects to the nearest common ancestor.
Having nullable support is the issue. I've played around with it in C#. Nullables are horrible. And I say this as someone who was formerly in Option<T> is horrible.
You can easily cause type confusion, and if the number of times a non-nullable has been nullable (or at least has appeared as that in the debugger) was greater than zero. To be fair there was reflection and code generation involved.
Java doesn't have a discriminated union for sure (and C# as of 8.0). It does have a `|` operator that can cast two objects to the nearest common ancestor.
Having nullable support is the issue. I've played around with it in C#. Nullables are horrible. And I say this as someone who was formerly in Option<T> is horrible.
You can easily cause type confusion, and if the number of times a non-nullable has been nullable (or at least has appeared as that in the debugger) was greater than zero. To be fair there was reflection and code generation involved.
I advise you to update your language knowledge to Java 24, C# 13, Scala 3.
From another comment of mine,
From another comment of mine,
type Exp =
UnMinus of Exp
| Plus of Exp * Exp
| Minus of Exp * Exp
| Times of Exp * Exp
| Divides of Exp * Exp
| Power of Exp * Exp
| Real of float
| Var of string
| FunCall of string * Exp
| Fix of string * Exp
;;
public sealed interface Exp permits UnMinus, Plus, Minus, Times, Divides, Power, Real, Var, FunCall, Fix {}
public record UnMinus(Exp exp) implements Exp {}
public record Plus(Exp left, Exp right) implements Exp {}
public record Minus(Exp left, Exp right) implements Exp {}
public record Times(Exp left, Exp right) implements Exp {}
public record Divides(Exp left, Exp right) implements Exp {}
public record Power(Exp base, Exp exponent) implements Exp {}
public record Real(double value) implements Exp {}
public record Var(String name) implements Exp {}
public record FunCall(String functionName, Exp argument) implements Exp {}
public record Fix(String name, Exp argument) implements Exp {}
public class Evaluator {
public double eval(Exp exp) {
return switch (exp) {
case UnMinus u -> -eval(u.exp());
case Plus p -> eval(p.left()) + eval(p.right());
case Minus m -> eval(m.left()) - eval(m.right());
case Times t -> eval(t.left()) * eval(t.right());
case Divides d -> eval(d.left()) / eval(d.right());
case Power p -> Math.pow(eval(p.base()), eval(p.exponent()));
case Real r -> r.value();
case Var v -> context.valueOf(v.name);
case FunCall f -> eval(funcTable.get(f.functionName), f.argument);
case Fix fx -> eval(context.valueOf(v.name), f.argument);
};
}
}> I advise you to update your language knowledge to Java 24, C# 13, Scala 3.
I'll update it when I need it :P I'm pretty sure I'll never need Scala 3.
> Into the Java ADTs that you say Java doesn't have for sure
That still seems like casting to a common object + a bunch of instanceof. But I guess if it looks like a duck and walks like a duck.
> C #13
Wait. You mentioned C# has ADTs via sealed classes IIUC. Why the hell do they have a https://github.com/dotnet/csharplang/issues/8928 ticket for discriminated unions then?
It implies that there are some differences between sealed interfaces and discriminated unions. Perhaps how they handle value types (structs and ref structs).
I'll update it when I need it :P I'm pretty sure I'll never need Scala 3.
> Into the Java ADTs that you say Java doesn't have for sure
That still seems like casting to a common object + a bunch of instanceof. But I guess if it looks like a duck and walks like a duck.
> C #13
Wait. You mentioned C# has ADTs via sealed classes IIUC. Why the hell do they have a https://github.com/dotnet/csharplang/issues/8928 ticket for discriminated unions then?
It implies that there are some differences between sealed interfaces and discriminated unions. Perhaps how they handle value types (structs and ref structs).
In no such way I mentioned C# has ADTs,
> Java and Scala certainly have ADTs, while Scala and C# have nullable types support.
> Java and Scala certainly have ADTs, while Scala and C# have nullable types support.
Then why did you tell me to update my knowledge of C#? It wasn't wrong for the discussion at hand.
Also, you failed to mention that the generics ADT in Java is still abysmal (it's relevant, because the topic started as boosting productivity in Java with ADT, I don't find ClassCastException as really boosting anything outside my blood pressure):
Also, you failed to mention that the generics ADT in Java is still abysmal (it's relevant, because the topic started as boosting productivity in Java with ADT, I don't find ClassCastException as really boosting anything outside my blood pressure):
sealed interface Result<T, E> permits Ok, Error { }
record Error<E>(E error) implements Result<Object, E> {}
record Ok<T>(T value) implements Result<T, Object> {}
//public <T, E> Object eval(Result<T, E> exp) {
// return switch (exp) {
// case Error<E> error -> error.error;
// case Ok<T> ok -> ok.value;
// };
//}
public <T, E> Object eval(Result<T, E> exp) {
return switch (exp) {
case Error error -> (E) error.error;
case Ok ok -> (T) ok.value;
};
}
Yeah, Java's generics still kind of suck. There's a rumor after project Valhalla, Java language maintainers might add reified generics in the future. However, I think the current state of Java ADT & generic isn't that bad for most purposes.
Though due to its nullable-by-default type system and backward compatibility, there's a decent amount of footguns if you're trying to mix Java's FP & ADT with code that utilizes nulls.
About your code example, you could just do something like this to avoid explicit casting
Though due to its nullable-by-default type system and backward compatibility, there's a decent amount of footguns if you're trying to mix Java's FP & ADT with code that utilizes nulls.
About your code example, you could just do something like this to avoid explicit casting
sealed interface Result<T,E> {
record Ok<T,E>(T value) implements Result<T,E> {}
record Error<T,E>(E error) implements Result<T,E> {}
public static <T,E> Object eval(Result<T,E> res) {
if (res instanceof Error<T,E>(E e)) // Rust's if let
System.out.println(e);
return switch (res) {
case Ok(T v) -> v;
case Error(E e) -> e;
};
}
}
Because your English reading comprehension missed the fact I was talking about the nullability improvements.
Given the expert level, you are certainly aware that most ML languages don't have reified polymorphism on their implementations, right?
Given the expert level, you are certainly aware that most ML languages don't have reified polymorphism on their implementations, right?
> Because your English reading comprehension missed the fact I was talking about the nullability improvements.
Tank you :P Never claimed to be native English speaker.
Were there any meaningful changes in nullability semantics between C# 8.0 and C# 14.0? The issue I encountered was related to a complex game engine doing some runtime reflection, dependency injection, code gen and so forth.
I also never claimed to be ML expert. But them being reified or not, doesn't change my point that ADT in Java much like generics look like a design afterthought.
Tank you :P Never claimed to be native English speaker.
Were there any meaningful changes in nullability semantics between C# 8.0 and C# 14.0? The issue I encountered was related to a complex game engine doing some runtime reflection, dependency injection, code gen and so forth.
I also never claimed to be ML expert. But them being reified or not, doesn't change my point that ADT in Java much like generics look like a design afterthought.
What’s remarkable is that (a) I have very little Rust experience overall (mostly a Python programmer), (b) very little virtio experience, and (c) essentially no experience working with any of the libraries involved. Yet, I pulled off the refactor inside of a week, because by the time the project actually compiled, it worked perfectly (with one minor Drop-related bug that was easily found and fixed).
This was aided by libraries that went out of their way to make sure you couldn’t hold them wrong, and it shows.