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

361–370 of 410 posts

Re: Rewriting Rust

#361

Post by pas »

SkiFire13 wrote: post #117
gyre007 wrote: post #50

One of the things that hit me when I was picking up Rust was that I felt like it had every imaginable feature one could think of - I dont know if Rust team said no to anything (yes I know they obviously must’ve done) - and yet people wanted more and more (some justifiably, others less so) as the language “felt” incomplete or that the features thatd be used by 2% of devs are totally necessary in the language that is “…

You'll be surprised by the amount of features that are often proposed by random people and are then rejected by the Rust community. Rust is definitely not trying to add all possible features, though you might get that feeling when you look at some feature like GATs and TAITs without having a clear idea of what problems they solve. Also, Zig might be a nice modern language, but it is not an option if you're aiming for…

GAT solves typing problems (by making a subset of HKT possible)

Re: Rewriting Rust

#362

Post by josephg »

jcranmer wrote: post #328
josephg wrote: post #239

Earlier quoted context omitted.

> The obvious examples you want to use work fine, but the feature needs to be designed in such a way that the language remains internally consistent and works in all edge cases. True. How long should that process take? A month? A year? Two years? I ask because this feature has been talked about since I started using rust - which (I just checked) was at the start of 2017. Thats nearly 8 years ago now. 6 years ago this…

> True. How long should that process take? A month? A year? Two years? If you want a feature that everyone complains about, like Pin or async rust, yes, that is how long that process should take. If you don't want a feature that everyone uses as their stock example for why language designers are drooling morons, and the feature has any amount of complexity to it, then the process should probably take over a decade. T…

> before launching into detailed criticism of a feature that most agree is (at least in part) the result of Rust moving too quickly.

Is Pin the result of moving too quickly? Maybe.

Personally, I’m not convinced that it’s generally possible to explore the design space properly by having long conversations. At some point, you have to ship. Figure out if it’s a good idea with your feet. Just like pin did.

I don’t claim to be smarter than anyone on the rust team who worked on this feature before it was launched. Only, now it’s launched and people have used it, I think we should go back to the drawing board and keep looking for other approaches.

Re: Rewriting Rust

#363

Post by nineteen999 »

Joeboy wrote: post #161
simonask wrote: post #110

Earlier quoted context omitted.

Who is "they"? Seriously, who?

Well, if you work on security-critical software that's currently written in a memory-unsafe language, I would say that's a good candidate for a Rust rewrite. Likewise if you work on a widely used library that's awkwardly slow because it's written in python. Which is not exactly the same as wanting everybody to rewrite everything in Rust, but I suppose it's the sort of thing that annoys nineteen999. There are also a l…

It's a good candidate for a rewrite in a memory-safe language, of which is Rust but one. Some people don't like the Rust syntax, the cargo ecosystem's resemblence to npm, the gulf between what's in stable vs nightly rust (ie. ISO standardization might be nice to consider at this point), personal attacks on experienced C/C++ programmers by well-meaning but junior devs in the Rust community who would be better served (re)writing stuff to prove their point rather than evangelizing so much. Some us also find the sensitivity to any kind of criticism of these aspects a little amusing, so we occasionally poke fun in return.

There are still plenty of constrained environments, architectures not yet supported, a lack of mature libraries for 2D/3D graphics amongst other things, that make Rust not a good fit yet for many projects where C/C++ already works. When Rust gets there and it and it's community matures a bit, we will all cheer. Until then ... we'll just get back to work.

Re: Rewriting Rust

#364

Post by throwitaway1123 »

dartos wrote: post #360
throwitaway1123 wrote: post #343

Earlier quoted context omitted.

> Look at the dependency tree for a next Looks ok to me: https://npmgraph.js.org/?q=next Ironically, most of the dependencies are actually Rust crates used by swc and turbopack [1][2]. Try running `cargo tree` on either of those crates, it's enlightening to say the least. And of course, Node has a built in file watcher, and even the most popular third party package for file watching (Chokidar) has a single dependency…

Not sure what npmgraph is doing exactly, but there are more dependencies than that. React is a dependency of every next application, but I don’t see it there. Maybe next, the singular package, has fewer dependencies than a project made with next.

React and react-dom are peer dependencies (npmgraph lists them but doesn't graph them visually). The actual full installation command is: `npm install next@latest react@latest react-dom@latest`[1]. Even if you include react and react-dom, the dependency graph still looks tolerable to me: https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%...

[1] https://nextjs.org/docs/getting-started/installation#manual-...

Re: Rewriting Rust

#365

Post by josephg »

dgroshev wrote: post #319
josephg wrote: post #313

Earlier quoted context omitted.

> - Comparing apples and oranges. For example, Box makes pinning trivial (you can just move in and out of Pin no problem), but oftentimes people new to Rust try to prematurely optimise and eliminate a single pointer lookup. If that's the case, were you really writing the same thing in JS and in Rust? Pointer lookups are cheap-ish, but allocating can be extremely expensive if you do it everywhere. I've seen plenty of…

Every single JS future is boxed. Moreover, they aren't just boxed, they are often backed by a hashmap (which may or may not be optimised away by the JIT). Elaborate allocation-free async is not an apple-to-apples comparison. JS does support concurrent execution, Promise.all is an example. Without it, JS async would make little sense. The problem very much exists there, and try-catch is only a surface-level answer. As…

Honestly I’m not really sure what you’re arguing here. Are you agreeing or disagreeing that solving this problem in rust is currently significantly more complex than solving it in JavaScript? I already told you I implemented error handling just fine in JavaScript. Do you think I’m lying? Do you want to see the code, so you can grade it?

The apples-to-apples comparison I’m making here is: “I sit down at my computer with the goal of solving this problem using code. How long before I have a robust solution using the tool at hand?”. Of course the internals of rust and JavaScript’s Future/promise implementations are different. And the resulting performance will be different. That’s what makes the comparison interesting.

It’s like - you could say it’s an apples to oranges comparison to compare walking and driving. They’re so different! But if I want to visit my mum tomorrow, I’m going to take all those variables into account and decide. One of those choices will be strictly better for my use case.

Rust came off terribly in the comparison I made here. I love rust to bits in other ways, but dealing with async streams in rust is currently extremely difficult. Even the core maintainers agree that this part of the language is unfinished.

Re: Rewriting Rust

#367

Post by rowanG077 »

mirashii wrote: post #352
rowanG077 wrote: post #339

Earlier quoted context omitted.

Why would you evaluate it using an interpreter? Since you are using it in the context of a rust lambda you compile it. You just have a rust file that calls cargo-watch as a library. Crafting an interpreter seems like an incredibly bad idea.

But now you have to know at compile time what you're watching, which is not what cargo-watch or any of the similar commands like entr do.

Considering you have a rust file and the dependency why wouldn't you compile it? It's not like rustc is not available when you are using cargo-watch.

Re: Rewriting Rust

#368

Post by withoutboats3 »

nazka wrote: post #356
withoutboats3 wrote: post #264

Earlier quoted context omitted.

I don't deny that Pin is complicated to use as it stands (in fact that is the entire thrust of my blog posts!), just that there is some magical easier solution involving Move and changes to the borrow checker. You wrote something on the back of a napkin and you imagine its better, whereas I actually had to ship a feature that works. The state of async Rust is not better because no one hired me to finish it past the M…

Modzilla not hiring you is just crazy. Love the work you do! In my view among the bests there is Dan for React and your one of them for Rust. :) God bless you

I did work at Mozilla; I stopped contributing to Rust after Mozilla stopped funding the project.

Re: Rewriting Rust

#369

Post by orf »

Arch-TK wrote: post #326
lifthrasiir wrote: post #188

Earlier quoted context omitted.

> There's no standard way of doing file watching across BSDs, Mac OS and Linux. You are correct, but that's about the only divergence matters in this context. As I've noted elsewhere, you can't even safely use `char*` for file names in Windows; it should be `wchar_t*` in order to avoid any encoding problem. > Are you referring to the clear feature? Yes, it's fixed. It's also pretty standard in that regard. At the ver…

> As I've noted elsewhere, you can't even safely use `char ` for file names in Windows; it should be `wchar_t ` in order to avoid any encoding problem. Yes, this is true. But I think the overhead of writing that kind of code would not be as enormous as 30k lines or anything in that order. > At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). Maybe. I…

> But neither of us has time for that.

Indeed, so why waste it reinventing the wheel instead of using a high quality third party package?

Or arguing about highly suspect LoC numbers pulled out of thin air as if it’s not an apples-to-oranges comparison, for that matter.

Re: Rewriting Rust

#370

Post by lifthrasiir »

Arch-TK wrote: post #326
lifthrasiir wrote: post #188

Earlier quoted context omitted.

> There's no standard way of doing file watching across BSDs, Mac OS and Linux. You are correct, but that's about the only divergence matters in this context. As I've noted elsewhere, you can't even safely use `char*` for file names in Windows; it should be `wchar_t*` in order to avoid any encoding problem. > Are you referring to the clear feature? Yes, it's fixed. It's also pretty standard in that regard. At the ver…

> As I've noted elsewhere, you can't even safely use `char ` for file names in Windows; it should be `wchar_t ` in order to avoid any encoding problem. Yes, this is true. But I think the overhead of writing that kind of code would not be as enormous as 30k lines or anything in that order. > At the very least it should have checked for TTY in advance. I'm not even interested in terminfo (which should go die). Maybe. I…

> It's an explicit option you must pass. It's often useful to be able to override isatty decisions when you want to embed terminal escapes in output to something like less. But for clear it's debatable.

In terms of UX it's just moving the burden to the user, who may not be aware of that problem or even the existence of `-c`. The default matters.

> I treat any amount of color as spamming when alternative options exist. Colours are useful for: syntax highlighting, additional information from ls. Not for telling you that a new line of text is available for you to read in your terminal.

I'm a bit more lenient but agree on broad points. The bare terminal is too bad for UX, which is why I'm generous about any attempt to improve UX (but not color spamming).

I'm more cautious about emojis than colors by the way, because they are inherently colored while you can't easily customize emojis themselves. They are much more annoying than mere colors.

> It also has many features that cargo-watch doesn't. If you wanted something cargo specific you could just write something specific to that in not very much code at all. The point is that the combination of jq and entr can do more than cargo-watch with less code.

I think you have been sidetracked then, as the very starting point was about cargo-watch being apparently too large. It's too large partly because of bloated dependencies but also because dependencies are composed instead of being inlined. Your point shifted from no dependencies (or no compositions as an extension) to minimal compositions, at least I feel so. If that's your true point I have no real objection.

> I hope you can agree that no number of millions of lines of code can fix JSON being trash. What would solve JSON being trash is if people stopped using it. But that's also not going to happen. So we are just going to have to deal with JSON being trash.

Absolutely agreed. JSON only survived because of the immense popularity of JS and good timing, and continues to thrive because of that initial momentum. It's not even hard to slightly amend JSON to make it much better... (I even designed a well-defined JSON superset many years ago!)

Post reply on HN