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

My negative views on Rust (2023)

chrisdone.com

Post reply on HN
Print view View original

301–308 of 308 posts

Re: My negative views on Rust (2023)

#301

Post by pjmlp »

dartos wrote: post #299
pjmlp wrote: post #290

Earlier quoted context omitted.

Because ISO processes are only open to those in the know. Same applies to Ada, C, Modula-2, Pascal, Fortran, Algol, Cobol,.....

That's... what I originally said... "in the know" and "you had to be there" are effectively the same statment It's is exactly why I feel more comfortable with complexity creep in Rust as opposed to C++, since I can easily find and read the rationale for just about every feature.

No they aren't, those "in the know" have access to ISO servers, mailing lists, meeting minutes, paper votes, and related content.

Some of the public C++ stuff:

https://www.open-std.org/jtc1/sc22/wg21

Some of the public C stuff:

https://www.open-std.org/jtc1/sc22/wg14/

Some of the public Ada stuff:

https://www.open-std.org/JTC1/SC22/WG9/

And so on.

Those "in the know" have access to the stuff that is beyond that.

However that is already plenty of stuff publicly available at those https://www.open-std.org subsites as well.

Re: My negative views on Rust (2023)

#302

Post by School-Cotton »

jasomill wrote: post #300
School-Cotton wrote: post #275

Earlier quoted context omitted.

I paste the code into an invocation of sed s/^/ /

Specifically: 1. Copy code to clipboard. 2. From a shell prompt on macOS, pbpaste | sed 's/^/ /' | pbcopy Linux (Wayland), wl-paste | sed 's/^/ /' | wl-copy Linux (X11), xclip -o -se c | sed 's/^/ /' | xclip -se c Windows (PowerShell), Get-Clipboard | % { $_ -replace '^',' ' } | Set-Clipboard 3. Paste into HN.

Thanks, I didn't know about xclip -se c

I've been typing out "-selection clipboard" this whole time!

Re: My negative views on Rust (2023)

#303

Post by dartos »

pjmlp wrote: post #301
dartos wrote: post #299

Earlier quoted context omitted.

That's... what I originally said... "in the know" and "you had to be there" are effectively the same statment It's is exactly why I feel more comfortable with complexity creep in Rust as opposed to C++, since I can easily find and read the rationale for just about every feature.

No they aren't, those "in the know" have access to ISO servers, mailing lists, meeting minutes, paper votes, and related content. Some of the public C++ stuff: https://www.open-std.org/jtc1/sc22/wg21 Some of the public C stuff: https://www.open-std.org/jtc1/sc22/wg14/ Some of the public Ada stuff: https://www.open-std.org/JTC1/SC22/WG9/ And so on. Those "in the know" have access to the stuff that is beyond that. Howe…

I don’t really know what your argument is

> Those "in the know" have access to the stuff that is beyond that.

Yeah “you have to be there”

But these are all great!

It’s a shame they’re not as discoverable.

Re: My negative views on Rust (2023)

#304

Post by trealira »

Minor49er wrote: post #23
DiabloD3 wrote: post #3

I've read this before, it's been passed around the Rust community a few times. The annotated tl;dr is: Chris doesn't want to learn how hardware works, they don't want to learn how to write optimal software, they don't want to write safe software, they just want to write in a language they already know because they're not comfortable with learning other languages because their home language is a functional language (H…

Chris is a team of people? I thought he was just one developer

It is common to use "they" for singular unknown people, e.g. "Someone left their coat here."

I'm not OP, but since I don't know anyone on the Internet, I have the habit of using "they" for everybody, for example: "WildRookie? No, I don't know their real name, only that username."

It could be that OP has such a habit, which just carried over for referring to Chris, even though someone named "Chris Done" is probably a man (although, there are women who go by Chris).

Re: My negative views on Rust (2023)

#305

Post by sfink »

VeejayRampay wrote: post #9
IshKebab wrote: post #7

So much to disagree with.... > In practice, people just want to be able to write a tree-like type without having to play Chess against the compiler. Sure, Rust's strong encouragement of tree-structured ownership may be annoying when you try and make a spaghetti ownership soup, but it's not like it doesn't have upsides. Many people have written about how the ownership & borrowing rules lead to code structure that has…

I'm curious what kind of code gets a 45x speedup by going from python to rust and by that I don't mean the rhetorical or bait-style "i'm curious", no, the literal I'm curious, cause I'm trying to find use cases such as that these days and I'm often thwarted by the fact that for anything requiring remotely decent speeds, python most of the time already delegates to C extensions and so any rewrite is not as useful

My "I'm gonna learn Rust!" initial project was porting a callgraph traversal tool from Python to Rust. For loading in my input file, the speedup was very disappointing: 1x. (As in, no speedup at all.)

Then I learned about the `--release` flag and it instantly became a 40x speedup. So that was nice.

Waiting 30s vs <1s puts it well within "anything requiring remotely decent speeds". But it was really about parsing a custom data format, nothing fancy. I haven't done comparison timings of the graph traversals, but everything is basically instantaneous in the Rust version and not in the Python.

Re: My negative views on Rust (2023)

#306

Post by mwcampbell »

estebank wrote: post #261
NoGravitas wrote: post #234

Earlier quoted context omitted.

It would be interesting to me to look at something written in Python and rewritten in Rust with a 40x speed-up, and then rewrite it in something like C# or Common Lisp, and see what the speed-up is. My gut tells me the Rust implementation would use significantly less memory than the CL one, but be only minimally faster, if at all. But my gut has been known to be unreliable in the past.

When comparing a networked service that wrote to disk (a-la magic wormhole) written in Java and in Rust, after 3 iterations of improvements on the respective implementations the throughput was the same for both, CPU utilization was comparable, but memory usage was orders of magnitude lower for Rust. I think that Java will have difficulty closing the gap until project Valhalla (value types in the JVM) is completed, bu…

Is that Rust version of Magic Wormhole released?

Re: My negative views on Rust (2023)

#307

Post by estebank »

mwcampbell wrote: post #306
estebank wrote: post #261

Earlier quoted context omitted.

When comparing a networked service that wrote to disk (a-la magic wormhole) written in Java and in Rust, after 3 iterations of improvements on the respective implementations the throughput was the same for both, CPU utilization was comparable, but memory usage was orders of magnitude lower for Rust. I think that Java will have difficulty closing the gap until project Valhalla (value types in the JVM) is completed, bu…

Is that Rust version of Magic Wormhole released?

I saw some time back that a productionalized attempt came out: https://github.com/magic-wormhole/magic-wormhole.rs

The one I mentioned was much more primitive, meant as a demo (you can look at the branches for different approaches): https://github.com/estebank/rusticwormhole

Re: My negative views on Rust (2023)

#308

Post by rc00 »

steveklabnik wrote: post #216
jcranmer wrote: post #154

Earlier quoted context omitted.

> I still don't know what people mean when they talk about "having to think about memory layout" The best example I'd give is the degree to which you have to ask yourself if you want to use String or if you want to use &str--is this struct, or this function, going to own the string or borrow it from somebody else? If you're borrowing it, who is owning it? Can you actually make that work (this is really salient for pa…

> the degree to which you have to ask yourself if you want to use String or if you want to use &str In practice, there isn’t a ton of thinking to do about this: if it’s a struct, you want String. If it’s a function parameter, you want &str, and if it’s a function’s return type, you want String. Doing that until you have a reason not to is the right call 95% of the time, and 4% of that last 5% is “if the return type i…

> Google’s research says Rust is roughly as productive as any other language there, so far. That doesn’t mean it’s universally true, but it’s also some evidence it’s not universally false.

You shouldn't call this evidence but instead marketing. It was thoroughly debunked for the nonsense that it was in many places such as this: https://www.youtube.com/watch?v=vB3ACXSesGo

Post reply on HN