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

111–120 of 157 posts

Re: A Fresh Look at Rust

#111

Post by saucetenuto »

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 are a bunch of small dumb things in it. Why do we have make_heap() and friends instead of a heap type? Why does binary_search() return a bool instead of an iterator? Why didn't we get any hash tables until like 2010? Who thought the vector specialization was a good idea, and why didn't they benchmark it first?

The STL is a weird mix of brilliant, visionary API design and abject failure. Because of C++'s many limitations, the fail-y parts are the parts that most people are most familiar with. C++11 has done an incredible amount to turn that around, but at this point, for me, it's too late: I'd rather have a new language and new library, informed by C++'s successes without being bound to its mistakes.

Re: A Fresh Look at Rust

#112

Post by Symmetry »

kibwen wrote: post #5
ekidd wrote: 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. :)

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 though, and something that might have a big influence on language design going forward.

Re: A Fresh Look at Rust

#113

Post by kibwen »

mercurial wrote: post #57
kibwen wrote: post #50

Earlier quoted context omitted.

It's true that Rust approaches the "if it compiles, it works" property that Haskell has, but otherwise the two languages have very little philosophical or practical overlap. It doesn't make sense to compare them outside the context of "here are examples of programming languages with relatively strong type systems".

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 different restrictions such that if your library compiles, you know that your users will never experience failure due to the traits implemented by other libraries.

So even though the Rust devs have clearly taken some degree of inspiration from Haskell, there are enough subtle interactions with other systems that even the familiar features have a distinctly different feel.

I will say, though, that in my observations there have been more than a few people from iterative backgrounds who have said that familiarity with Rust was a useful stepping stone to Haskell. So even though I'd hesitate to compare the languages in absolute terms, in relative terms it's true that Rust is probably the iterative language with the most to offer to aspiring Haskellers.

Re: A Fresh Look at Rust

#114

Post by Symmetry »

lucian1900 wrote: post #79
CmonDev wrote: post #61

Earlier quoted context omitted.

Rust is meant to be practical, Haskell is more for academia (horrible ML syntax etc.).

Arguably that is either wrong or depends on taste. Haskell has very little syntax in comparison to something like C or Python and what little is has is very obvious. I'd much prefer ML/Haskell-ish syntax in Rust, but I know I'm in a minority.

I agree with you, but Rust is mostly targeted at C++ developers so it makes sense that they'd use C++isms where they it wasn't crazy. Examples of crazy being resource declaration mirroring use.

Re: A Fresh Look at Rust

#115

Post by kibwen »

tomp wrote: post #96
kibwen wrote: post #93

Earlier quoted context omitted.

Off the top of my head this seems like it would allow the amount of memory taken up by an enum to vary dynamically, which would prohibit stack allocation and require heap allocation instead. It would also be impossible to realize this optimization for any array of enums, since they would all need to be the same size for efficient indexing, and further it would wreak havoc with structs containing enums by making it im…

Well, it would definitely need to be special-cased, i.e. only use it when (1) the field containing the enum is immutable, and (2) it's the last field in the structure (it would then make the structure a Dynamically Sized Type). I only care about the size of enums inasmuch as I find it wasteful to allocate a 10 words long Box to hold a 2 words long enum. Of course, the optimization would only make sense if the Box was…

It's true, enum design in Rust can be a fine art. Specifically, knowing when to make the tradeoff between big inlined enum variants and pointer-sized variants that require an indirection to access. This plagued the Rust compiler for a long time as well, as the AST was formerly represented by a ludicrously large enum with something like 120 words per node.

Re: A Fresh Look at Rust

#116

Post by wisienkas »

Started using rust just this week.

Used more hours than ever expected on it. Simple put you'll fall in love with the compiler, because it point out so well your mistakes.

Another thing to note is that it greatly encourage you to fix your warnings too. which for me coming from java and php world isn't something you'd give much thought.

Re: A Fresh Look at Rust

#117

Post by DasIch »

pjmlp wrote: post #95
swah wrote: post #91

Earlier quoted context omitted.

Does OCaml still doesn't compile 1.0 + 2.0 or has that changed? Small stuff like this really bother some people and they fly off to Pythonland never to be seen again.

I guess it depends on the nature of the work being done. Personally I never used Python for anything other than glorified shell scripts and Websphere installations (after Jacl got replaced by Jython). For everything else I prefer languages with type inference and availability of native compilers (AOT/JIT) in their toolchains. How good is PyPy for production code nowadays?

> How good is PyPy for production code nowadays?

Unless you are using CPython extensions, PyPy is usable as a drop-in replacement that's significantly faster in almost all cases. In order to notice any significant speed gain, the JIT needs a chance to "warm up" though, so on short running applications or on web applications for the first couple of requests PyPy can be slower than CPython.

Re: A Fresh Look at Rust

#118

Post by kibwen »

Symmetry wrote: post #112
kibwen wrote: 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. :)

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.

Re: A Fresh Look at Rust

#119

Post by mcguire »

moron4hire wrote: post #48
moron4hire wrote: post #38

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…

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.

Re: A Fresh Look at Rust

#120

Post by kibwen »

wisienkas wrote: post #116

Started using rust just this week. Used more hours than ever expected on it. Simple put you'll fall in love with the compiler, because it point out so well your mistakes. Another thing to note is that it greatly encourage you to fix your warnings too. which for me coming from java and php world isn't something you'd give much thought.

I agree about the warnings. Normal Rust code is already so strict that a lot of the warnings that you'd get from other languages are already compiler errors, which means that issues that are merely good style (e.g. declaring a variable as mutable when you never actually mutate it) can spit out warnings without overwhelming coders and causing them to lapse into "I've already got 200 pages of warnings so screw this" apathy. It's a fine line though, and something we have to remain mindful of as we add more warnings by default.
Post reply on HN