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

Rust 2024 the Year of Everywhere?

smallcultfollowing.com

Post reply on HN
Print view View original

121–130 of 206 posts

Re: Rust 2024 the Year of Everywhere?

#121

Post by kibwen »

aussiesnack wrote: post #101
kibwen wrote: post #91

Earlier quoted context omitted.

That's fair, Clap is an 800 pound gorilla of library that is trying to be heavy-duty and production-grade. But if you're just learning Rust and want to crank out a CLI for fun or education then I'd say that Clap is overkill and a distraction from learning the language itself. There are dramatically simpler libraries out there for argument parsing, e.g. https://crates.io/crates/lexopt . Heck, if I was just starting ou…

That was but one example of what I face at every single turn with Rust though. Complexity ( not conceptual difficulty) seems to be the general culturally accepted norm. I truly don't rule out that this reasonable given Rust's domain of use. But there is a general reluctance from Rust advocates to accept that it's complex, and that this complexity makes it hard to use. I do find the intense advocacy thing singularly o…

> Complexity (not conceptual difficulty) seems to be the general culturally accepted norm.

Can you give an example of what you mean by "complexity"? I think this could be an instance of people simply having different definitions.

Re: Rust 2024 the Year of Everywhere?

#122

Post by woodruffw »

kibwen wrote: post #116
woodruffw wrote: post #56

Earlier quoted context omitted.

Unsafe Rust is, in the Rust Language book's own words, a "second hidden language" within Safe Rust[1]. You're absolutely right that it's a superset; that's what makes it distinct and therefore a unique language with unique semantics (even if the syntax is nearly identical). Procedural macros can be used to define new languages within Rust, which means that grokking them requires the developer to understand their expr…

> that's what makes it distinct and therefore a unique language with unique semantics Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. Which is to say, for any given expression that compiles with Safe Rust, if you wrap that expression in an unsafe block it will have precisely the same semantics. For the book to describe it as a "second, hidden la…

> Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations.

"Allows more operations" seems like a straightforward meaning for "different semantics" to me. In Safe Rust, you can't access union members. In Unsafe Rust you can.

I agree that it's a little fanciful, but I also don't think it's really wrong.

> To suggest that this means that the language itself has infinite sublanguages obscures its actual sublanguages, such as the built-in macro-rules DSL.

In many languages, the macro language is either homoiconic or nearly homoiconic. In Crystal, for example, the macro DSL looks like normal Crystal, but with a few extra sigils. You can't invent new syntax in it.

When we talk about understanding C we generally take that to include the C preprocessor, despite the latter being a conceptually separate macro language. I think the same standard (except much, much better) applies to procedural macros in Rust: you need to understand a separate set of token production and consumption rules that interact but do not align with Rust's core syntax.

> This is a misunderstanding of the reference manual

I wasn't referring to the production rules themselves; I'm aware they're on most pages. I was referring to the fact that the attribute language is explicitly taken directly from a separate language (C#).

Re: Rust 2024 the Year of Everywhere?

#123

Post by gouda-gouda »

cercatrova wrote: post #113
verdagon wrote: post #107

Earlier quoted context omitted.

Good news! Complexity isn't a baseline requirement: it's possible to make a language that has the basic patterns and benefits of an average Rust program. It's what we're doing in Vale [0]. It turns out, they key is to move some checks to run-time [1] to reduce complexity, move other checks instead to compile-time [2] where it doesn't increase complexity, and then make the borrow checker "opt-in" instead of forcing it…

Just curious, why isn't Rust doing this currently? And could Rust adopt something similar to Vale's model?

Rust definitely has a mixture of runtime and static checks (Rc, RefCell, Arc, etc)

Re: Rust 2024 the Year of Everywhere?

#124

Post by gouda-gouda »

infogulch wrote: post #99

Every time there's a new post about 'big new features' in current or future Rust releases there's someone shouting in fear of how Rust is getting more and more complex. Rust may be complex, but 99% of newly added features have not made it more complex than the initial release. Consider a different language with three orthogonal features. You could think of its 'design space' as a cube , where each feature corresponds…

This is the right take. Nikos vision is about polishing what’s already refinement, polishing what’s already there.

Re: Rust 2024 the Year of Everywhere?

#125

Post by 3a2d29 »

xyzzy_plugh wrote: post #54
ilovecaching wrote: post #4

This is why Rust will eventually become the next C++ - it's becoming just as bloated with type theory, a cumbersome syntax, and will eventually ignite a begrudging dislike by the people that have to find a subset of the language to make sense of just to write simple programs. Everything about this language is overcomplicated by language enthusiasts. The best thing for Rust over the next few years is for it to fall to…

It already is the next C++. It's a powerful language full of incredible abstractions but sadly that attracts incredibly smart developers who worship at the altar of complexity. I enjoy rust for what it is, and I've had fun writing programs in it. You couldn't pay me to work with it in a professional capacity involving peers. I'll stick to Go, where my code reads and writes like everyone else's.

But Go can’t be used for all low level programming. Of course a GCed language is easier to read, it’s simpler at the cost of performance.

Rust complexity is more of a debate about low level programming below Go. Where only C/C++ and Rust exist. Can there be a simpler language in that space?

Re: Rust 2024 the Year of Everywhere?

#126

Post by Gigachad »

BatFastard wrote: post #46
robbintt wrote: post #14

I'm just sitting here learning c++.

I am relearning c++, much has changed in last 12 years! I tried Rust, but when doing a data driven app, I found myself using unsafe way too much!

Why are people always more afraid of unsafe than C/++? Using C++ because you had to use unsafe is throwing the whole house out with the bath water.

It’s like Rust forces people to acknowledge when they are taking things in to their own hands while C/++ let’s them live in blissful ignorance.

Re: Rust 2024 the Year of Everywhere?

#127

Post by AnimalMuppet »

3a2d29 wrote: post #125
xyzzy_plugh wrote: post #54

Earlier quoted context omitted.

It already is the next C++. It's a powerful language full of incredible abstractions but sadly that attracts incredibly smart developers who worship at the altar of complexity. I enjoy rust for what it is, and I've had fun writing programs in it. You couldn't pay me to work with it in a professional capacity involving peers. I'll stick to Go, where my code reads and writes like everyone else's.

But Go can’t be used for all low level programming. Of course a GCed language is easier to read, it’s simpler at the cost of performance. Rust complexity is more of a debate about low level programming below Go. Where only C/C++ and Rust exist. Can there be a simpler language in that space?

> Can there be a simpler language in that space?

Maybe not. The problem is that you have to have a language powerful enough to do all the things, even the things that haven't been thought of yet. That means, basically, that you have to be able to manipulate raw memory. You can't depend on a library or a language built-in, because you have to be able to write the library, and do things for which the builtin doesn't exist yet.

And then you have the problem of not blowing yourself up with that power. That comes with 1) all the danger of C, 2) all the complexity of C++, or 3) all the difficulty of the borrow checker in Rust. If a fourth language appears with the necessary power, it's going to have equivalent drawbacks.

Re: Rust 2024 the Year of Everywhere?

#128

Post by stormbrew »

jerf wrote: post #31
andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

"Is it possible to create a truly safe language without the dizzying complexity?" Yes! The good news is, they even already exist. There's even at least two variants of them: Pure immutable values (Haskell, Erlang) and languages that aren't pure functional but involve lots of little execution units that can't send mutable references between the units (Elixir, Pony) which when used even slightly properly makes unaccoun…

I don't think it's really possible to seriously consider Haskell as somehow less "dizzyingly complex" than rust unless you're already a math postgrad. I like haskell, don't get me wrong, but it is not in any way simple to write or read or work with by comparison. And while rust has some heady concepts in its design, for the most part even advanced users don't actually need to understand most of them to use it (I think this is actually rust's biggest innovation).

I do wish rust had borrowed syntactically more from haskell than C++, though.

Re: Rust 2024 the Year of Everywhere?

#129

Post by darthrupert »

nu11ptr wrote: post #66
andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

This exactly how I felt the first two times I tried it, but I never really just dove in. The third time I just dove in. The learning curve is straight up, but once you are over (took me about a month), Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely. Sure, there are a few corner cases where the type system gets hard an…

> Rust isn't really all that hard. I can write it as fast as I can write Python typically, so that friction you probably feel will go away...entirely.

I hear this a lot. Having written both, it seems to me that the only way to reasonably have this thought is that one never learned to use the repl in Python. This gives me a, say, 2-10x improvement in implementation speed, at least for exploratory-kind of coding.

Re: Rust 2024 the Year of Everywhere?

#130

Post by fulafel »

andrewstuart wrote: post #12

My theory is that every technology that is too complex gets replaced with something that does the same thing more simply. You see this relentlessly in the JavaScript ecosystem where waves of too-complex tools get rapidly replaced with something else, only to be swept away again when someone finds an even more simple way to do the same thing. This must be the fate of Rust - eventually it will be replaced with a langua…

> Is it possible to create a truly safe language without the dizzying complexity?

In Rust the complexity comes from elsewhere (eg rejecting GC), there are lots of easier languages that match the safety.

Rust is not really the paragon of safety, its guarantees are similar to easy languages like F# or even Java. And behind Ada.

Post reply on HN