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

An incoherent Rust

boxyuwu.blog

Post reply on HN
Print view View original

141–150 of 175 posts

Re: An incoherent Rust

#141

Post by Capricorn2481 »

bluGill wrote: post #126
jandrewrogers wrote: post #45

Earlier quoted context omitted.

> I wonder if C++ has some hairy concepts and syntax today Both better and worse. The current version of idiomatic C++ is much cleaner, more concise, and more powerful than the version of C++ you are familiar with. You don't need C-style macros anymore. The insane template metaprogramming hacks are gone. Some important things that were problematic to express in C++ (and other systems languages to be fair) are now ful…

These problems will happen in some form for every long lived codebase. In 15 years you will have some regrets, and some of those regrets will be things that are all core APIs used everywhere in the code base and so impossible to quickly change.

Isn't it 100x worse in C++ though? Because the surface area is huge? I work on legacy apps but PHP 5.6 is not that fundamentally different from PHP 8.3.

Re: An incoherent Rust

#142

Post by jdonszelmann »

staticassertion wrote: post #44
kelnos wrote: post #15

This is one of the (several?) things that make me very worried about Rust long-term. I love the language, and reach for it even when it sometimes isn't the most appropriate thing. But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. When I used to write Scala, I accepted the fact that I don't have a background in type/set/etc. theory, and that there were some facets of the la…

I really wouldn't worry much. Over the last decade of rust, very few of the articles exploring new syntax have turned into anything controversial by the time they were merged (I can't even think of big rust syntax changes other than `impl T` in arguments etc). The singular example really is async/await and, having been quite worried about it / against it at the time, it was really nothing to be concerned with at all.

let-else was a more recently added new syntax

Re: An incoherent Rust

#143

Post by staticassertion »

jdonszelmann wrote: post #142
staticassertion wrote: post #44

Earlier quoted context omitted.

I really wouldn't worry much. Over the last decade of rust, very few of the articles exploring new syntax have turned into anything controversial by the time they were merged (I can't even think of big rust syntax changes other than `impl T` in arguments etc). The singular example really is async/await and, having been quite worried about it / against it at the time, it was really nothing to be concerned with at all.

let-else was a more recently added new syntax

Indeed, but it hardly seems controversial or major. It's sort of just an extension of existing syntax, similar to `impl Trait` in argument position.

Re: An incoherent Rust

#144

Post by bluGill »

Capricorn2481 wrote: post #141
bluGill wrote: post #126

Earlier quoted context omitted.

These problems will happen in some form for every long lived codebase. In 15 years you will have some regrets, and some of those regrets will be things that are all core APIs used everywhere in the code base and so impossible to quickly change.

Isn't it 100x worse in C++ though? Because the surface area is huge? I work on legacy apps but PHP 5.6 is not that fundamentally different from PHP 8.3.

No, it is nearly the same - most problems are your own making because of your own lack of foresight. (perfect foresight is impossible)

Re: An incoherent Rust

#145

Post by estebank »

dap wrote: post #65
kelnos wrote: post #15

This is one of the (several?) things that make me very worried about Rust long-term. I love the language, and reach for it even when it sometimes isn't the most appropriate thing. But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. When I used to write Scala, I accepted the fact that I don't have a background in type/set/etc. theory, and that there were some facets of the la…

Having used Rust professionally for six years now, I share your fear. Like many of the commenters below, coherence just hasn't been a big problem for me. Maybe there are problem spaces where it's particularly painful? How does the Rust language team weigh the benefits of solving user problems with new language features against the resulting increased complexity? When I learned Rust, I found it to be quite complex, bu…

You can look at the discussions in any of the language RFCs to see that increased complexity is one of the recurring themes that get brought up. RFCs themselves have a "how do we teach this?" section, that IMO makes or break a proposal.

Keep in mind that as time goes on, features being introduced will be more and more niche. If you could do things in a reasonable way without the new feature, the feature wouldn't be needed. That doesn't mean that everyone needs to learn about the feature, only the people that need that niche have to even know about it (as long as it is 1) it interacts reasonably with the rest of the language, 2) its syntax is reasonable in that it is either obvious what's going on or easy to google and memorable so that you don't have to look it up again and 3) it is uncommon enough that looking at a random library you won't be seeing it pop up).

Re: An incoherent Rust

#146

Post by dev_l1x_be »

hmry wrote: post #105
dev_l1x_be wrote: post #103

Earlier quoted context omitted.

Highly Expressive Macros No thanks. Most of the time you do not need macros and adding those is not free. CGP enables you to write overlapping and orphan implementations of any trait, breaking free from Rust's coherence rules while maintaining type safety. I am not sure that I need this. I can't remember to run this issue in the last couple of years. Isn't it the case that coherence is what makes Rust’s dependency gr…

> Isn't it the case that coherence is what makes Rust’s dependency graph sound? So, why would I want to give up that? Read the article that comment is on, it's all about why one would want that.

I have read it. I see only theoretical reasons not really practical ones. Maybe I do not use Rust enough to run into issues with coherent Rust.

Re: An incoherent Rust

#147

Post by estebank »

smj-edison wrote: post #60

I feel like encapsulation and composition are in strong tension, and this is one place where it boils over. I've written a decent bit of Rust, and am currently messing around with Zig. So the comparison is pretty fresh on my mind: In Rust, you can have private fields. In Zig all fields are public. The consequences are pretty well shown with how they print structs: In Rust, you derive Debug, which is a macro that impl…

> Zig vs Rust also shows up with how object destruction is handled.

I often hear critiques of Drop being less efficient for anything Arena-like, where batch destruction would be better, and holding that as the reason defer is a better approach. What is not mentioned there is that there's nothing stopping you from having both. In Rust you can perform batch destruction by having additional logic (it might require control of the container and its contents' types for easiest implementation), but the default behavior remains sane.

Re: An incoherent Rust

#148

Post by smj-edison »

estebank wrote: post #147
smj-edison wrote: post #60

I feel like encapsulation and composition are in strong tension, and this is one place where it boils over. I've written a decent bit of Rust, and am currently messing around with Zig. So the comparison is pretty fresh on my mind: In Rust, you can have private fields. In Zig all fields are public. The consequences are pretty well shown with how they print structs: In Rust, you derive Debug, which is a macro that impl…

> Zig vs Rust also shows up with how object destruction is handled. I often hear critiques of Drop being less efficient for anything Arena-like, where batch destruction would be better, and holding that as the reason defer is a better approach. What is not mentioned there is that there's nothing stopping you from having both. In Rust you can perform batch destruction by having additional logic (it might require contr…

That's fair, since you can leak the box. I will say though it's not as ergonomic as defer, as defer handles all exits from the scope, where it's trickier to juggle destructors. Though on further thought, I suppose the arena can have Drop.

EDIT: What you can't really do is this: https://github.com/smj-edison/zicl/blob/ea8b75a1284e5bd5a309...

Here I'm able to swap out std.MultiArrayList's backing to be backed by virtual memory, and correctly clean it up. I'm not sure you can really do that with Rust, barring making custom data structures for everything.

Re: An incoherent Rust

#149

Post by dap »

estebank wrote: post #145
dap wrote: post #65

Earlier quoted context omitted.

Having used Rust professionally for six years now, I share your fear. Like many of the commenters below, coherence just hasn't been a big problem for me. Maybe there are problem spaces where it's particularly painful? How does the Rust language team weigh the benefits of solving user problems with new language features against the resulting increased complexity? When I learned Rust, I found it to be quite complex, bu…

You can look at the discussions in any of the language RFCs to see that increased complexity is one of the recurring themes that get brought up. RFCs themselves have a "how do we teach this?" section, that IMO makes or break a proposal. Keep in mind that as time goes on, features being introduced will be more and more niche. If you could do things in a reasonable way without the new feature, the feature wouldn't be n…

Thanks for the context. That makes a lot of sense! Those three constraints seem pretty important and a useful way to think about the problem.

Re: An incoherent Rust

#150

Post by tialaramex »

gpderetta wrote: post #136
tialaramex wrote: post #122

Earlier quoted context omitted.

Surely "We have many different ways to do this, each with different rules" is exactly the point? C++ 20's std::bit_cast isn't necessarily constexpr by the way although it is for the trivial byte boolean transmutation I mentioned here. I see that C++ people were more comfortable with the "We have far too many ways to initialize things" examples of this problem but I think transmutation hits harder precisely because it…

bit_cast and reinterpret_cast do different things: one works at the value level, the second preserves address identity (and it is problematic from an aliasing point of view). Not sure what any of this has to do with initialization though. FWIW, the direct translation of your rust code is: constexpr char y = 2; constexpr bool x = std::bit_cast (y); It fails on clang for y=2 and works for y=1, exactly like rust; GCC pr…

Firstly, that's not a direct translation because you're making two variables and I made none at all. Rust's const is an actual constant, it's not an immutable variable. We have both, but they're different. The analogous Rust for your bit cast example would make two immutable variables that we promise have constant values, maybe:

    static y: u8 = 2;
    static x: bool = unsafe { core::mem::transmute(y) };
Of course this also won't compile, because the representation for 2 still isn't a boolean. If it did compile you'd also (by default) get angry warnings because it's bad style to give these lowercase names.

I also don't know if you found a GCC bug but it seems likely from your description. I can't see a way to have UB, a runtime phenomenon, at compile time in C++ as the committee imagines their language. Of course "UB? In my lexer?" is an example of how the ISO document doesn't understand intention, but I'd be surprised if the committee would resolve a DR with "That's fine, UB at compile time is intentional".

I understand that "these are different things" followed by bafflegab is how C++ gets here but the whole point of this sub-thread is that Rust didn't do that, so in Rust these aren't "different things". They're both transmutation, they don't emit CPU instructions because they happen in the type system and the type system evaporates at runtime.

So this is an impedance mismatch, you've got Roman numerals and you can't see why metric units are a good idea, and I've got the positional notation and so it's obvious to me. I am not going to be able to explain why this is a good idea in your notation, the brilliance vanishes during translation.

Post reply on HN