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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

81–90 of 319 posts

Re: A Rust shaped hole

#81

Post by [deleted] »

rich_sasha wrote: post #57
tialaramex wrote: post #46

Earlier quoted context omitted.

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

C++'s complexity is coming from how eager it is to let you shoot yourself in the foot. Rust will make you sweat blood to prove the bird in the sky you're shooting at is really not your own foot.

[deleted]

Re: A Rust shaped hole

#82

Post by wisty »

uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

I'm not at all fluent at Rust, but I think c++ is not just complex, but every c++ project is complete in a different way.

Re: A Rust shaped hole

#83

Post by eldenring »

rich_sasha wrote: post #57
tialaramex wrote: post #46

Earlier quoted context omitted.

I've seen this idea from a few people and I don't get it at all. Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis. One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a ho…

C++'s complexity is coming from how eager it is to let you shoot yourself in the foot. Rust will make you sweat blood to prove the bird in the sky you're shooting at is really not your own foot.

It's really not that bad.

Re: A Rust shaped hole

#84

Post by ignoramous »

JoelMcCracken wrote: post #55
tptacek wrote: post #33

Earlier quoted context omitted.

Their rubric is literally just 3 items: "native compilation", "abstractions", and "manual memory management". Had they put that little table at the front of the article, there wouldn't even need to be an article: the table basically says "I'm going to use Rust". That's fine!

The author really doesn't want to do manual memory management. The table is there to summarize things discussed, but he never says he wants to do manual memory management. I just went back and checked. If you do find something that indicates that, I'd appreciate you pointing it out to me, because idgi

> The table is there to summarize things discussed, but he never says he wants to do manual memory management.

  But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me.
The author wants the compiler to do memory management? How does Rust achieve this?

Re: A Rust shaped hole

#85

Post by andrewflnr »

daxfohl wrote: post #80
pragmatic wrote: post #77

Earlier quoted context omitted.

No libraries. All the niche languages have a chicken and egg problem. Only way around that is to be able to piggy back on C or JavaScript or Java.

Yeah, though when I say that I mean more like I'm surprised the ecosystem itself hasn't matured more. Rust and Go have both built solid ecosystems up from scratch, but it's a shame that OCaml hasn't since it's a nice middle ground between the two.

I really considered one of the BuckleScript/js_of_ocaml languages for my current frontend project, but went with Typescript for basically conservatism/conventionalism reasons. I was already taking some arguably unnecessary technical risks on that project and wasn't sure I could afford more. I agree that I really wish OCaml or something close to it was mainstream.

Re: A Rust shaped hole

#86

Post by bryanlarsen »

uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

Reading between the lines, the author is a Haskell fan. Haskell is another "complicated" language, but the complexity feels much different than the C++ complexity. Perhaps I would describe it as "complexity that improves expressiveness". If you like Haskell for its expressiveness but dislike C++ for it's complexity, I suspect Rust is a language you're going to like.

Re: A Rust shaped hole

#87

Post by ignoramous »

pron wrote: post #42

> And the very point of writing a native program in the first place is to make it feel solid. What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes. > realizing that I was just spawning complexity that is unrelated to the problem at hand Wait till you use Rust for a while,…

> What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes

TFA also concludes

  Since I want native code ...
I think by "solid" they mean as close to metal as possible, because, as you suggest, one can go "native" with AOT. With JS/TS (languages TFA prefers), I'm not sure how far WASM's AOT will take you ... Go (the other language TFA prefers) even has PGO now on top of "AOT".

Re: A Rust shaped hole

#88

Post by renewiltord »

jlokier wrote: post #52
tux3 wrote: post #7

>To paraphrase Norvig's Latency numbers a programmer should know, if we imagine a computer that executes 1 CPU instruction every second, it would take it days to read from RAM. It's a detail, but this is a little bit off. RAM latency is roughly around ~100ns, CPUs average a couple instructions per cycle and a few cycles per ns. Then in the analogy, a stall on RAM is about a 10 minute wait; not quite as bad as losing…

In current machines, that's way off depending on how you choose to count "1 CPU instruction" for the metaphor. Take Apple's latest laptops. They have 16 CPU cores, 12 of those clocking at 4.5 GHz and able to decode/dispath up to 10 instructions per cycle. 4 of those clocking at 2.6 GHz, I'm not sure about their decode/dispatch width but let's assume 10. Those decoder widths don't translate to that many instructions-p…

This seems like the classic 9 women making a baby in 1 month. Even if the CPU can execute 824 instructions per nanosecond, it can't execute 1 instruction in 1/824 nanoseconds. You can't mix throughput and latency like that.

Re: A Rust shaped hole

#89

Post by bryanlarsen »

uecker wrote: post #45
dijit wrote: post #24

Earlier quoted context omitted.

You’re right that Rust is a ball of complication. I am a fan of Rust but it’s definitely a terse language. However there are definitely signs that they have thought about making it as readable as possible (by omitting implicit things unless they’re overwritten, like lifetimes). I’m reminded also about a passage in a programming book I once read about “the right level of abstraction”. The best level of abstraction is…

I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step. For C++ this is much more painful because all the tools invented to make the code look concise make it extremely hard to follow and change. From the feature set, I would say that Rust is the same (but I have no experience refactoring Rust code).

> but I have no experience refactoring Rust code

But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible experience to worry so little about unknown side-effects.

Re: A Rust shaped hole

#90

Post by steveklabnik »

ignoramous wrote: post #84
JoelMcCracken wrote: post #55

Earlier quoted context omitted.

The author really doesn't want to do manual memory management. The table is there to summarize things discussed, but he never says he wants to do manual memory management. I just went back and checked. If you do find something that indicates that, I'd appreciate you pointing it out to me, because idgi

> The table is there to summarize things discussed, but he never says he wants to do manual memory management. But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me. The author wants the compiler to do memory management? How does Rust achieve this?

The compiler works with you to ensure that you’re not misusing memory. If you make a mistake, it will let you know.

You’re not often manually managing memory in the same sense as other low-level languages. You’re not invoking malloc and free directly. Thanks to ownership, when you do allocate, Rust will call free for you.

It’s somewhere in between fully manual and fully automatic. It can feel more like one or the other based on what you’re doing, but most of the time, in average, it feels like automatic.

Post reply on HN