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

My “grand vision” for Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

181–190 of 323 posts

Re: My “grand vision” for Rust

#181

Post by tormeh »

QuantumNoodle wrote: post #94

I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…

Nothing can really save you from architecture astronauts, except possibly Go, but I hear there are people templating Go with preprocessors, so who knows. This is a human problem. On the other hand I hear you. The moment Rust gets proper async traits an entire world of hexagonal pain will open up for the victims of the astronauts. So it will get even worse, basically. I think if we could solve the problem of bored smart people sabotaging projects it'd be amazing.

Re: My “grand vision” for Rust

#182

Post by pjmlp »

ChrisSD wrote: post #96
pjmlp wrote: post #80

Earlier quoted context omitted.

Exactly, hence why people should stop talking about editions as if they sort out all Rust evolution problems, in your own words it doesn't allow changing type semantics

I think you're too stuck on the current implementation. Work is going into investigating how to evolve the standard library over editions. The "easiest" win would be to have a way to do edition-dependent re-exports of types.

What I am stuck is Rust folks advocating editions as the solution for everything in language evolution, when it clearly isn't.

Re: My “grand vision” for Rust

#183

Post by ozgrakkurt »

beanjuiceII wrote: post #89
plantain wrote: post #85

I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right. Do these people ever ship anything? Or is it just endless rearranging of deckchairs?

I already need a reference to read rust code, looks like I'll need a third reference sheet. The language is currently bordering on spaghetti

The most annoying part is that you can't just go to source code or docs and understand some code. I still can't do it after spending many years using it. You have to wade through 7 layers of macros and traits to understand some basic thing most of the time.

It is easier to understand musl-libc code compared to understanding a http library in rust which is just insane to me.

Re: My “grand vision” for Rust

#184

Post by pjmlp »

aw1621107 wrote: post #98
pjmlp wrote: post #81

Earlier quoted context omitted.

Exactly because they don't allow it, they don't cover all scenarios regarding language evolution

OK, sure, but again what breaking changes editions do/don't currently allow is independent from what SkiFire13/I was responding to, which was the "requires full access to source code" bit.

How do you expect a compiler to be able to mix and match changes across editions between crates, if those happen to be changes in semantic behaviour?

Re: My “grand vision” for Rust

#185

Post by spockz »

rapnie wrote: post #145
sam0x17 wrote: post #127

Earlier quoted context omitted.

I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…

Perhaps there are similarities to Scala, from my anecdotal observation. Coming from Java and doing the Scala coursera course years ago, it feels like arriving in a candy shop. All the wonderful language features are there, true power yours to wield. And then you bump into the code lines crafted by the experts, and they are line for line so 'smart' they take a real long time to figure out how the heck it all fits toge…

At least from what I’ve seen around me professionally, the issue with most Scala projects was that developers started new projects in Scala while also still learning Scala through a Coursera course, without having a FP background and therefore lacking intuition/experience on which technique to apply when and where. The result was that you could see “more advanced” Scala (as per the course progression) being used in newer code of the projects. Then older code was never refactored resulting in a hodgepodge of different techniques.

This can happen in any language and is more indicative of not having a strong lead safeguarding the consistency of the codebase. Now Scala has had the added handicap of being able to express the same thing in multiple ways, all made possible in later iterations of Scala, and finally homogenised in Scala 3.

Re: My “grand vision” for Rust

#186

Post by pjmlp »

plantain wrote: post #85

I used to hate Golang for not having generics and how verbose getting basic things done was. Then I read posts like this and realise, my god, Rob Pike was so, so right. Do these people ever ship anything? Or is it just endless rearranging of deckchairs?

I mostly agree, however it wouldn't harm Go, even to get back some of the niceties of Limbo that it still misses.

Re: My “grand vision” for Rust

#187

Post by pjmlp »

phplovesong wrote: post #67

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

Not sure who pushed async Rust, but at least async JS does work without having to hunt down for runtimes, and naturally the answer is always Tokio.

Re: My “grand vision” for Rust

#188

Post by pjmlp »

simonask wrote: post #79
phplovesong wrote: post #67

async rust is the worse async out there. I prayed that rust did not include a async at all. But the JS devs pushed it thru. That pretty much sealed my rust use. Im still salty.

You know what, I’ve heard people say this and thought “OK, maybe these other languages with GCs and huge runtimes really do something magical to make async a breeze”. But then I actually tried both TypeScript and C#, and no. Writing correct async code in those languages is not any nicer at all. What the heck is “.ConfigureAwait(false)”? How fun do you really think debugging promise resolution is? Is it even possible…

Unless you are writing GUI code, ConfigureAwait() shouldn't be on your source code.

Re: My “grand vision” for Rust

#190

Post by Ygg2 »

pjmlp wrote: post #178
Ygg2 wrote: post #57

Earlier quoted context omitted.

Doubt Rust will ever get to implicit hell of Scala 2. If for anything, Rust isn't married to C as Scala is to Java.

It certainly is in what concerns ABI support, and dependency on LLVM.

Scala had an unnatural dependency on Java, not JVM. I.e., imitating not just some patterns but copying its flawed interfaces. For example, Scala could express and bypass decades of cruft in the Java Collections API. Did it choose to do it?

To paraphrase former Scala developer and present poker player, "If Java cut its nose, would you Scala... Oh god, stop! The blood, the blood!"

Everyone who wants to talk to low-level code has to have C ABI. The equivalent Scalaism in Rust would be if Rust reimplemented the C-inspired java.util.Date. Yes. Monday should be 0, not an enum. Because C did it.

Post reply on HN