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

91–100 of 157 posts

Re: A Fresh Look at Rust

#91

Post by swah »

mercurial wrote: post #78
pjmlp wrote: post #64

Earlier quoted context omitted.

> but it doesn't have the momentum behind Rust (the community is quite small, and the number of libraries isn't that large) How come, given the amount of use it gets in the industry and academia versus Rust that still hasn't reached 1.0?

That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting D in the same position as OCaml, I guess?), while having nice enough constructs that people coming from high-level languages get interested in it. By contrast, OCaml doesn't have the "shiny new" feeling of Rust (also suffers from other issues, such as its stan…

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.

Re: A Fresh Look at Rust

#92

Post by mercurial »

swah wrote: post #91
mercurial wrote: post #78

Earlier quoted context omitted.

That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting D in the same position as OCaml, I guess?), while having nice enough constructs that people coming from high-level languages get interested in it. By contrast, OCaml doesn't have the "shiny new" feeling of Rust (also suffers from other issues, such as its stan…

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.

> Does OCaml still doesn't compile 1.0 + 2.0 or has that changed?

I'm not quite sure what you mean? In any case, the compilation speed isn't really an issue (especially since we're talking about Rust, which last time I used it wasn't exactly fast).

Re: A Fresh Look at Rust

#93

Post by kibwen »

tomp wrote: post #85
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. :)

I think that mutability should also be recorded in types (i.e. even a &mut would not allow you to modify an immutable type). Then, programmers could control whether variants/enums are "fat" (use the maximum amount of memory of any variant in the same type) or "thin" (use the minimum amount of memory for the given variant) by changing the mutability of fields they are stored in. But I totally understand that you proba…

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 impossible to statically compute field offsets.

However, we have considered elevating the position of mutability in the type system for other reasons--specifically, to make it possible to write a function that is generic with respect to mutability. But there's never been a huge amount of enthusiasm for that, so I wouldn't expect any changes of that sort.

But thanks for the feedback anyway! :) It's definitely valuable to know that people do care about the size of enums. We have various optimizations required by the language spec to shrink them down wherever we can do so while preserving semantics, and we welcome people to concoct more.

Re: A Fresh Look at Rust

#94

Post by InfiniteRand »

Rust actually makes me think a lot about Ada, if you want to program, you need to program correctly.

Probably the reason I will not use Rust is the same reason I only look at Ada in a professional context, I usually start projects with something quick and dirty, then gradually refactor it into something better, rather than piece by piece. Being forced to do it right the first time would likely just push me more into doing less programming.

Re: A Fresh Look at Rust

#95

Post by pjmlp »

swah wrote: post #91
mercurial wrote: post #78

Earlier quoted context omitted.

That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting D in the same position as OCaml, I guess?), while having nice enough constructs that people coming from high-level languages get interested in it. By contrast, OCaml doesn't have the "shiny new" feeling of Rust (also suffers from other issues, such as its stan…

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?

Re: A Fresh Look at Rust

#96

Post by tomp »

kibwen wrote: post #93
tomp wrote: post #85

Earlier quoted context omitted.

I think that mutability should also be recorded in types (i.e. even a &mut would not allow you to modify an immutable type). Then, programmers could control whether variants/enums are "fat" (use the maximum amount of memory of any variant in the same type) or "thin" (use the minimum amount of memory for the given variant) by changing the mutability of fields they are stored in. But I totally understand that you proba…

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 immutable (even with a unique reference). I mostly mentioned the enum size issue because I read somewhere not too long ago that Servo people were having problems with memory usage because of that (and that they also want objects/records with inheritance of fields - that would bring all the issues you speak about above).

Re: A Fresh Look at Rust

#97

Post by muyuu »

kibwen wrote: post #2

I adore that someone like Armin is so delighted to use Rust. From what I've seen of Flask and his other Python libraries, the level of consideration that he devotes to API design is absolutely inspiring. At such an early stage in the language's history, I'm optimistic that his thoughtfulness in API design will become the baseline for the entire Rust ecosystem. In this vein, I'd also like to credit Chris Morgan's Teep…

Speaking of which, Rust is probably an appropriate language to write a safe and fast WSGI dispatcher to go with Flask, or maybe a full server with an embedded Flask-like framework.

Re: A Fresh Look at Rust

#98

Post by aethertap »

jonesetc wrote: post #8

I rarely have to do anything as low-level as rust would demand. More often than not I find myself using Python, but I had the same feelings when I started looking into rust a few weeks ago. It was exciting seeing the full pattern-matching, especially. I have a desire to get some experience in the area, but the problem is what to make. Does anyone have any ideas for some smallish libraries that would benefit the commu…

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.

Re: A Fresh Look at Rust

#99

Post by the_mitsuhiko »

FreeFull wrote: post #90
the_mitsuhiko wrote: post #81

Earlier quoted context omitted.

Unwrap only appears in simplistic examples. The correct "unwrap" is the `try!` macro.

Once you reach the main function, you have to deal with the errors, since you can't propagate them any further.

Your main function is most likely pretty empty and that's the only place where you need to deal with hard failure. And that's the same in all languages. If you write in Python you don't just not handle exceptions either. Somewhere you catch them down and present them to the user in a good way.

Re: A Fresh Look at Rust

#100

Post by bam365 »

mercurial wrote: post #92
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.

> Does OCaml still doesn't compile 1.0 + 2.0 or has that changed? I'm not quite sure what you mean? In any case, the compilation speed isn't really an issue (especially since we're talking about Rust, which last time I used it wasn't exactly fast).

He's probably referring to the fact that you have to use different arithmetic operators for int and float in OCaml, so it would have to be 1.0 +. 2.0
Post reply on HN