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

A taste of Rust

lwn.net

Post reply on HN
Print view View original

71–80 of 93 posts

Re: A taste of Rust

#71

Post by pcwalton »

lobster_johnson wrote: post #67
pcwalton wrote: post #65

Earlier quoted context omitted.

> Rust has three types of pointers, and needs a line-noise character for each of them. `~T` and `@T` were felt to be preferable to `std::unique_ptr ` and `std::shared_ptr `. You really do type them all the time.

I understand that. That's not the alternative I want. Go actually gets by with just one type of pointer syntax. Go is what a colleague calls "being stupid simple", which is really its strongest asset at this point. It eschews a lot of complexity by not trying to be clever. The problem with Go's pointers is that no thought has gone into thinking about goroutines as boundaries of data ownership. It's simple to share mu…

I would also like it if we could just copy everything, but for implementing a competitive browser this gets really hard really fast. Erlang's actors are not really designed to squeeze every cycle out of the hardware. Incidentally, you can get this model with Rust's `flatpipes` module, which allows you to send data across Rust.

We experimented with COW designs in the early days. It seemed pretty hard to implement: hardware MMUs operate on page granularity, not on object granularity, so you need (thread-safe!) guards for all objects. That's pretty tough from a performance point of view. Perhaps it can be done, but it seemed less risky to just use uniqueness.

Re: A taste of Rust

#72

Post by pcwalton »

Dewie wrote: post #68
lobster_johnson wrote: post #66

Earlier quoted context omitted.

The period is necessary in human languages because we write sentences next to each other and we need some way to separate them . Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course. Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an op…

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this: if (something()); { somethingOther(); } The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.

This error can't happen in Rust. If blocks must be braced.

Re: A taste of Rust

#73

Post by lobster_johnson »

klibertp wrote: post #69
lobster_johnson wrote: post #41

Earlier quoted context omitted.

That logic sounds fishy to me. After all, they took C++'s semicolon syntax over Haskell, OCaml and Ruby's semicolon-free syntax, so there must have been a reason for picking one over the others. So the issue is not about inventing syntax, it's about choosing one (existing) syntax over another. pcwalton says it was to attract C++ devs, which is interesting considering that Go was also designed to attract C++ devs and…

Since when OCaml is semicolon-free? It not only has semicolons, single semicolon (;) means something different than double semicolon (;;). The former is used as an expression separator, like comma in Erlang, and the latter denotes the end of a top-level declaration, like period in Erlang. That's a pain while refactoring, but I can live with it. Anyway, that's just a style, nothing more, you can learn to love it or yo…

True, Ocaml has semicolons, although it's a little different given that you can construct deeply nested functional expressions without ever using a single one. If I remember correctly the semicolon is a separator, not a terminator, which means that declarations don't need to end with a semicolon, for example, and you pretty much only need it to separate statements.

Re: A taste of Rust

#74

Post by mcguire »

Dewie wrote: post #68
lobster_johnson wrote: post #66

Earlier quoted context omitted.

The period is necessary in human languages because we write sentences next to each other and we need some way to separate them . Programming languages are line-based and are more akin to recipes or poetry. So that's a bad analogy. Unless you consistently write all your statements on a single line, of course. Furthermore, you present a false dichotomy here. A semicolon-free language can easily have semicolons as an op…

I've on a few occasions had problems with semicolons in Java: accidently putting a semicolong like this: if (something()); { somethingOther(); } The semicolon seemed to shortcut the whole if-block. I don't know why that thing is even allowed by the compiler.

The semicolon following the conditional is an empty statement; it ends the if statement equivalently to "if (something()) { }". It's not often seen, but sometimes can be found in:

     for (i = 0; a[i] != x; i++) ;
to find the first index equaling x.

Personally, I always use braces in conditional and loop statements, so I'll never have the empty statement semicolon. But that's me.

Re: A taste of Rust

#75

Post by lobster_johnson »

pcwalton wrote: post #71
lobster_johnson wrote: post #67

Earlier quoted context omitted.

I understand that. That's not the alternative I want. Go actually gets by with just one type of pointer syntax. Go is what a colleague calls "being stupid simple", which is really its strongest asset at this point. It eschews a lot of complexity by not trying to be clever. The problem with Go's pointers is that no thought has gone into thinking about goroutines as boundaries of data ownership. It's simple to share mu…

I would also like it if we could just copy everything, but for implementing a competitive browser this gets really hard really fast. Erlang's actors are not really designed to squeeze every cycle out of the hardware. Incidentally, you can get this model with Rust's `flatpipes` module, which allows you to send data across Rust. We experimented with COW designs in the early days. It seemed pretty hard to implement: har…

Indeed, the types of programs I write are very different from a web browser.

For what it's worth, I know I speak for at least a couple of other people when I say that we were, for a long time, hoping for a "better Go" -- we are mainly rubyists who want native compilation, a better/safer type system, better concurrent performance, more easily massively parallelizable -- and that Rust's development has been going in a slightly different direction than we were hoping. Perhaps it's time to re-evaluate C++11 or even Haskell.

Re: A taste of Rust

#76

Post by maxcan »

jes5199 wrote: post #45
maxcan wrote: post #38

Earlier quoted context omitted.

can someone explain why this (of all the flamebaity/controversial comments I make) is getting downvoted?

Okay, since you asked: Your comment doesn't make sense. The parent comment: "rust unsafe and haskell unsafePerformIO are different!" Your comment: "You forgot about unsafePerformIO! It's the same as rust unsafe!"

Actually, the OP was talking about Safe Haskell, which is not the same as unsafePerformIO. While the two are related, they are different. While Safe Haskell does not really map to the Rust unsafe functions, unsafePerformIO does.

Re: A taste of Rust

#77

Post by ambrop7 »

monkeyfacebag wrote: post #4

The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell ( http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... )…

If they're really into reducing bugs, they should embed a complete proof system into the language, rather than try to guarantee something as simple as correct memory references - which isn't much of a problem to ensure for anyone serious about the correctness of their code.

Add that if a proof system (that is powerful enough) was available, and people actually used it, the language could do away with the unsafe overrides. It could also be of great help to the compiler to optimize the code, like removing array bounds checks where the programmer has supplied a proof that the index is in range.

Re: A taste of Rust

#78

Post by gnaritas »

lobster_johnson wrote: post #44
alcuadrado wrote: post #18

Earlier quoted context omitted.

Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \ you \ to \ write \ so \ many \ backslashes. They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story. Disclaimer: I code python every day of my life nowadays, I'm not a python hater.

I prefer Ruby's approach, which is not whitespace-sensitive, but has a very liberal approach to where expressions end. The general rule is, as with Python and Go, that open braces, brackets, parens or quotes have precedence; and operators or punctuation at the end of a line will continue to the next line. In addition, there are some complicated parsing internals -- not just for expression-ending sensing, but also for…

Ruby can use braces instead of end, both are valid.

Re: A taste of Rust

#79

Post by eslaught »

ambrop7 wrote: post #77
monkeyfacebag wrote: post #4

The article doesn't specify what exactly, is permitted by an unsafe vs. safe function. The Rust reference indicates the additional operations permitted by unsafe functions are: 1. Dereferencing a raw pointer. 2. Casting a raw pointer to a safe pointer type. 3. Calling an unsafe function. I was expecting something more along the lines of Safe Haskell ( http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... )…

If they're really into reducing bugs, they should embed a complete proof system into the language, rather than try to guarantee something as simple as correct memory references - which isn't much of a problem to ensure for anyone serious about the correctness of their code. Add that if a proof system (that is powerful enough) was available, and people actually used it, the language could do away with the unsafe overr…

I believe this is the programming language you are looking for: http://www.ats-lang.org/

Re: A taste of Rust

#80

Post by kibwen »

lobster_johnson wrote: post #75
pcwalton wrote: post #71

Earlier quoted context omitted.

I would also like it if we could just copy everything, but for implementing a competitive browser this gets really hard really fast. Erlang's actors are not really designed to squeeze every cycle out of the hardware. Incidentally, you can get this model with Rust's `flatpipes` module, which allows you to send data across Rust. We experimented with COW designs in the early days. It seemed pretty hard to implement: har…

Indeed, the types of programs I write are very different from a web browser. For what it's worth, I know I speak for at least a couple of other people when I say that we were, for a long time, hoping for a "better Go" -- we are mainly rubyists who want native compilation, a better/safer type system, better concurrent performance, more easily massively parallelizable -- and that Rust's development has been going in a…

Aside from the native compilation bit, could Elixir be the language that you're really looking for?

http://elixir-lang.org/

Speaking personally for a moment here, I'm a Python/Javascript/PHP dev by day, and the reason that I'm interested in Rust is precisely because of all the new concepts that it's forced me to learn. I could never get into C because I enjoy having two feet, and I could never get into C++ because I know that there's no escape from that stygian pit. For me, Rust is precisely the right balance of low-level/safety/coherence, semicolons be damned.

Post reply on HN