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

Rewriting Rust

josephg.com

Post reply on HN
Print view View original

211–220 of 410 posts

Re: Rewriting Rust

#211

Post by lifthrasiir »

pas wrote: post #206
lifthrasiir wrote: post #154

Earlier quoted context omitted.

> In my experience, [patch] doesn't cut it or compare. AFAIK what Maven does is an exclusion of dependency edges , which is technically an unsafe thing to do. Cargo [patch] is a replacement of dependency vertices without affecting any edges. (Maven surely has a plugin to do that, but it's not built-in.) They are different things to start with. Also I believe that the edge exclusion as done by Maven is (not just "tech…

namespaces are a solution to having "authenticated groups of crates", it helps structuring and more importantly restructuring crates.

That's an intention, not the outcome. You might assume that having both `@chrono/chrono` and `@chrono/tz` shows a clear connection between them, but such connection is nothing to do with namespace (the actual crate names are `chrono` and `chrono-tz`), and any authority provided by `@chrono/` prefix is offseted by the availability of similar names like `@chrno/tz` or `chrono-tz`. The only thing namespace can prevent is names starting with the exact prefix of `@chrono/`, and that's not enough.

Re: Rewriting Rust

#212

Post by gary17the »

goodpoint wrote: post #195
gary17the wrote: post #138

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new "features" to the PL, in order to prevent the "language surface" from being bloated, inconsistent and unpredictable. I've seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it…

> Good ideas are "dime a dozen". Please keep Rust as lean as possible. Good ideas are rare and precious by definition.

I think it would be helpful to clearly distinguish between "good ideas" and "excellent ideas". It's relatively easy in the complex art of programming to come up with a dozen good ideas. It seems very hard in the complex art of programming to come up with even one truly excellent idea.

Re: Rewriting Rust

#213

Post by TwentyPosts »

chrisco255 wrote: post #76
simonask wrote: post #65

Earlier quoted context omitted.

I'm curious, what drama in the Rust community are you referring to? I see some drama associated with Rust, but it's usually around people resisting its usage or adoption (the recent kerfuffle about Rust for Linux, for example), and not really that common within the community. But I could be missing something? Zig is great, but it just isn't production ready.

On drama: https://users.rust-lang.org/t/why-is-there-so-much-mismanage... Also, Zig is set to release 1.0 beta in November.

Zig is not even close to a 1.0 beta this year. Or even next year.

For example, the async problem still exists and still has absolutely no viable path forward, or even MVP approach.

Re: Rewriting Rust

#214

Post by mwcampbell »

> a fully baked language - warts and all. Python 2.7 for life.

I still wish the Python core team had abandoned the Python 3 experiment and gone with Python 2.x for life, warts and all. I learned to work with the warts, including the Unicode ones. I think a lot of us did.

Re: Rewriting Rust

#215

Post by lifthrasiir »

josephg wrote: post #196
lifthrasiir wrote: post #159

Earlier quoted context omitted.

I personally use two conditionals for such case. Yes, I might have written Rust too long to say this but it is more like a minor ergonomic fix and any solution should be generalizable into other use cases. The eventually accepted syntax, `if let PAT = EXPR {&& EXPR}` [1], is okay by itself but not (yet) generalized and that's my current complaint about it. The whole `{let PAT = EXPR &&} EXPR` should have been a valid…

> I personally use two conditionals for such case. Me too. But that often makes my logic worse. Its quite common to want to share the same code in the else branch, for example: if let Some(val) = opt { if expr { // .... } else { do_complex_stuff(); } } else { do_complex_stuff(); } I don't want to copy+paste that complex code in two places. And you can fix that in turn with a named block & named break statements or a…

I'm worried that you want a "good" language at any circumstance, which is not even generally possible but also at odds with other aspects of languages. This still counts as minor for me because it is just slightly annoying and doesn't make something impossible or much harder to read (and the readability varies enough that this threshold is much higher than this case).

Re: Rewriting Rust

#216

Post by rowanG077 »

mirashii wrote: post #165
lostmsu wrote: post #150

Earlier quoted context omitted.

Regex one stands out as a negative example here. Why does it have to be built-in instead of exposing a str -> bool filter lambda?

Now you need a general purpose embedded language interpreter to express your filter lambda? I'm not sure you've really made anything simpler.

I don't see why you want an embedded interpreter for this. Can you explain?

Re: Rewriting Rust

#217

Post by mwcampbell »

josephg wrote: post #158
eterevsky wrote: post #106

I would gladly switch to a Rust fork without async. Even though this article is not about async per se, it’s clear that async makes most of the described problems worse.

Author here. I think async is a great feature to have - but I can't help but wonder if you're right. It might just be case of timing, but it seemed like once async was in the works, work on the rest of the language ceased. For awhile there all energy was poured into bikeshedding over how async would work. And I don't know if anyone is super happy with the result. Pin is a mess. Async functions still return anonymous…

> If we could go back in time and have the rust project decide to never implement async, I wonder what rust would look like today.

If withoutboats is right [1], then Rust would never have received the industry backing to be as successful as it is now.

[1]: https://without.boats/blog/why-async-rust/ especially the section "Organizational considerations"

Re: Rewriting Rust

#218

Post by adwn »

withoutboats3 wrote: post #190
josephg wrote: post #171

Earlier quoted context omitted.

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b…

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to…

> Your commentary on Pin in this post is even more sophomoric than the rest of it and mostly either wrong or off the point. I find this quite frustrating, especially since I wrote detailed posts explaining Pin and its development just a few months ago.

To me, this sounds as if the Pin concept is so difficult to understand that it's hard to even formulate correct criticism about it.

I get that Pin serves a critical need related to generators and async, and in that it was a stroke of genius. But you as the creator of Pin might not be the right person to judge how difficult Pin is for the more average developers among us.

Re: Rewriting Rust

#219

Post by cogman10 »

varjag wrote: post #120
joatmon-snoo wrote: post #78

Earlier quoted context omitted.

Good file watching that provides flexible primitives absolutely requires: - ok, a single ext4 file inode changes, and its filename matches my hardcoded string - oh, you don’t want to match against just changes to “package.json” but you want to match against a regex? voila, now you need a regex engine - what about handling a directory rename? should that trigger matches on all files in the renamed directory? - should…

Are you 100% sure all these cases are handled by cargo-watch?

Yup. Every user facing case mentioned has a corresponding flag. The non-user facing stuff, like being cross platform, is common sense.

https://crates.io/crates/cargo-watch/8.5.2

Re: Rewriting Rust

#220

Post by Zagitta »

skywal_l wrote: post #64
armitron wrote: post #44

Earlier quoted context omitted.

This is the main reason we have banned Rust across my Org. Every third party library needs to be audited before being introduced as a vendored dependency which is not easy to do with the bloated dependency chains that Cargo promotes.

The dependency hell issue is not directly related to Rust. The Rust language can be used without using any dependency. Have you banned javascript and python too?

And in a similar vein have they audited the runtimes of all the languages they use? Because those a dependencies too and in many ways even more critical than libraries.
Post reply on HN