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

71–80 of 175 posts

Re: An incoherent Rust

#71

Post by jandrewrogers »

fc417fc802 wrote: post #69
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…

It's much simpler and better than it used to be but it's still pretty bad. As just one example off the top of my head consider the meaning of curly braces for initialization. There's several different things they can mean depending on the context. Good luck figuring out which set is currently in effect.

The initialization situation in C++ is indefensibly broken. It is near the top of my list of things I hate about C++.

You can mitigate it with some practices but that this is even necessary is a crime. Initialization is one of the most basic things in software development. How do you fuck it up so badly?

On a day to day basis it doesn’t cause me issues but it offends me just on principle.

Re: An incoherent Rust

#72

Post by caditinpiscinam »

I think a lot of developers look at Typescript and come away thinking that a static type system is something you can retrofit onto any language. These devs ask why anyone would still want to use a dynamically typed language, as though static typing is something that can be had for free. But the reality is that a robust type system ends up profoundly shaping the design of a language, and introduces these sorts of thorny design questions, with each option bringing its own tradeoffs and limitations.

We want our languages to make it easy to write correct programs. And we want our languages to make it hard to write incorrect programs. And trying to have both at once is very difficult.

Re: An incoherent Rust

#73

Post by jandrewrogers »

tialaramex wrote: post #68
jandrewrogers wrote: post #49

Earlier quoted context omitted.

> starting playing around with std::launder and std::byte and strict aliasing rules and lifetime rules, and you'll yearn for the simplicity of Rust Annotations like std::launder, lifetime manipulation, etc solve a class of problems that exist in every systems language. They inform the compiler of properties that cannot be known by analyzing the code. Rust isn't special in this regard, it has the same issues. Without…

> 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…

> For example C++ dare not perform compile time transmutations

I am confused by this assertion. You can abuse the hell out of transformations in a constexpr context. The gap between what is possible at compile-time and run-time became vanishingly small a while ago.

I think your example is not illustrative in any case. Many C++ code bases work exactly like your example, enforced at compile-time. That this can be an issue is a hangover from retaining compatibility with C-style code which conflates comparison operators and cast operators. It is a choice.

C++ can enforce many type constraints beyond this at compile-time that Rust cannot, with zero effort or explicit type creation. No one should be passing ints around.

Re: An incoherent Rust

#74

Post by kelnos »

Aurornis wrote: post #38
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…

> 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.

Re: An incoherent Rust

#75

Post by hactually »

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.

Re: An incoherent Rust

#76

Post by [deleted] »

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…

[deleted]

Re: An incoherent Rust

#78

Post by lmm »

simonask wrote: post #51
JoshTriplett wrote: post #32

Earlier quoted context omitted.

It's a social problem that's created by a technical problem. In many languages, if you want to integrate package A with package B, you can make and share a package AB, which people can reuse. That scales, and facilitates reuse, and avoids either package having to support everything. In Rust, if the integration involves traits, integration between package A and package B must happen either in A or in B. That creates a…

Other than duck-typed languages (and I count Go as basically that), which languages actually provide this feature? AFAIK, it’s not really very common to be able to extend foreign types with new interfaces, especially not if you own neither. C++ can technically do it using partial specialization, but it’s not exactly nice, and results in UB via ODR violation when it goes wrong (say you have two implementations of a `s…

> Other than duck-typed languages (and I count Go as basically that), which languages actually provide this feature?

There are only like 3 significant languages with trait-based generics, and both the other ones have some way of providing orphan instances (Haskell by requiring a flag, Scala by not having a coherence requirement at all and relying on you getting it right, which turns out to work out pretty well in practice).

More generally it's an extremely common problem to have in a mature language; if you don't have a proper fix for it then you tend to end up with awful hacks instead. Consider e.g. https://www.joda.org/joda-time-hibernate/ and https://github.com/FasterXML/jackson-datatype-joda , and note how they have to be essentially first party modules, and they have to use reflection-based runtime registries with all the associated problems. And I think that these issues significantly increased the pressure to import joda-time into the JVM system library, which ultimately came with significant downsides and costs, and in a "systems" language that aims to have a lean runtime this would be even worse.

Re: An incoherent Rust

#79

Post by hrmtst93837 »

nmilo wrote: post #5

I will never stop hating on the orphan rule, a perfect summary of what’s behind a lot of rust decisions. Purism and perfectionism at the cost of making a useful language, no better way to torpedo your ecosystem and make adding dependencies really annoying for no reason. Like not even a —dangerously-disable-the-orphan-rule, just no concessions here.

[flagged]

Re: An incoherent Rust

#80

Post by Surac »

As a non Rust man, how real are the problems in this article? Does it show up in real word or is it just a edge case? I only program in C17, C++ as C with classes and C#. Anyone can give me a good read what Traits even are?
Post reply on HN