Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A half-hour to learn Rust

fasterthanli.me

Post reply on HN
Print view View original

221–230 of 342 posts

Re: A half-hour to learn Rust

#221

Post by GolDDranks »

wokwokwok wrote: post #73
kaoD wrote: post #66

Earlier quoted context omitted.

Types are not generated at runtime, lifetimes are types (although they cannot be constructed). T and T are different types altogether (although, being generic, they can resolve to the same type if 'a == 'b, but it's not required). All this happens at compile time. When you say T: 'a you say that T is a subtype of 'a hence it lives longer. https://doc.rust-lang.org/nomicon/subtyping.html Maybe you're being confused by…

You misunderstand; what confuses me is how 'static can mean the same thing in both of these contexts. T: 'static does not mean the references in T must exist for the lifetime of the application. Ie. the lifetime constraint on T isn’t the same 'static from &'static where the reference must life for the entire lifetime of the application. Types are static. T: 'static applies to instances at runtime. These instances do…

You seem to misunderstand what type : lifetime means.

> 'static in this context would mean that all members of T must be 'static, which means that all instances of T must be 'static.

Your "which means that" isn't true. It doesn't mean that. The syntax type : lifetime indicates that the values of the type MUST BE ABLE to outlive the lifetime. It doesn't mean that they NEED to outlive the lifetime.

This means, for example, i32 : 'static even in the case doesn't live the whole 'static lifetime. It COULD live, though, if the author of the code allocated it statically.

Re: A half-hour to learn Rust

#222

Post by julenx »

fasterthanlime wrote: post #215
globuous wrote: post #214

Earlier quoted context omitted.

Except from that though, it really looks like ocaml, which really makes me want to look into rust a little bit more :)

Yup, strong similarities there, since the original Rust compiler was implemented in OCaml :)

For those who are curious, here's the source code of the original compiler written in OCaml (rustboot) https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216...

Re: A half-hour to learn Rust

#223

Post by [deleted] »

_nckn wrote: post #191
artursapek wrote: post #165

Earlier quoted context omitted.

> I cannot believe that I am smitten by Rust within an hour This has been my, and a lot of my colleagues', experience with Rust. Never have I seen people fall in love with a programming language so strongly. And the love lasts for a long time.

Try to use that in real world and see if your love still stays put. An hour is not enough to validate Rust.

[deleted]

Re: A half-hour to learn Rust

#224

Post by damnyou »

archon wrote: post #146

Preface: This is an honest question, not an attempt to start a "which language is better" war. I'm proficient in C#. I haven't yet encountered any problems I can't solve with C# and the .Net open source ecosystem. (Perhaps that says more about the banality of the problems I'm solving than about .Net, but there you are.) What would Rust give me the tools to do that I can't already accomplish with C# / .Net Core?

Control over 95th+ percentile latency.

Re: A half-hour to learn Rust

#225

Post by felipellrocha »

ithrow wrote: post #171
nitred wrote: post #161

As a Python programmer with limited experience with compiled languages, Rust code was more intimidating to read or look at than C++, Java or Go. After only an hour, I am overwhelmed by the sheer beauty and mature design of this language - it almost reads like Python or as well as any compiled language can. I cannot believe that I am smitten by Rust within an hour. Its features seem, obvious. My experience with Go was…

am overwhelmed by the sheer beauty and mature design of this language - it almost reads like Python or as well as any compiled language can. All those lifetime annotations are not sheer beauty or pretty, sure they are necessary but not nice to look at if you are comparing it to a higher level language.

You get used to it, and you don't really need to use it most of the time. Only for more complicated things, but by that point, it's second nature.

Re: A half-hour to learn Rust

#226

Post by nobleach »

throwaway894345 wrote: post #197
nobleach wrote: post #184

Earlier quoted context omitted.

Yes, you can clone all day long and just reuse variable names as if you were writing JavaScript, but what does that do to your memory allocation?

To be clear, JS doesn’t require cloning because it has a gc. Not sure what you’re getting at with reusing variables names...

What I mean is, if one does:

  const obj1 = { a: 32, b: 42 };
  function foo(ref) { ref.a = 0; }

  foo(obj1);
  console.log(obj1);
in JavaScript, one is just using the variable name as a "holder" of some value. One doesn't have to designate that that variable is being passed by reference. If one wanted to actually copy that object, they'd have to devise a mechanism to do so. In Rust, if someone doesn't specify, using the & symbol, that something is a reference, it'll end up moving the value.

Basically all I was saying is one can not approach writing Rust with a Java/JavaScript mindset. (That a variable is just a bucket holding a value). Care needs to be taken when referencing a variable as it may need to be moved, copied/cloned or referenced. In the case of copying, another memory allocation is done. So if someone approaches Rust from the standpoint of "this word represents a value, and I'm going to use it all over the place", they can find themselves blindly allocating memory.

Re: A half-hour to learn Rust

#227

Post by GolDDranks »

wokwokwok wrote: post #120
kaoD wrote: post #116

Earlier quoted context omitted.

What confuses me is... why do you think the meaning is different? There is no meaning overload. It's a single meaning. T: 'static would happily typecheck with &'a str if 'a: 'static. T: 'static typechecks: - OwnedValue - OwnedValueWithReferences where 'a: 'static - &'a ReferencedValue where 'a: 'static /// &'static ReferencedValue - Foo where 'a: 'static /// Foo ...and more. See the example here: https://play.rust-la…

What you say makes sense... but I struggle to reconcile it with reality. If "the left part of this bound can live up to the end of the application" then why is &a not 'a where 'a: 'static? a can live up to the end of the application. &a can live up to the end of the application. Why is the result "argument requires that `a` is borrowed for `'static`" fn foo (a: &'a str) { println!("{}", a) } pub fn main() { let a = "…

> a can live up to the end of the application. &a can live up to the end of the application.

Nope, a reference to a stack frame can't live up to the end of the application. The stack frame gets deallocated and the referent ceases to exist; therefore the reference you're creating in your linked example doesn't outlive 'static. `main` is not an exception to this in Rust.

Re: A half-hour to learn Rust

#228

Post by _lbaq »

faitswulff wrote: post #173
dmitshur wrote: post #149

For anyone curious what a Go version of the same article would look like (as I was), I tried to answer that question by writing https://dmitri.shuralyov.com/blog/27 .

I enjoyed this, thank you!

Comments like this are to far in-between on the internet, kudos!
Post reply on HN