Live data from Hacker News

Why Rust?

rerun.io

71–80 of 294 posts

Re: Why Rust?

#71
post #12

> Rust's enums and exhaustive match statement are just amazing ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.

> we'll look back and see them as the key paradigm shift of this era. You mean the key paradigm shift of the 1970s when they were invented. Only took 50 years for it to go semi-mainstream.

Going mainstream is the paradigm shift.

OOP was invented in the 60s/70s, but the paradigm shift came in the 80s/90s.

Re: Why Rust?

#72
post #49

Earlier quoted context omitted.

It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. If you manage to land on the 1/100 that actually does something useful and survives, well, better odds than the lottery I suppose.

Sounds a lot like Silicon Valley circa. 1999

That's my feeling, you might pick the company that becomes the google of crypto, or you might end up in one of the ones you haven't even heard about because they disappeared without a trace.

Re: Why Rust?

#73
post #16

Earlier quoted context omitted.

Scala, Kotlin, Haxe, Swift, and several others. The search term you want is "Algebraic Data Types" Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly.

> Erlang has the superpowered version of this - binary pattern matching, that lets you pattern match on a bitstream directly. Erlang has a super-powered version of the pattern matching bit, but not of what GP actually likes about it: > you have to handle every case whenever you're matching on it because Erlang is dynamically typed. So partial patterns are acceptable, and not entirely uncommon.

You can use partial patterns in Rust too. I think perhaps you meant partial matches?

Re: Why Rust?

#74
> There is of course some legitimate worry that the Rust crate ecosystem could devolve into the crazy left-pad world of npm, and it is something to be wary about, but so far the Rust crates keep an overall high quality.

Note that the particular case of left-pad cannot happen with crates.io/cargo, because once published, you cannot unpublish a crate. You can 'yank' it, in which case it will not be resolved by Cargo.toml, but if you put it in Cargo.lock directly (IIUC) it will still work. So we can't have someone pulling a crate and crashing half the ecosystem.

We can however still have lots of other problems that plague all package management systems. Check out `cargo-crev`!!!! It's an awesome idea I'm always plugging to solve the lack of trust in an open library repository. It requires people to participate though.

Re: Why Rust?

#75
Honestly, this kind of breathless adulation is off-putting to me.

> If I'm honest, the main reason is because I love Rust.

That's nice if it works for you, but I'm looking to build and maintain software well and efficiently. I don't want a programming language I can love I want a tool. (BTW, old and tired but true: don't love things that can't love you back.)

Re: Why Rust?

#77
post #33

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,... Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust cod…

>I wonder why, doing Windows programming with OWL in 1993 was quite delightful,

For me, it's because memories are not trustworthy (rose-colored glasses). Also, I had less experience back then. And we as an industry didn't know any better.

I got started in programming in Borland Pascal and Borland C++. Because of nostalgy, I've tried using them for fun again ten years ago and boy is there a reason I stopped using them in the first place. Sheesh.

Example OWL snippets:

  for (int index = 0; index  buf(new tchar[len+1]);
    GetString((tchar*)buf, index);
    *outStream SendMessage(WM_COMMAND, DB_BTGAST, 0);
    TEdit::EvKillFocus(hWnd);
  }
^-- I liked THAT? What was wrong with me ;)

That said, Borland had really good class libraries. If I had those libraries in a modern language, hey that wouldn't be so bad. But these languages? No, thank you.

Re: Why Rust?

#78

Earlier quoted context omitted.

Quoted post unavailable.

In which way is that incorrect? How can you, when reading Python code, know whether it may error? Or is your point that Rust code can panic too, without it being clear from reading the code?

Except for the maybe simplest variable initialization, I always assume that if it exists, it may error. “Won’t error ever” doesn’t exist in the real physical world.

(See also: halting problem.)

The “invisibility” of errors in languages that have first-class exceptions usually means that exceptions are being somehow swallowed without being handled properly. Shit happens, and the program happily chugs along regardless, sowing destruction.

If you get down to reading the code, you can usually see if it is likely to error out or not. At the point where you get down to reading the code, it’s usually quite clear unless intentionally obfuscated.

A better question is, can a machine show you if the code may error and how, given language X? In statically compiled languages, IDEs have been wickedly good at inferring the possible exception types on any line of code for the last decade, even if you don’t annotate them in the signature.

Re: Why Rust?

#79
post #12

> Rust's enums and exhaustive match statement are just amazing ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.

This. I have no idea why people underestimate the conceptual power of ADTs. Every time I try to explain this concept they just disregard it as just a convenient wrapper over union...and union isn't THAT common right..?

Turns out that having a much better tagged union opens up so many possibilities. Software deals with states and what's better to represent states than an ADT? Last time I was fixing an issue where a mouse position is initialized to (0.0f,0.0f) and causes it to trigger a mouse event on startup. The fix was to simply turn it into an Option which is so much better than initializing them as (-1.0f,-1.0f) because it forces you to check all the places where you do arithmetic operations on them.

Post reply on HN