My favorite Rust function(blog.jabid.in) |
My favorite Rust function(blog.jabid.in) |
`Inductive False := .`
i.e., `False` has no constructors and hence is an empty type.
Anyway, this means that for any type `A`, you can construct a function of type `False -> A` because you just do this:
`fun (x : False) => match x with end.`
Since `False` has no constructors, a match statement on a value of type `False` has no cases to match on, and you're done. (Coq's type system requires a case for each constructor of the type of the thing being matched on.) This is why, if you assume something that is false, you can prove anything. :)
Isn't it really only there in case someone needs to "hook into" the drop functionality before the variable is dropped? Please correct me if I'm wrong.
EDIT: Minor editing to clarify meaning.
It's talking instead about std::mem::drop, a standard library function that drops a value before it would ordinarily go out of scope.
One cool thing about Drop (and some other cool stuff, like MaybeUninit) is that it makes doing things like allocating/freeing in place just like any other Rust code. There may be some unsafe involved, but the syntax is consistent. Whereas in C++ seeing placement new and manually called destructors can raise eyebrows.
If I do the rust equivalent of:
def add1(x):
return x + 1
x = 1
y = add1(x)
z = add1(x)
[You can ignore the fact that I'm using numbers and substitute an object if that makes more sense in the context of allocating / deallocating memory in rust.]
However, a few types, including integers, but also things like booleans and chars, implement a trait (which for the purposes of this discussion is like an interface, if you're not familiar with traits) called Copy that means that they should be implicitly copied rather than moved. This means that in the specific example you gave above, there would not be any error, since `x` would be copied implicitly. You can also implement Copy on your own types, but this is generally only supposed to be done on things that are relatively small due to the performance overheard of large copies. Instead, for larger types, you can implement Clone, which gives a `.clone` method that lets you explicitly copy the type while still having moves rather than copies be the default. Notably, the Copy trait can only be implemented on types that already implement Clone, so anything that is implicitly copied be can also be explicitly copied as well
Compare with C++, in particular types with deleted copy operators (e.g. unique_ptr<T>). In order to call a function that takes an unique_ptr by value as argument, you must explicitly move the object into the function:
void foo(unique_ptr x) {
...
}
unique_ptr x = ...;
foo(move(x));
foo(move(x));
Also and importantly because move() only indicates that the value may be moved from (it's a fancy cast), that doesn't mean it will be moved from. The called function needs to take an rvalue reference (T&&) for a move to possibly happen. That is if you had a
void foo(unique_ptr&& x)
IIRC what happens here is that since foo() takes a unique_ptr by value the compiler will insert the construction of a temporary unique_ptr and overload resolution will select the move constructor (since we've provided an rvalue reference, and assuming the wrapped type is move-constructible).
> move leaves the object in an unspecified but valid state
Also notes that this is the general semantics, but specific types can define their exact behaviour here. In particular, unique_ptr specifies that a moved-from unique_ptr is "nulled" (equal to nullptr).
(I realize you, saagarjha, probably know this already -- this is more a note to other readers.)
But I remember the words "drop" and "dup" being used since the early days of linear logic too. I believe they come from Forth, where they do pretty much the same thing! [2]
[1] http://homepages.inf.ed.ac.uk/wadler/papers/linear/linear.ps
|_| ()
In which case there’s only one situation where I could see this useful, and that’s when you are building a large object to replace an old one.
The semantics of
foo = buildGiantBoject();
drop(foo);
foo = buildGiantBoject();
template<typename _Tp>
constexpr typename std::remove_reference<_Tp>::type&&
move(_Tp&& __t) noexcept
{ return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); }The compiler actually implicitly adds drop glue to all dropped variables!
It's a wonderful language but there are still some PITAs. For example you can't initialize some const x: SomeStruct with a function call. Also, zero-cost abstraction is likely the biggest bullshit I've ever heard, there is a lot of cost and there's also a lot of waiting for compiler if you're using cargo packages.
That said, I wouldn't rather use C/C++/Go/Reason/Ocaml/? - that is probably the love part.
BTW: I've recently stopped worrying about unsafe and it got a bit better.
So my message is probably: - keep your deps shallow, don't be afraid to implement something yourself - if you get pissed off, try again later (sometimes try it the rust way, sometimes just do it in an entirely different way)
let x = String::from("abc");
std::mem::drop(&x);
std::mem::drop(&x);
std::mem::drop(&x);
std::mem::drop(&x);https://play.rust-lang.org/?version=stable&mode=debug&editio...
On my phone so I can’t triple check, but there’s no bound on T, you can pass in any type.
The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard.
i'm fairly ignorant on the various differences but my general feeling was that Go is quite useful?
See "less is exponentially more".
The same way some electric bikes are restricted to a given speed to keep their user safe. Some people call it "crippled", while some other call it "simple and safe to use".
Gotta say, I lost a lot of respect for the author at this point. It’s not like I don’t love Rust - quite the contrary - but if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight. Go has been one of my languages of choice for over half a decade now, and for good reason.
I just spit mezcal on a stranger.
It's not just a matter of memory use. References and mutable references form a sort of compile-time read-write mutex; you can't take a mutable reference without first dropping all other references. See https://stackoverflow.com/questions/50251487/what-are-non-le... for more.
NLL only affects values without destructors.
Now actually this is a quite nasty object with implicit global side effects which you should avoid in the first place, but for the mutex case i don't know of a better option, maybe Rust has a better way to handle this?
fn main() {
let mut a = 1;
let b = &mut a;
*b = 2;
println!("{}", a); // prints "2"
// *b = 4; // If this line is uncommented, compile time error.
}
Of course, it doesn't matter in this trivial case, because b is just some bytes in the current stack frame so there's nothing to actually de-allocate. But if b were a complex type that _also_ had some memory to de-allocate, this wouldn't happen until the end of main(). But in this case, b's scope also lasts until the end of main, which is kind of like adding that last line back in...
This can be seen in the following example, where b has an explicit type:
struct B<'a>(&'a mut i32);
impl<'a> Drop for B<'a> {
fn drop(&mut self) {
// We'd still have a mutable reference to a here...
// If B owned resources and needed to free them, this is where that would happen
}
}
fn main() {
let mut a = 1;
let b = B(&mut a);
*b.0 = 2;
std::mem::drop(b); // Comment this line out, get compiler error
println!("{}", a); // prints "2"
}
In other words, this "going out of scope at last use" is really about rust's lifetimes system, not memory allocation.
IMHO... this is one of the rough edges in rust's somewhat steep learning curve. Rust's lifetimes rules make the language kind of complicated, though getting memory safety in a systems programming language is worth the trade-off. There's a lot of syntactic sugar that makes things a LOT easier and less verbose in most cases, but the learning curve trade-off for _that_ is that, when you _do_ run into the more complex cases that the compiler can't figure out for you, it's easy to get lost, because there are a few extra puzzle pieces to fit together. Still way better than the foot-gun that is C, though. At least for me... YMMV, obviously.
"(...) there are two factors that make something a proper zero cost abstraction:
No global costs: A zero cost abstraction ought not to negatively impact the performance of programs that don’t use it. For example, it can’t require every program carry a heavy language runtime to benefit the only programs that use the feature.
Optimal performance: A zero cost abstractoin ought to compile to the best implementation of the solution that someone would have written with the lower level primitives. It can’t introduce additional costs that could be avoided without the abstraction."
https://boats.gitlab.io/blog/post/zero-cost-abstractions/
It's not about compile time...
You can if it's a `const fn`. The set of features you can use in `const` is small but growing.
While someone else is right that "zero-cost" refers to runtime cost rather than compilation cost, dependencies are the biggest problem.
The program `spotifyd` takes over an hour to compile on my X200 laptop. This is, for reference, the same amount of time that the Linux Kernel and GCC takes to compile (Actually, I think GCC takes less time...). Most of the compilation time is on the 300+ dependencies, that simply wrap C (and in some places, replicate) libraries that I already have installed on my system!
Your comment was the first I've heard of spotifyd, so I downloaded it from github and ran "cargo build". I spent 3 minutes figuring out that I needed to install the "libasound2-dev" package, then I spent less than 2 minutes compiling. I watched the clock to be sure, but after only 2 minutes, Cargo produced a target/debug/spotifyd executable. Maybe you're referring to --release compilation?
I don't have the fastest PC, it's just an 8 year old desktop with a 6 core Intel i7 980x running Ubuntu 18.04. Rust compilation maxes out all the cores, which is really nice.
With the RustEnhanced package added to Sublime Text, editing Rust code is a very interactive experience with practically instant feedback. Running tests is fast too.
I wish I understood why some people are apparently having a very different experience. Maybe it's slow on some operating systems.
You can get a $200 CPU that will blast through a kernel compile in 3 minutes.
Swift is still missing decent async / await support, generators and promises. Some of this stuff can be written by library authors, but doing so fragments the ecosystem. Its also still harder than it should be to write & run swift code on non-mac platforms. And its also not as fast as it could be. I've heard some reports of swift programs spending 60% of their time incrementing and decrementing reference counts. Apparently optimizations are coming. I can't wait - its my favorite of the current crop of new languages. I think it strikes a nice balance between being fancy and being easy of use. But it really needs some more love before its quite ready for me to use it as a daily workhorse for http servers and games.
For example, use an atomic integer: https://play.rust-lang.org/?version=stable&mode=debug&editio...
You can also use types built on std::sync::Once and UnsafeCell, like once_cell::Lazy<std::sync::RwLock<T>>. This will get even easier as we get `const fn` constructors for locks in the future.
Zero cost refers to runtime cost, not compilation cost. Zero cost abstraction is not bullshit.
Maybe just dig into some sources and see what macros are expanded to to see the overhead.
> I guess I shouldn't be promoting language-bashing, but +1 for calling Go an unacceptably crippled edifice :)
https://old.reddit.com/r/rust/comments/dh4rcz/my_favorite_ru...
Less common complaints are that it's missing: object oriented features like inheritance, a configurable gc (as java has), the ability to work with OS threads, c-compatible stacks for fast c-interop, ownership semantics, type-inference for arguments (e.g. as haskell does), operator overloading, dependent types, etc.
The list of things in the first set can mostly be summed up as "go has a worse type-system than C++/rust/etc, something much closer to java 1 before generics, or c". Basically, the language is intentionally crippled because it intentionally ignores advances in type-theory that have been shown to allow expressing many things more safely.
For example, sum types and match statements make modifying code much safer. People will write switch/if-else-ladder code to do exactly the same sort of thing even without them, the code will just fail at runtime rather than compile-time when a new variant is added or one is not handled by accident.
Lack of generics is a big part of the issue. But more generally the focus on "simple" code means that more sophisticated abstractions are actively eschewed, and personally I find this makes writing Go code quite frustrating.
Someone describes Go as "unacceptably crippled" while Uber engineering has 1500 microservices written in Go, making it their primary language.
Go was explicitly designed to be a poor language of this sort, as evidenced by the infamous Rob Pike quote:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
In other words: a language that makes programmers fungible. And how did they accomplish this? By omitting features and barely going for the lowest-common denominator of the languages listed, disregarding any reasons other languages may have for their more ‘advanced’ features like generics. Hence, crippled.
(Frankly, I object more to describing Scala as ‘the most complex edifice’.)
I also find Go-the-language unacceptably crippled. Unfortunately, Go-the-runtime is the only best runtime for microservice-based applications, if you want a GC, especially if you want to run the system on limited hardware.
All the other options are either too bloated to comfortably spawn in large numbers (Java, C#, Node, Python, Ruby take too long to start, use too much RAM , and/or give you too large containers), or are too new and unproven (Nim).
So, we chose to use the inferior language and line with a small hit to productivity (language choice has little impact on productivity after the learning stage anyway) for the superior runtime system.
> ... if the only takeaway from Go for you is that it is “unacceptably crippled” then I feel you have missed a lot of insight.
Perhaps the author used a poor choice of words and instead could have phrased their intent along the lines of:
Go lacks the semantic density needed to express solutions in both a concise and consistent manner.
Were this the case, it would be hard to disagree as Go does, indeed, lack linguistic capabilities present in other programming languages which enable developers to encode system constraints within the language itself. Some might see this as a benefit, but I do not. YMMV.
A similar philosophy of "keep the language dirt-simple so anyone can code in it" was a driving force behind Java (the language) and JavaScript. What people have discovered is that when a programming language does not assist in expressing intrinsic problem complexity explicitly, it becomes implicitly intertwined within the source itself.
Pre-generics Java is about the appropriate amount of language complexity for our current lingua franca
That is a difficult statement for a Go user to parse.
It is referring to a lack of language features that result in verbosity or boilerplate?
But it's certainly less semantically dense compared to Rust or Scala etc.
Go is a favorite target, but Python, Ada, Java, C# etc didn't remain unscathed either.
fn add1(x: Thing) -> Thing {
x + 1
}
fn add2(x: &Thing) -> Thing {
x + 2
}
fn add3(x: &mut Thing) {
x.add(3)
}
let y = add1(x); // Works; takes ownership.
let z = add2(&y); // Works, and doesn't take ownership.
let zz = add2(&y); // So you can do it twice. (Y tho?)
let h = add3(&y); // Compile-time error!
let hh = add3(&mut y); // Works. You need to specify that you're fine with y being mutated. fn add1(x: Vec<i32>) -> Vec<i32> { // Takes ownership
return x.iter().map(|&x| x + 1).collect::<Vec<_>>();
}
fn add1_borrow(x: &Vec<i32>) -> Vec<i32> {
return x.iter().map(|&x| x + 1).collect::<Vec<_>>();
}
let x = vec![1, 2, 3];
let y = add1(x);
let z = add1(x); // error[E0382]: use of moved value: `x`
let x = vec![1, 2, 3];
let y = add1_borrow(&x);
let z = add1_borrow(&x);
let x = vec![1, 2, 3];
let y = add1_borrow(&x);
let z = add1(x);
(Note, I chose Vec here because Vec does not implement Copy: if I used i32 it would just copy the value in the non-borrowing case, which would make the code fine as no ownership would be transferred.)
I'll be honest, neither of those are my top issue with that in terms of why I think it's ugly.
I value my security first and foremost. My X200 has zero binary blobs running on the machine, it also has several other properties that I appreciate.
> You can get a $200 CPU that will blast through a kernel compile in 3 minutes.
That assumes that I even have the money to afford that. Not all of us live in silicon valley.
Go shouldn't be Rust. We already have Rust. Though while I say that, I'd still hate to have to use Go.
Clone would be what comes closest to copy constructors, and it has to be explicitly invoked.
This rule really helps both the compiler and the programmer to make moving and copying things effortless. It does prevent things like a struct holding internal pointers to it's own state. This is not bad on x86, because you can replace internal pointers with internal offsets, and the instruction set contains a fast reg+reg addressing mode, but can cost an extra instruction on many other cpu architectures. IMHO the rule is well worth it, although it is an example of a situation where Rust chooses to give away a bit of performance for sanity.
There is no "read the docs and don't screw up" because the program will not compile at all if you do it wrong, and the compiler will explain why.
It's very useful for data ownership e.g. move file or string, you can forget about its existence (you have to really). It's also extremely useful to encode "static" state machines, especially when they're attached to some sort of unique resource: on state transition, consume the old state (one type) and return the new state (a different type). Not all state machines can be encoded thus and still useful, but when they do it's really nice.
It is a compiler error to use the value after it was moved. And the compiler error is quite explicit about how to solve it
For example you can explicitly clone
let y = add(x.clone());
let z = add(x);What the chance in real life that a function like that cannot simply use a reference?
In my learning Rust, my life became significantly better and easier when I started to references to borrow as much as possible.
It's a very much a "bondage and discipline"-style language in the sense that unless you explicitly use "unsafe", you have to prove to the compiler that everything you do is safe. Moving large things is not unsafe because after you move something to a different scope, the original doesn't exist anymore and can't be used, so if you were to accidentally move something and tried to use it again, the compiler would helpfully tell you that the thing you're trying to refer to isn't there anymore.
There is no warning on every time you pass something without copy because passing things to different scopes is extremely common, normal and desired.
I often see Go functions with a large number of lines- many of which are noisy boilerplate error handling. Combine that with terse variable names, type inference and it's straight up tiresome to filter out the important parts. These functions aren't even doing all that much.
There is a healthy middle-ground between excessive abstraction a la Enterprise Java and what Go offers.
There are nice aspects to reading Go, but any function which does some kind of error-prone operation is so hard to grok, it gets tiring - the actual purpose is constantly interrupted by 'if err := nil' so much.
And gods help you if there is some actual non-trivial error handling going on, as you've generally learned to gloss over and can easily miss that one place that actually does something with an error other than log and return.
Also, while admittedly rare, trying to review code that needs to copy structs around, if they also involve pointers or slices, is just hell.
I'm sorry but I couldn't read past this.
Indeed.
I currently compile on raspi4 and scp the results there to check.
Memory management is not the only type of “little detail.” For instance, rust provides common collection operations (filer, map, find…) in the standard library. In go (AFIAK), you need to hand-write a loop for each. IMO, the rust version is takes much less mental bandwidth to write and understand.
I am not sure to whom you are referencing as being "our", so I can only say I disagree as there are many developers which are quite adept in languages having more complexity than "pre-generics Java."
Perhaps you meant to reply to a different comment?
Also even Google does have more stuff going on Java, C++, Dart, Kotlin and TypeScript than Go, which has more uptake outside Googleplex.
Uber on the other hand has many languages available yet picked Go. So they certainly don't think it is "unacceptably crippled".
Even the most charitable interpretation would conclude it's speaking in broad terms and not just "for my use case".
Full paragraph:
> The beauty of programming language design is not building the most complex edifice like Scala or making the language unacceptably crippled like Go - but giving the programmer the ability to represent complex ideas elegantly and safely. Rust really shines in that regard.
Switching to Go was an educated decision. Not a continuation of what was there.
https://www.quora.com/What-is-the-technology-stack-behind-Ub...
Not rethorical, I'm genuinely curious as I used to struggle with the copy vs move decisions, and a bunch of issues with ownership which went all away when I started using pointer/borrowing everywhere.
You'd have to write two extra lines of code to set up y and z separately from calling add(), and you'd have to make them mutable which is an extra mental burden.
And an immutable reference is bad because it would force extra objects to be allocated, wasting time and cache space.
Um, the whole point of Go was to be "opinionated and acceptably crippled". That's why the creators built it the way they did. Go has more than a few things where "Me, but not for thee" rules--the compiler can do X but you cannot. If you find that is an acceptable tradeoff for the other features of Go, great!
Lots of modern languages, however, are trying to go the other way. They are trying to give the programmer every bit of power that the library/compiler programmers have. This has its own failure modes that you may find unacceptable. That's fine too.
I personally dislike the Rust vs Go discussions. Those two languages in particular really don't have domain overlap and are like comparing apples to screws.
But of course, Rust is not flawless. In fact up until recently it was kind of annoying, before non-lexical lifetimes became a part of the language. It’s also a very large and complex language compared to Go. This is not unilaterally a bad thing, but just as every line of code comes at a cost, so to does every language feature, and if enough language features fail to pay the rent your programming language will end up feeling bloated.
What Go lacks is exactly its strengths. If you criticize C for not having Java-style exceptions, people will look at you funny. There is some divide in the community over error handling but I defend that Go’s verbose and stupid error handling pattern is my favorite part of the language, and changed how I code inside and outside of Go. I also appreciate Go’s simple but effective patterns for composition-based object oriented programming, and for having a decent concurrency model (not that it is without flaws: the limitation of Go’s memory safety is definitely an issue here.)
Everything comes at a cost. The borrow checker brings immense promise for security, but that does not mean other approaches to memory safety or language design are suddenly obsolete. It’s more complicated than that, and I consider failure to understand this to be a sign that someone is not keeping an open mind.
Surely you understand that this is a very self-serving attitude, though?
It's like someone points out that your car is crippled because it has a turning radius of 2 degrees and also has no brakes, and you go, "no but you see, what this car lacks is exactly its strengths! And it's those strengths that I enjoy the most when driving this car!"
I don't like it. I program Rust the rest of the time. I'm considering learning Perl5 so that at least my type system lets me do vaguely expressive things - I'm utterly fed up of half my code looking like:
foo, err := something()
if err != nil {
return nil, someErr{err}
}
I would consider "unacceptably crippled" to be a reasonable description of Go, even if it's the best tool I have for some jobs.
Or maybe they have just expanded their "knowledge spectrum" and are experiencing an effusive moment?
Those who can will do,
Those who cannot will seek to,
Hide that fact from you.
Both points you make I agree with. I simply was offering a possible explanation for those whom exhibit overly passionate opinions when they become enlightened.
When people take an epiphany to the point of denigrating those around them, then they likely have issues beyond what any programming philosophy could possibly encode.
Would do the same in C++ for values held by unique_ptr: take ownership of the pointer and then free it.
Am I missing something? Does it not work with std::move?
void drop(std::unique_ptr<T> x) {}
Or, you know, just call someX.reset(); or do someX = nullptr;. The drop call would be way noisier: drop(std::move(someX));
template <class T>
void drop(T&) = delete; // force callers to move
template <class T>
void drop(T&& x) {
T drop_me(std::move(x));
}
template <class T>
void drop(T) {}