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

Rust 1.45

blog.rust-lang.org

Post reply on HN
Print view View original

191–200 of 227 posts

Re: Rust 1.45

#191

Post by tekknik »

conradludgate wrote: post #162
cuddlybacon wrote: post #146

As someone who hasn't used Rust, I am curious about why Rust has macros. I use C++ at work, which admittedly isn't the language I use most, and macros are used quite a bit in the code base. I find they just make the code harder to read, reason about, debug, and sometimes even write. I don't see them really living up to their claimed value. Is there something different about Rust's macros that make them better?

The first thing I would say is that regular inline macros are hygienic and type safe, just like the rest of the code you write. That way they're not just text expansion but smart code expansion. When I say hygienic, I mean that when a macro uses a variable that isn't in the parameters or isn't static, it will be a compile error as it cannot know the scope. Any variables defined inside are scoped. Only parameters pars…

I’m not a rust programmer, reading your explanation here it’s not anymore clear why some macros exist (println for instance). They very much look similar to functions in most of the cases I’ve seen (again from the perspective of trying to find a reason besides safety to learn rust) so why exactly do these exist? They are a great source of confusion for those of us with C/C++ experience (or at least me) which is the target audience.

Re: Rust 1.45

#192

Post by saurik »

estebank wrote: post #153
saurik wrote: post #145

Earlier quoted context omitted.

It might not be "idiomatic", but it isn't "unsafe", and so it is now providing a guaranteed behavior that... is it a bug? I certainly think saturation should always be considered a bug... like that's even worse to me than truncation as the semantics of truncation are at least interesting and related to mathematical basis of von neumann computing and sometimes extremely useful as a way to interact with memory-oriented…

"unsafe" has a very specific meaning in the context of Rust[1][2]: particularly letting you perform actions that can potentially cause undefined behavior. Defining `as` as saturating is removing UB. That being said, the reason it is considered unidiomatic is because saturating or wrapping might not be what your intention could be, so other ways of turning one type to another is needed and should be recommended (into…

It is "removing" undefined behavior by simply defining it to be something no one would ever ever want ;P. If you are willing to just define behavior arbitrarily then I think you will find the vast majority of (but admittedly not all) undefined behaviors can be made "safe".

Re: Rust 1.45

#194

Post by staticassertion »

Jweb_Guru wrote: post #131
kibwen wrote: post #116

Earlier quoted context omitted.

I believe it's safe to assume that Rust's memory model is (a subset of) C++11's memory model, since that's what LLVM implements. At this point I don't see how any specification could deviate significantly from that without breaking tons of code.

The Rust memory model is deviating from it a little in order to enable some norestrict-based optimizations that aren't really done for C, even though (as you know) LLVM can't really take advantage of them yet.

I imagine that in C if the compiler can prove that two pointers don't alias than it can elide a load?

Re: Rust 1.45

#195

Post by jefftime »

jefftime wrote: post #107
fullstop wrote: post #36

I keep seeing more and more news about Rust, and figure that perhaps it is time that I learn something new. 99% of my development work these days is C with the target being Linux/ARM with a small-ish memory model. Think 64 or 128MB of DDR. Does this fit within Rust's world? I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are…

I've been playing with Rust myself in my free time, and if you use Rust with the standard library a stripped executable should be smaller and more comparable to C than what you're seeing with the standard library included. Depending on your use case, you might be able to get away with just using the core library

Ah, meant to say "without the standard library." My bad

Re: Rust 1.45

#196

Post by lumost »

nicoburns wrote: post #158
The_rationalist wrote: post #135

Earlier quoted context omitted.

>= 1.0 in semantic versioning universally means that it should be "stable enough"

The Rust ecosystem typically has much more conservative version numbers than other ecosystems though, and higher quality standards. There are several very high quality crates with 0.x version numbers.

A fairer statement might be that the rust ecosystem has inconsistent version numbers. I've seen both flawless v.14s and awful v.7s. There are a few ways to figure out the difference like sorting by downloads on crates.io to find packages that are commonly used.

There is a curious parallel to the rise of Go which had no versions in their ecosystem as the language was adopted.

Re: Rust 1.45

#197

Post by DesertVarnish »

tekknik wrote: post #191
conradludgate wrote: post #162

Earlier quoted context omitted.

The first thing I would say is that regular inline macros are hygienic and type safe, just like the rest of the code you write. That way they're not just text expansion but smart code expansion. When I say hygienic, I mean that when a macro uses a variable that isn't in the parameters or isn't static, it will be a compile error as it cannot know the scope. Any variables defined inside are scoped. Only parameters pars…

I’m not a rust programmer, reading your explanation here it’s not anymore clear why some macros exist (println for instance). They very much look similar to functions in most of the cases I’ve seen (again from the perspective of trying to find a reason besides safety to learn rust) so why exactly do these exist? They are a great source of confusion for those of us with C/C++ experience (or at least me) which is the t…

println is a macro in Rust because 1) the language currently lacks support for variadic functions and 2) being a macro allows the format string to be parsed at compile time.

Re: Rust 1.45

#198

Post by luhn »

sitkack wrote: post #29

> Rust 1.45.0 adds the ability to invoke procedural macros in three new places! Rust 1.45 will be the Rocket Release. It unblocks Rocket running on stable as tracked here https://github.com/SergioBenitez/Rocket/issues/19 This is so excellent, and I love seeing long term, multiyear goals get completed. It isn't just this release, but all the releases in between. The Rust team and community is amazing.

For those out of the loop like me, Rocket is a web framework for Rust that apparently was using a lot of experimental features. https://rocket.rs/

Or maybe it's an explosive weapon crafted with metal pipe and gunpowder. https://rust.fandom.com/wiki/Rocket

Re: Rust 1.45

#199

Post by lmm »

cuddlybacon wrote: post #146

As someone who hasn't used Rust, I am curious about why Rust has macros. I use C++ at work, which admittedly isn't the language I use most, and macros are used quite a bit in the code base. I find they just make the code harder to read, reason about, debug, and sometimes even write. I don't see them really living up to their claimed value. Is there something different about Rust's macros that make them better?

Most languages end up needing a way to step outside that language, and if you don't have macros you end up using something even worse. Rust in particular lacks "do notation" or proper support for higher-kinded types, so it needs to use macros as an ad-hoc replacement for things like sequencing async operations or proper propagation of errors. To be honest I'm surprised they didn't find a way to make a web framework in plain rust though.

Re: Rust 1.45

#200

Post by ChrisSD »

saurik wrote: post #192
estebank wrote: post #153

Earlier quoted context omitted.

"unsafe" has a very specific meaning in the context of Rust[1][2]: particularly letting you perform actions that can potentially cause undefined behavior. Defining `as` as saturating is removing UB. That being said, the reason it is considered unidiomatic is because saturating or wrapping might not be what your intention could be, so other ways of turning one type to another is needed and should be recommended (into…

It is "removing" undefined behavior by simply defining it to be something no one would ever ever want ;P. If you are willing to just define behavior arbitrarily then I think you will find the vast majority of (but admittedly not all) undefined behaviors can be made "safe".

Nobody wants undefined behaviour. That's always worse than defining it, whatever that definition is. In any case, there are better options for selecting the behaviour you want instead of using `as`.
Post reply on HN