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

121–130 of 175 posts

Re: An incoherent Rust

#121

Post by BigTTYGothGF »

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 wonder if C++ has some hairy concepts and syntax today on par with Rust's more difficult parts

Yes, it's called "C++".

Re: An incoherent Rust

#122

Post by tialaramex »

gpderetta wrote: post #110
tialaramex wrote: post #68

Earlier quoted context omitted.

> Rust isn't special in this regard, it has the same issues. This is both fundamentally true and misleading. Rust has to solve the same issues but isn't obliged to make all the same bad choices to do that and so the results are much better. For example C++ dare not perform compile time transmutations so, it just forbids them and a whole bunch of extra stuff landed to work around that, but in Rust they're actually fin…

First of all mem::transmute is like bit_cast (which works perfectly fine in constexpr context), not reinterpret cast. Second, this compiles just fine: constexpr int ivalue = 1; constexpr bool bvalue {ivalue}; This fails at compile time (invalid narrowing): constexpr int ivalue = 2; constexpr bool bvalue {ivalue}; Note we don't need bit_cast for this example as int to bool conversions are allowed in C++.

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 sneaks up on you.

Re: An incoherent Rust

#123

Post by bryanlarsen »

kelnos wrote: post #74
Aurornis wrote: post #38

Earlier quoted context omitted.

> But reading some of the made-up syntax in the "Removing Coherence" section makes my head hurt. Articles discussions new features always have difficult syntax. There have been proposals like this going on from the start. Fortunately the language team is cognizant of the syntax and usability issues with proposals. There have been a lot of proposals that started off as very unwieldy syntax but were iterated for years…

I think it's more than the syntax, it's just the number of concepts you need to keep in your head to read a type signature, or a trait declaration, or whatever. There's only so much you can pack into a limited language before it becomes too much to keep in your head at once.

Most of the time over the past couple years when somebody complained about Rust getting a complex new feature, it was complex backend work that exhibited to users as the removal of restriction, making the language simpler. Example: async closures. A language that supports both async and closures but doesn't support them together is more complicated than one that supports async closures.

This feels like it should end up similar. The driving desire here is the removal of a restriction, so hopefully it ends up as an end user simplification rather than complication.

Re: An incoherent Rust

#124

Post by ameixaseca »

hactually wrote: post #75

Great write up of a problem that I'm glad Golang sidesteps The problem with this is that it's systemic and central to Rusts trait-based ecosystem composition. Go’s has a version but it's much smaller and more local. In Go, consumer-defined structural interfaces remove most of the pressure that causes the Rust problem in the first place which is producer led.

Sidesteps by not providing the same level of functionality.

As an analogy, it would be equivalent to say that "contrary to an airplane, a car sidesteps the problem of requiring wings".

Yes, indeed - but it doesn't fly.

Re: An incoherent Rust

#125

Post by busterarm »

antonvs wrote: post #83
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…

> so if the API is bad, you're pretty screwed. Is this really that big a downside? It encourages good APIs. The alternative of everything being public is the kind of feature that quickly becomes a big disadvantage in larger systems and teams, where saying “just don’t footgun yourself” is not a viable strategy. If there’s a workaround to achieve some goal, people will use it, and you end up with an unmaintainable mess…

Because no one has ever deliberately used the wrong tool for business reasons. Or thought they had a perfectly reasonable argument.

It's better to have escape hatches for in case you need them, but anyone who feels that way probably isn't using Rust to start with.

Maybe that's a bit harsh. I'm sure there are some problem domains where the other trait is desirable, but IMO it's not generic systems programming.

Re: An incoherent Rust

#126

Post by bluGill »

jandrewrogers wrote: post #45
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 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.

Re: An incoherent Rust

#127

Post by MeetingsBrowser »

simonask wrote: post #52
MeetingsBrowser wrote: post #41

Earlier quoted context omitted.

> In many other ecosystems it's not uncommon to run into having issues where certain libraries can't be used together at all. The same problem exists in Rust, but from the other side. If I use serde for serialization I am effectively locked in to using crates that implement serde traits (or do newtype hacks to define them myself). If I want to use something more niche than serde, I essentially lose access to all the…

Newtypes aren’t hacks, they’re perfectly acceptable in my opinion. Especially if you’re willing to also use a crate like `derive_more`.

In my experience using newtypes like this causes a constant shuffle between the original type and the newtype.

If a library exposes Foo and I wrap it in MyFoo implementing some trait, I need to convert to MyFoo everywhere the trait is needed and back to Foo everywhere the original type is expected.

In practice this means cluttering the code with as_foo and as_myfoo all over the place.

You could also impl From or Deref for one direction of the conversion, but it makes the code less clear in my opinion.

Re: An incoherent Rust

#128

Post by MeetingsBrowser »

selfmodruntime wrote: post #108
MeetingsBrowser wrote: post #3

Earlier quoted context omitted.

can you elaborate on how have they contributed to the quality of the ecosystem?

There are virtually no incompatible dependencies.

The blog post gives an example of how the current approach makes dependencies incompatible.

> if someone publishes an alternative to serde (say, nextserde) then all crates which have added support for serde also need to add support for nextserde. Adding support for every new serialization library in existence is unrealistic

If I use serde, I cannot use a crate that only implements nextserde.

If I want to use nextserde, I lose the ability to use all the crates that only implement serde.

Re: An incoherent Rust

#129

Post by i_don_t_know »

I’m not sure I fully understand but this seems to be the kind of problem that Ocaml functors solve. You program against an interface (signature) and you supply a concrete implementation (structure) when you want to run it. You can use different implementations in different parts of your application.

So maybe do something similar in Rust by expanding how you import and export modules?

Re: An incoherent Rust

#130

Post by gedy »

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 wonder if Google's Carbon could fill that gap?

https://en.wikipedia.org/wiki/Carbon_(programming_language)

Post reply on HN