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

81–90 of 175 posts

Re: An incoherent Rust

#81

Post by ifwinterco »

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.

And then someone declares "this language is a mess! I'll take the good parts and create a new one without all this cruft!" and the cycle continues

Re: An incoherent Rust

#82

Post by boardwaalk »

bitbasher wrote: post #62

I used Rust for ~14 months and released one profitable SaaS product built entirely in Rust (actix-web, sqlx, askama). I won't be using Rust moving forward. I do like the language but it's complicated (hard to hold in your head). I feel useless without the LSP and I don't like how taxing the compiler and LSP are on my system. It feels really wasteful to burn CPU and spin up fans every time I save a file. I find it har…

Those dependencies pretty quickly reveal themselves to be complicated and heavy. I wouldn’t blame Rust for that. I rarely need more than what workspaces and VCS based deps give me, but when I have, putting up and using a non-official registryis pretty easy.

Re: An incoherent Rust

#83

Post by antonvs »

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. It’s why languages whose names start with C feature so prominently on CVE lists.

Re: An incoherent Rust

#84

Post by poppadom1982 »

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…

I'm not sure what you're getting at but

const bool z = (const bool)((int8_t)2);

Is perfectly valid C++.

Re: An incoherent Rust

#88

Post by swiftcoder »

Surac wrote: post #80

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?

> As a non Rust man, how real are the problems in this article?

Real, but of more concern to folks designing widely-used libraries than to folks using said libraries.

> Anyone can give me a good read what Traits even are?

You can think of traits as analogous to interfaces in OOP languages (i.e. pure virtual abstract classes in C++ terminology).

They just define a set of methods that types can implement to conform to the trait, and then consumers can treat implementing types as if they were the trait.

The major differences are: traits are implemented outside the actual type implementation, so arbitrary trait implementations can be added after the type has been written (this is why we need coherence), and rust uses traits as compile-time bounds for generics (templates).

Re: An incoherent Rust

#89

Post by debugnik »

poppadom1982 wrote: post #84
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…

I'm not sure what you're getting at but const bool z = (const bool)((int8_t)2); Is perfectly valid C++.

That's a conversion, not the same. The naive equivalent to transmute would be

    int8_t x = 2;
    bool y = *reinterpret_cast(&x);
But reinterpret_cast isn't valid in a constexpr scope.

Re: An incoherent Rust

#90

Post by germandiago »

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.

Use static analyzers and move on. Almost all the complaints I see about C++ nowadays are removed by max warning levels. Set them as error.

Certainly initialization is the single most confusing feature in C++, I can give you that.

But still doable with s few patterns to remember. And warnings always max level.

Post reply on HN