Live data from Hacker News

A Fresh Look at Rust

lucumr.pocoo.org

131–140 of 157 posts

Re: A Fresh Look at Rust

#131
post #103

Disappointing how this author's hyper-criticism of Python is not applied equally to Rust, presumably because Rust is newer and this author has other bones to pick with Python. If Rust has a problem, he will sell that it is charming (e.g. "it makes you think", "you just need to think differently", "needs more love"). The glass will be full any day now! But if any new effort in Python is not absolutely perfect or just…

> , presumably because Rust is newer and this author has other bones to pick with Python.

Presumably because this attitude is what you've seen from the author before? Or presumably because you just assume that he is a "Magpie Developer"? If its the latter, that seems like a really unfair presumption.

Re: A Fresh Look at Rust

#132
post #47
post #41

Earlier quoted context omitted.

Searching[1] a data-structure (like a hashmap) will return a borrowed reference to that data, which "freezes" the hashmap while the borrow exists. And, due to lexical borrowing, it is frozen even if there was nothing (that is, if the return value was `None` which contains no references linked to the original map). The following is currently illegal because the `insert` is trying to modify the borrowed map. match some…

How exactly does one decide if scope is lexical or non-lexical? Or more precisely how do you tell compiler?

There is a Drop trait that has one method, drop(). It's like a destructor. It's called for you, but you can also call it yourself.

    fn foo(x: &something) {
        // stuff
        x.drop();
        // more stuff,
    } // if we didn't drop, x gets drop()-ped here
If we had non-lexical borrows, after we drop x, we could have it be un-borrowed. currently, x is still considered borrowed until the end of foo(). This is sort of a contrived example, but if you check out the ticket it has better ones.

There's also good examples here: http://www.reddit.com/r/rust/comments/2hy06n/a_fresh_look_at...

Re: A Fresh Look at Rust

#133
post #63

Earlier quoted context omitted.

I've been using Rust for toy projects for a while, and I gotta say Rust is one of the nicest languages out there. Kudos to the Rust team. As a relative newbie to Rust, one of the biggest hurdles I faced was that of poor documentation. A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs. I understand that Rust is a young language, and documentation is probably the l…

> A lot of "rust xxx" searches would link to outdated articles or to stale links in the Rust official docs. Or to an old mirror of the official doc, http://web.mit.edu/rust-lang_v0.9 is the bane of my rustperience.

I specifically contacted MIT about this issue, and unfortunately, we're just gonna have to out-SEO them.

Re: A Fresh Look at Rust

#134

Earlier quoted context omitted.

I've been thinking about implementing fastcgi so that I could play with simple rust webapps. Haven't had time to start on it though, so if that sounds interesting you'd have at least one immediate user.

Instead of FastCGI just speak HTTP. And for those there are libraries already.

Or 0MQ to talk to Mongrel2.

Re: A Fresh Look at Rust

#136
post #20

This is a good write-up. I still think some kind of vanilla ML would suit a lot of people very well.

What do you mean by 'vanilla ML'? I wasn't sure there were any really around... Ocaml has tons of stuff added, and SML also has lots of added extensions.

OCaml would be fine. It's a good language with a very efficient run-time.

I'm arguing that you could throw out most of the advanced features and that would be enough for most people. Its best features are the core ones. That's why I don't really care which specific flavor of ML you pick. Any would be a big win over many languages in wide use today.

Re: A Fresh Look at Rust

#137
post #5
post #4

I've been using Rust to process a large text corpus, and as Armin suggests, it's a really interesting experience. Here are a few things I've noticed so far: 1. Writing Rust code definitely takes more time than Python or Ruby, but it's not bad in practice. I can't measure the productivity difference yet, partly because I'm still learning Rust. I do spend more time thinking about how to write zero-allocation and zero-c…

This is great feedback, thanks. And if there's anything that you don't like about Rust, please let us know now while we still have a chance to possibly fix it! Only a few short months left until all of our mistakes are forever entombed in Rust 1.0. :)

Hi! I use F# for most tasks (from websites/JS generation, to packet capture and indexing, call routing and billing processing), and some C where required. Rust looks fantastic, and would give me the memory control I need when I need extra performance. A LOT of it comes down to simply being able to stack-allocate things; in F# I'm essentially forced to use the GC heap for even the most trivial things.

Rust looks fantastic, and I'm very excited about using it. When I found out about it and started reading how it worked, it was almost exactly what I had been wanting, on almost every count. I really wish it had existed a few years ago.

My comments are from someone that's just been playing around with the getting started guide of Rust.

-- Lack of custom operators limits expressiveness. For instance, look at Parsec or FParsec. Why shouldn't they be allowed to exist in Rust? But if custom operators are totally out of the question, then what about user-defined infix functions? (And then, why not functions with nearly arbitrary codepoints as identifiers?)

-- It seems that currying, partial application, and function composition are sorta cumbersome in Rust. Is this a conscious decision, that idiomatic Rust shouldn't be doing such things? Like " add >> inc >> print " being equivalent to "|a,b| -> print(inc(add(a,b)))" ? In F# I use this kind of stuff all the time, especially when processing lists.

-- It seems there's a difference between function types. Like if I do "fn foo(a:int, f:proc(int)->int)", I can call it with foo(1i, inc) if inc is a fn. But if I first do "let f = inc; foo(i1, f)", that's an error. Offhand, I'd assume this is due to lifetime management, but it feels a bit strange. When writing HoFs, do I need to implement a version for each kind of function? Or am I totally misunderstanding things?

-- Sorta related, does Rust allow something like:

  let inc =
    let x = ~0
    || { let res = *x; *x += 1; res }
The idea is to expose a function that contains some private state. I remember hearing that Rust changed the ownership stuff around a few times, but the basic idea is to create a globally-accessible closure. Is this impossible, requiring us to use statics to store the global state?

-- Why doesn't Rust warn when discarding the result of a function if not unit? Is it idiomatic Rust to return values that are often ignored?

-- Even without higher kinded types, monadic syntax is useful. Is Rust planning any sort of syntax that'd let users implement Option or Async? How does Rust avoid callback hell? Or is this quite possible today with macros and syntax extensions?

-- Has Rust considered Active Patterns (ala F#)? With that, I can define arbitrary patterns and use them with matching syntax. E.g. define a Regex pattern, then "match s { Regex("\d") => ... , Regex("\D") => ... , _ => ... }"

-- Consider allowing trailing commas in declarations; why special-case the last item?

-- And last but not least: Please, please, please, reconsider type inference. It's baffling why "fn" requires type annotations, but a closure does not. What's more, why is there even different function syntax in the first place? I've heard the reason that "top level items should have types documented", but that's a very personal decision to make. It certainly isn't something the Rust compiler should force me to do in all my code. Why do ya gotta limit my expressiveness? (Same argument I'd use for custom operators.) Statics/consts should also have type inference. And note that these items aren't necessarily public or exposed - but a private fn on a module still requires type annotations.

Re: A Fresh Look at Rust

#138

Earlier quoted context omitted.

All things a proper understanding of regex and a minimal understanding of streaming file IO can cover. The whole "if you think regex is the solution to your problem, now you have two problems" thing has gotten out of hand. Regex is not that hard.

I think people who are downvoting me don't understand how ludicrously retarded most people who output CSV are. CSV is not RFC4180. It's whatever bullshit text file your client has handed you and convinced your project manager is your problem to parse, not their problem to generate even remotely correctly. There is no CSV library capable of handling "CSV". Every time someone asks you for it, you better kick and scream…

I think you just answered your own question. Parsing CSV is not a problem solved by "any standard regex library".

Re: A Fresh Look at Rust

#139

Earlier quoted context omitted.

He actually has a point there. There are so many different versions of "CSV" floating around that I'm not at all sure I'd want to deal with a parser that could handle most of them. Ever generated a CSV file from a spreadsheet or DB interface program? Did it have a big list of options on how the CSV would be formatted, so you could easily read the generated file into whatever downstream you were using? Yeah.

> I'm not at all sure I'd want to deal with a parser that could handle most of them. Python's CSV parser will handle almost anything you throw at it and it is widely used to great success. > Ever generated a CSV file from a spreadsheet or DB interface program? Did it have a big list of options on how the CSV would be formatted, so you could easily read the generated file into whatever downstream you were using? Just…

"Python's CSV parser will handle almost anything you throw at it and it is widely used to great success."

I like the word "almost". It's kept me in cheesy-puffs for years, now. :-)

I was actually only speaking to the post I replied to. CSV is a mess.

Re: A Fresh Look at Rust

#140
post #5

Earlier quoted context omitted.

This is great feedback, thanks. And if there's anything that you don't like about Rust, please let us know now while we still have a chance to possibly fix it! Only a few short months left until all of our mistakes are forever entombed in Rust 1.0. :)

Hi! I use F# for most tasks (from websites/JS generation, to packet capture and indexing, call routing and billing processing), and some C where required. Rust looks fantastic, and would give me the memory control I need when I need extra performance. A LOT of it comes down to simply being able to stack-allocate things; in F# I'm essentially forced to use the GC heap for even the most trivial things. Rust looks fanta…

> -- Consider allowing trailing commas in declarations; why special-case the last item?

They are allowed in most circumstances.

Post reply on HN