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

Rust – A hard decision pays off

pinecone.io

Post reply on HN
Print view View original

301–310 of 386 posts

Re: Rust – A hard decision pays off

#301

Post by [deleted] »

nomel wrote: post #170
throwaway894345 wrote: post #154

Earlier quoted context omitted.

Agreed, but I think people make too big a deal about iterators. The simple for loops that they’re fit to replace aren’t that hard to read or write, so they aren’t causing real problems, and on the more complex end you’re writing imperative stuff anyway. Iterators certainly aren’t a bad thing, but they’re not the game changer that Go-critics made them out to be in all of the Rust-vs-Go debates.

I disagree. If I can avoid an index variable, I’m going to have less bugs since I won’t have to index.

[deleted]

Re: Rust – A hard decision pays off

#302

Post by [deleted] »

rustinquisition wrote: post #297
andrewxdiamond wrote: post #295

Earlier quoted context omitted.

> The unique safety features of Rus are all about memory safety, which is not something you have to worry about at all in Python Rust gets safety with its ownership system. The ownership system brings strong guarantees around who is mutating / reading any given object. Python has uncontrolled ownership. Any function can generally mutate / store any variable you pass in. This can definitely cause bugs if a rouge funct…

Quoted post unavailable.

[deleted]

Re: Rust – A hard decision pays off

#303

Post by MauranKilom »

nomel wrote: post #298
throwaway894345 wrote: post #244

Earlier quoted context omitted.

But earlier you claimed the for-loop version required index variables and indexing into iterators/vectors/etc ... ?

I clearly said the opposite, in response to, what appeared to be, your suggestion that indexing isn't so bad: "I think people make too big a deal about iterators. The simple for loops that they’re fit to replace aren’t that hard to read or write, so they aren’t causing real problem"

It seems like you imply that iterators = range-for and "simple loops" = indexing, which is clearly not what the previous poster has in mind (which was "range-for = imperative loops, iterators = functional style, simple loops = trivial loop body").

Re: Rust – A hard decision pays off

#304

Post by Already__Taken »

0x457 wrote: post #261
throwaway894345 wrote: post #120

Earlier quoted context omitted.

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Oth…

Iterator-chain version would be a lot better looking if it was actually was a chain and not everything pushed into a single `filter_map`. "Ifs" are weird looking, one branch is using `entry`(I take it's a `DirEntry`?) and another is using `file_name` I suspect both could use the and look like `Self::is_` ? If you're going to write an iterator chain in an imperative way, then you might as well right it imperatively. A…

Forgive me for asking instead of looking, I'm still getting into rust; why do you map instead of getting the result?

    path.extension().map(|ext| ext == "bundle").unwrap_or(false)
vs

    (path.extension() == "bundle").unwrap_or(false)
or further up

    .map(|e| e.map(|e| e.path()))
    vs
    .map(|e| e.path())
Is the .map keeping any value wrapped in an iterator so you can map again? I thought it was interesting what you wrote looks a lot like what I'd write in powershell.

Re: Rust – A hard decision pays off

#305

Post by ekidd »

throwaway894345 wrote: post #51
FartyMcFarter wrote: post #45

Earlier quoted context omitted.

If people only used Python as originally intended (as a language to write small scripts in), this kind of problem never would have happened.

Sure, but the Python community itself promoted the idea that Python was suitable for general application development and so on. And it probably was a really good option back in the day when people were using C, C++, Perl, and PHPv4. And I'm sure there are still some areas where it's a fine option (maybe heavy data science stuff?). But I would only use it as an absolutely final resort.

Greenfield Python programs that had strict type checking from day 1 can be pretty reasonable, as long as you know you never plan to write heavy data-munging code.

I often work on codebase that involves typed async Python plus a collection of Rust CLI tools that do most of the heavy lifting. And it's really not bad at all.

Re: Rust – A hard decision pays off

#306

Post by gmadsen »

throwaway894345 wrote: post #41

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow…

python i think is still good prototyping. I can do numerical work, visualisations, animations, game dev, web dev, etc. for me python is just the biggest collection of tools while not being the best at anything. which is an ok trade off a lot of the times

Re: Rust – A hard decision pays off

#307

Post by xhevahir »

tralarpa wrote: post #286
tlrobinson wrote: post #234

Earlier quoted context omitted.

> I find that static typing means I can be more productive, because type errors are caught straight away I agree completely. I feel like there’s a pretty common arc among programmers: 1. learn to program using verbose statically typed languages 2. discover fun dynamically typed languages, eschew statically typed languages 3. discover dynamically typed languages are a shitshow for large real-world projects 4. re-disco…

I hate that some universities teach dynamically typed languages as first language in their curriculum. I think for CS students the first language should be as "strict" (not in the mathematical sense) as possible, so the student is forced to think very carefully what is going where. This is of course a controversial opinion, especially among proponents of SICP (which is, in my opinion, not a good book for beginners. Y…

What language do you recommend for beginners?

Re: Rust – A hard decision pays off

#308

Post by tene »

mxkopy wrote: post #95
benreesman wrote: post #26

Earlier quoted context omitted.

I guess I’m rooting for Rust in the long game sense, which is a different set of imperatives than the hang the hashtag on peripheral stuff sense. I use a lot of great software written in Rust, it’s demonstrably a good vehicle for great software. But too many of its fans are advocates , this can start to seem like an agenda. Don’t take engineering advice from people with an agenda.

Thank you for pointing this out. Lately I've been getting a culty feeling around Rust which has been turning me off to learning it.

How would you expect the response to something genuinely better to be different, in a non-culty way?

Re: Rust – A hard decision pays off

#309

Post by throwaway894345 »

xhevahir wrote: post #307
tralarpa wrote: post #286

Earlier quoted context omitted.

I hate that some universities teach dynamically typed languages as first language in their curriculum. I think for CS students the first language should be as "strict" (not in the mathematical sense) as possible, so the student is forced to think very carefully what is going where. This is of course a controversial opinion, especially among proponents of SICP (which is, in my opinion, not a good book for beginners. Y…

What language do you recommend for beginners?

I think Go would make a pretty good language for beginners, but I haven't tested that theory. TypeScript might be the safer bet, especially since you can run it in the browser and see things, which is probably somewhat more gratifying than printing text to a console.

Re: Rust – A hard decision pays off

#310

Post by throwaway894345 »

0x457 wrote: post #261
throwaway894345 wrote: post #120

Earlier quoted context omitted.

I actually don't care as much for iterators as I thought I would. Beyond some simpler map().reduce() stuff they tend to fall over pretty fast, and I end up spending too much time trying to make iterator chains work before defaulting to for loops. I also dislike how anemic Rust's stdlib is. I'm sure there are good reasons, but I like that I can just reach for Go's stdlib for annotating errors or dealing with JSON. Oth…

Iterator-chain version would be a lot better looking if it was actually was a chain and not everything pushed into a single `filter_map`. "Ifs" are weird looking, one branch is using `entry`(I take it's a `DirEntry`?) and another is using `file_name` I suspect both could use the and look like `Self::is_` ? If you're going to write an iterator chain in an imperative way, then you might as well right it imperatively. A…

I'm sure there's plenty of room for improvement. I spent several hours with a bunch of Rustaceans just trying to get the short-circuiting to work right, and we sort of gave up on it beyond that.
Post reply on HN