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

A Fresh Look at Rust

lucumr.pocoo.org

Post reply on HN
Print view View original

121–130 of 157 posts

Re: A Fresh Look at Rust

#121

Post by aidenn0 »

kibwen wrote: post #46
haberman wrote: post #28

> The truth is that the borrow checker is not perfect. The borrow checker prevents you from doing dangerous things and it does that. However it often feels too restrictive. In my experience though the borrow checker actually is wrong much less often than you think it is and just requires you to think a bit differently. I would love to see this explored in more detail. The borrow checker is, from what I can tell, one…

> it kept you from doing something that seemed safe, but > then you realized that it was actually telling you > something important. One of the reasons that I know Rust is on to something is how often I've seen this scenario occur on IRC. It's great to watch someone come in with a complaint about appeasing the borrow checker, only to later realize that what they were attempting to do was actually subtly unsafe. For t…

It's also really a pain now to get the borrow checker to be happy with boxed structures now that box isn't implemented in the compiler. You need to first borrow the whole structure, and then things within it.

Re: A Fresh Look at Rust

#122

Post by cageface »

saucetenuto wrote: post #111
cageface wrote: post #6

I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry. I really don't understand why STL gets so little love. It's a little lean on features maybe but in my experience it just works, and it's fast . Once you get your head around the iterator concept it's pretty simple to use. And with lambdas in C++ I can write code that's almost as concise as Ruby or Scal…

Lambdas in C++ are pretty new. Most of us who used std::algorithm had to write our own functor structs and do the variable capture by hand. Except that typically we didn't, because at that point a for loop is more readable. I think that's the essential objection to the STL: it's a library built around functional programming and not OO, in a language built around OO and not functional programming. And of course there…

The STL is a weird mix of brilliant, visionary API design and abject failure.

Sounds like most software projects. IIRC the Scala folks have pretty much rewritten their entire collections library twice already, and that's with the benefit of hindsight.

I'd like to see a mature new language in this space with a good ecosystem too but the number of major swerves they've taken in the Rust design already makes me inclined to think that, like C++, they're going to discover they made some serious mistakes along the way.

Re: A Fresh Look at Rust

#123

Post by sanderjd »

bjz_ wrote: post #10
dbaupp wrote: post #3

Earlier quoted context omitted.

Don't forget Aaron Turon (employed by Mozilla to work on the design of the std library), who, among other things, wrote the "fluent" APIs for process[1] and task[2] spawning, which possibly inspired the redis-rs API Armin describes in this post. [1]: http://doc.rust-lang.org/nightly/std/io/process/struct.Comma... [2]: http://doc.rust-lang.org/nightly/std/task/struct.TaskBuilder...

I'm so glad that Aaron is on the core team, focusing specifically on API design and ergonomics, rather than just the language. He has definitely been applying much needed polish that we need for a slick 1.0 release.

Just wanted to also add that in an area of design with lots of strongly held subjective opinion and rampant bikeshedding, Aaron has shown himself to be incredibly thoughtful, well-measured, and diplomatic. Really a great addition to the team!

Re: A Fresh Look at Rust

#124

Post by saosebastiao »

kibwen wrote: post #118
Symmetry wrote: post #112

Earlier quoted context omitted.

The ability to evaluate functions at compile time would be really nice. I was sort of looking at writing a macro in Rust to mirror Nimrod/Nim's 'when' statements but gave sort of gave up when I saw that. But of course that's probably an entirely unreasonable thing to request in the remaining time you have and it might be incompatible with having a borrow checker anyways. The borrow checker looks really valuable thoug…

Lightweight compile-time evaluation is definitely a weakness of ours. A full-fledged syntax extension can get you pretty far, but those are a terror to write and ugly to import. While I don't know of any proposals in the air at the moment, I expect the developers will treat this with great importance post-1.0.

Interesting. From what I understand, this was what BurntSushi's regex macro was intended to accomplish: an efficiently compiled regex that optimized away all unneeded functionality for regex literals. With CTFE, would this get rid of the need for a macro entirely?

Re: A Fresh Look at Rust

#125

Post by burntsushi »

mcguire wrote: post #119
moron4hire wrote: post #48

Earlier quoted context omitted.

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…

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 about every single CSV file that I've ever had to read was generated by someone other than me. Frequently (but not always), they come from a non-technical person.

Sometimes those CSV files even have NUL bytes in them. Yeah. Really. I swear. It's awful and Python's CSV parser fell over when trying to read them. (You can bet that my parser won't.)

> He actually has a point there.

His point is to use regexes instead of a proper CSV parser. I'm hard pressed to think of a reason to ever do such a thing:

1. A regex is much harder to get correct than using a standard CSV parser. 2. A regex will probably be slower than a fast CSV parser.

Re: A Fresh Look at Rust

#126

Post by robertfw »

ObviousScience wrote: post #22

I've been very interested in Rust for a while, but put off by the early development status and the fact that it's undergone a few major redesigns. I don't hold them against the language team in any sense, and actually think more of them for it, since redesigns early are good if you realize something else might be better or one of your original ideas just didn't work out. Rather, I'm just curious when I can expect Rus…

There was a blog post recently discussing what is left before a 1.0 release, and the timeline for it. I'm in the same boat as you and the blog post has been helpful because now I can at least feel comfortable learning some basics, while avoiding the areas that are still in flux.

http://blog.rust-lang.org/2014/09/15/Rust-1.0.html

Re: A Fresh Look at Rust

#127

Post by kibwen »

saosebastiao wrote: post #124
kibwen wrote: post #118

Earlier quoted context omitted.

Lightweight compile-time evaluation is definitely a weakness of ours. A full-fledged syntax extension can get you pretty far, but those are a terror to write and ugly to import. While I don't know of any proposals in the air at the moment, I expect the developers will treat this with great importance post-1.0.

Interesting. From what I understand, this was what BurntSushi's regex macro was intended to accomplish: an efficiently compiled regex that optimized away all unneeded functionality for regex literals. With CTFE, would this get rid of the need for a macro entirely?

Sadly I'm not enough of an expert to say for sure. It would certainly depend on the specific form that it took, and there are a multitude of options in this space. Of the current contributors who are willing and able to push the boundaries here, I believe that quasiquotation is the preferred approach (motivated by use cases for compile-time codegen in Servo).

Re: A Fresh Look at Rust

#128

Post by scardine »

mercurial wrote: post #56
zem wrote: post #21

Earlier quoted context omitted.

you might also like ocaml as a higher-level language with a lot of the same features.

Yes. Rust borrows quite a few things from the ML family of languages (and things unique to Haskell like "deriving"). OCaml has the advantage of offering very good performance while not having to deal with the borrow checker, but it doesn't have the momentum behind Rust (the community is quite small, and the number of libraries isn't that large). That said, it is a very nice language to work with, and offers a number…

I think most ML implementations still have poor support for unicode, and this is a killer feature for me.

Re: A Fresh Look at Rust

#129

Post by ghshephard »

mcguire wrote: post #119
moron4hire wrote: post #48

Earlier quoted context omitted.

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…

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.

A good CSV Parser (Python's) let's you specify the dialect of CSV file - it doesn't make assumptions as to the format of the CSV file.

Re: A Fresh Look at Rust

#130

Post by comex »

kibwen wrote: post #113
mercurial wrote: post #57

Earlier quoted context omitted.

Well, Rust has some kind of typeclasses, #deriving, stuff like that. If what parent means is "if you like the things Rust borrowed from OCaml and Haskell, check out Haskell", it's not unreasonable, especially if addressed to people coming from mostly-imperative languages (C or Python). I agree that Rust and Haskell do feel mighty different in practice.

(Warning: not at all a Haskell expert, so please correct me if I'm wrong.) Each language's deriving facilities aren't actually comparable, as Haskell's are actually generic whereas each Rust's are all hand-coded syntax extensions. Also, I believe that it's possible for Haskell code to fail at link time due to libraries providing incompatible typeclasses (contributing to Cabal hell, perhaps?), whereas Rust traits have…

What do you mean by Haskell's deriving being generic? As far as I know, Haskell can only derive a fixed list of classes, except for newtypes, which are sort of a different case. How the fixed list is implemented in the compiler isn't that important... on the contrary, at least vanilla Rust has a way to define arbitrary deriving-like extensions based on inspecting the structure at compile time (even if it's somewhat ugly), while vanilla Haskell has nothing of the sort.
Post reply on HN