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

371–380 of 410 posts

Re: Rewriting Rust

#371

Post by lifthrasiir »

simon_o wrote: post #267
lifthrasiir wrote: post #247

Earlier quoted context omitted.

How can you be that sure? :-) It is not even like that Maven repositories don't suffer from malicious packages with confusing names (for example, [1])... [1] https://github.com/spring-projects/spring-ai/issues/537

That seems to be an absolute win to be honest. Not sure how you think this is helping your case. Maven Central people nuked the artifact that may have caused confusion, and if the owners try anything like that again, it's likely their domain will be banned from publishing.

Yes, but that's not unique to Maven because virtually all software repositories have such policies. If that's about the required amount of "moderation" you claim, I don't see how Maven can even be considered better than others.

Re: Rewriting Rust

#372

Post by adastra22 »

Measter wrote: post #329
adastra22 wrote: post #230

Earlier quoted context omitted.

We should strive for easy to learn, easy to use.

Though we should also accept that some things are just hard. Though that's not to say that we should give up on trying to make them as easy to learn and use as possible.

I don’t know. This certainly isn’t provable. What’s the difference between a something being intrinsically difficult and something for which adequate UI just hasn’t been figured out yet?

I don’t know anything that hasn’t been made simpler and easier over time.

Re: Rewriting Rust

#373

Post by adastra22 »

cogman10 wrote: post #324
adastra22 wrote: post #228

Earlier quoted context omitted.

A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand.

I disagree. Some features are more complex than others and design has little to do with that complexity. Async is a good example of a complex feature that needs a fairly detailed blog post to understand the nuances. Pretty much any language with coroutines of some sort will have 1 or many blog posts going into great detail explaining exactly how those things work. Similarly, assuming Rust added HKT, that would also r…

Languages using pure versions of the pi calculus support concurrency without any of the usual headaches.

Async is a great example of this problem. It is way more cumbersome in Rust then it could be, in a different universe where Rust concurrency made different choices.

Re: Rewriting Rust

#374

Post by cogman10 »

adastra22 wrote: post #373
cogman10 wrote: post #324

Earlier quoted context omitted.

I disagree. Some features are more complex than others and design has little to do with that complexity. Async is a good example of a complex feature that needs a fairly detailed blog post to understand the nuances. Pretty much any language with coroutines of some sort will have 1 or many blog posts going into great detail explaining exactly how those things work. Similarly, assuming Rust added HKT, that would also r…

Languages using pure versions of the pi calculus support concurrency without any of the usual headaches. Async is a great example of this problem. It is way more cumbersome in Rust then it could be, in a different universe where Rust concurrency made different choices.

> A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand.

After reading though the wiki about pi calculus and looking up the few languages that support it, I would be pretty shocked to find a language that adds a pi calculus feature wouldn't need several blog posts explaining what it is and how to understand it.

Re: Rewriting Rust

#375

Post by [deleted] »

formerly_proven wrote: post #140
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…

> Please keep Rust as lean as possible. Alternatively: Rust is already the Wagyu of somewhat-mainstream PLs, don't keep adding fat until it's inedible.

[deleted]

Re: Rewriting Rust

#376

Post by lifthrasiir »

josephg wrote: post #261
lifthrasiir wrote: post #215

Earlier quoted context omitted.

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

> 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. Yes, I do want a good programming language. I agree its relatively minor compared to the other issues I talked about in the blog post. In what way is this at odds with other aspects of the language? If its at odds with the rest of the language, why is this feature b…

Mainly a long-term consequence in teaching and readability. The RFC was accepted only after considering such trade-offs.

Re: Rewriting Rust

#377

Post by hitekker »

anonfordays wrote: post #353
hitekker wrote: post #349

Earlier quoted context omitted.

Yes, she was dating him at the time. It did not go well for Rust, https://news.ycombinator.com/item?id=28633113 https://news.ycombinator.com/item?id=28513656 Ashley is just one out of many, unfortunately. Other former and current top contributors share similar qualities. Those qualities tend to trigger unnecessary explosions like last year's https://www.reddit.com/r/rust/comments/13vbd9v/on_the_rustco... .

[flagged]

I have a few pieces of info, but they're not linkable. Not yet.

IMHO, I don't think she was trash. I think she was the face of Rust's lack of integrity, in many respects.

Re: Rewriting Rust

#378

Post by lifthrasiir »

lifthrasiir wrote: post #154
cmrdporcupine wrote: post #141

Earlier quoted context omitted.

It's frustrating because the grand-daddy of build systems with automatic transitive dependency management -- Maven -- already had tools from day one to handle this kind of thing through excluded dependencies (a blunt instrument, but sometimes necessary). In my experience, [patch] doesn't cut it or compare. That, and the maven repository is moderated. Unlike crates.io. Crates.io is a real problem. No namespaces, basic…

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

A small fix: Maven Central is not moderated by Maven developers themselves but by Sonatype [1].

[1] https://www.sonatype.com/blog/the-history-of-maven-central-a...

Re: Rewriting Rust

#379

Post by lifthrasiir »

adastra22 wrote: post #373
cogman10 wrote: post #324

Earlier quoted context omitted.

I disagree. Some features are more complex than others and design has little to do with that complexity. Async is a good example of a complex feature that needs a fairly detailed blog post to understand the nuances. Pretty much any language with coroutines of some sort will have 1 or many blog posts going into great detail explaining exactly how those things work. Similarly, assuming Rust added HKT, that would also r…

Languages using pure versions of the pi calculus support concurrency without any of the usual headaches. Async is a great example of this problem. It is way more cumbersome in Rust then it could be, in a different universe where Rust concurrency made different choices.

Do you even know what the pi calculus is? Like, you can implement the pi calculus (or the lambda calculus) by explicitly rewriting names but that's rarely done in practice. Any practical implementation would have a set of channels possibly shared by different processes and that's not very different from the free threading model with channels. By disallowing any other communciation methods you effectively end up with the actor model, was this what you were arguing for?

Re: Rewriting Rust

#380

Post by lifthrasiir »

raverbashing wrote: post #276
lifthrasiir wrote: post #121

Earlier quoted context omitted.

> The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui have been some of the most pleasant ones I've ever worked with. The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade, and I mostly dealt with C# and sometimes C++ for low-level stuffs.) Even C++ is now out of fashion for at least a…

> The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade Game programming changed a lot, parent is talking about stuff older than 10 yrs There was a lot of PC gaming in C/C++, and "Engine" were developed together with games for the most part. Think all the Doom and Quake saga That's what he's talking about

Most libraries mentioned in the GP are less than 10 years old, except for perhaps stb libraries (dates back to early 2000s). Single-header libraries are definitely a recent phenomenon, possibly inspired by stb libraries after all.
Post reply on HN