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

Rust means never having to close a socket

blog.skylight.io

Post reply on HN
Print view View original

121–130 of 165 posts

Re: Rust means never having to close a socket

#121

Post by samth »

mwcampbell wrote: post #81
steveklabnik wrote: post #71

Earlier quoted context omitted.

You can do that if you want, just use the Rc /Arc /Weak types. That said, you're right: if you don't need Rust's strengths, the tradeoff may not be worth it.

I know Rust has RC pointers. But I'm guessing a Rust programmer would still have to understand ownership and borrowing, since the standard library and third-party libraries use those concepts. I think what I'd really like is something like C# and the .NET base class library, but AOT compiled to native code and using automatic reference counting, with some way to indicate weak references. I know that neither GC nor re…

I think the language you want is Ocaml.

Re: Rust means never having to close a socket

#122

Post by wycats »

shadowmint wrote: post #118
wycats wrote: post #117

Earlier quoted context omitted.

> In rust there are two types of code. 'safe' and 'unsafe'. The above is only true if your entire code path contains only safe code. I think this is actually a misconception. In every high-level language (Ruby, Python, etc.) there are APIs for interacting with low-level code. These APIs (C bindings and FFI) are unsafe, and are in the path of virtually all high-level code. It is the responsibility of somebody implemen…

> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the proc…

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it.

You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface.

You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a safe interface.

Anything to the contrary is a misunderstanding of the purpose and role of unsafe code in Rust, and endangers the entire ecosystem, just as it would endanger the Ruby ecosystem if it were seen as normal for C extensions to SEGV the safe Ruby process.

Re: Rust means never having to close a socket

#124

Post by nwmcsween »

wycats wrote: post #122
shadowmint wrote: post #118

Earlier quoted context omitted.

> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the proc…

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a…

'Unsafe' is a bad term, effect is much better and it is most definitely a rust issue. If the language doesn't have a way of dealing with effects it won't be able to handle them. Rust is honestly a more safe c++ and in my opinion not an alternative for c.

Re: Rust means never having to close a socket

#125

Post by wycats »

nwmcsween wrote: post #124
wycats wrote: post #122

Earlier quoted context omitted.

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a…

'Unsafe' is a bad term, effect is much better and it is most definitely a rust issue. If the language doesn't have a way of dealing with effects it won't be able to handle them. Rust is honestly a more safe c++ and in my opinion not an alternative for c.

I don't know what this means. I stand by my upstream comment.

Re: Rust means never having to close a socket

#126

Post by spullara »

pcwalton wrote: post #114
spullara wrote: post #62

"Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety." If it is freeing everything at the scope boundary it is incurring a huge runtime cost relative to garbage collected languages. GC scales with the number of live objects during GC while this scheme scales with the number of allocated objects. It is far more predictable than GC but I…

In general, idiomatic Rust puts most objects that would be in a semispace nursery on the stack instead, which has all the advantages of a semispace collector, plus improved locality and the lack of a mark phase. The lifetime system means that the traditional limitations of escape analysis (higher order functions, separately compiled functions, virtual functions, returning objects on the stack) largely don't apply.

If you can get all the objects for a full request on the stack, that would be pretty great. Is that true for the current HTTP servers / frameworks written in Rust?

Re: Rust means never having to close a socket

#127

Post by shadowmint »

wycats wrote: post #122
shadowmint wrote: post #118

Earlier quoted context omitted.

> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the proc…

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a…

I'm not arguing any of these points.

I'm just saying there are these two misconceptions:

    - if you write safe rust code, your code can't segfault
This isn't true if your code path contains any unsafe code.

    - Rust code can't segfault
This isn't true at all.

Sure, if it does segfault its a bug in the c code / unsafe code.

You're absolutely correct.

...but bugs aren't deliberate. Obviously no one is going to deliberately expose a c api that has segfaults in it.

The misconception is that if you're using rust you're safe from the bugs that other programmers may have made... which is not true.

There's a trust chain involved; if you depend on a library you trust it's bug free and won't delete your harddisk and crash your program, but there's a difference between trusting a library is not malicious, and trusting a library is bug free.

If you have to trust the library is bug free, you're really no better off than using C++ are you?

...but people keep saying that if you use rust then there are certain types of safety that are guaranteed by the language: http://doc.rust-lang.org/reference.html#behavior-considered-..., regardless of programmer bugs.

It's just not true.

Once again, I'm not arguing that safety is good or bad or whatever. My assertion is very very specific:

Rust code written 100% safely can crash if it has a dependency that uses unsafe code.

The assertion that 100% safely written rust code with arbitrary dependencies can't crash is false.

Re: Rust means never having to close a socket

#128

Post by pcwalton »

spullara wrote: post #126
pcwalton wrote: post #114

Earlier quoted context omitted.

In general, idiomatic Rust puts most objects that would be in a semispace nursery on the stack instead, which has all the advantages of a semispace collector, plus improved locality and the lack of a mark phase. The lifetime system means that the traditional limitations of escape analysis (higher order functions, separately compiled functions, virtual functions, returning objects on the stack) largely don't apply.

If you can get all the objects for a full request on the stack, that would be pretty great. Is that true for the current HTTP servers / frameworks written in Rust?

I don't do a lot of server Web development in Rust, but I see no reason why it wouldn't be possible, at least for common cases with small vector optimization.

Re: Rust means never having to close a socket

#129

Post by dbaupp »

shadowmint wrote: post #118
wycats wrote: post #117

Earlier quoted context omitted.

> In rust there are two types of code. 'safe' and 'unsafe'. The above is only true if your entire code path contains only safe code. I think this is actually a misconception. In every high-level language (Ruby, Python, etc.) there are APIs for interacting with low-level code. These APIs (C bindings and FFI) are unsafe, and are in the path of virtually all high-level code. It is the responsibility of somebody implemen…

> If you use `nokogiri` in Ruby and get a segfault, that is a bug in nokogiri. It is not an indication that Ruby is unsafe. Rust has a strict definition of safety; not all rust code for fills that guarantee. We're not talking fast and loose here. These are absolute definitions. You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. > This is in the proc…

> No it's not.

> What's happening is some of the run time overhead is being reduced.

I believe wycats was responding specifically to

> Rust uses 'drop flags', which are extra bytes at the end of struct instances in memroy, to track objects and keep meta information about them to determine if they should be dropped.

And these are being eliminated. That is the drop flag will be entirely separate to the struct instance, and will only be injected into stack frames where there is a conditional branch in which a value is moved out in one, but not the other, e.g.

  let x = some_value;
  if condition { drop(x); } else { /* do nothing */ }
then `x` will get a drop flag as a single bit (or byte) on the stack. If the code is changed to

  if condition { drop(x); } else { drop(x) }
there will be no drop flag, and no overhead.

Furthermore, placing the value on to the heap, e.g. `box some_value`, will not have an associated drop flag for `some_value`, that is, eliminating the byte that is currently stored with it.

Re: Rust means never having to close a socket

#130

Post by dbaupp »

shadowmint wrote: post #127
wycats wrote: post #122

Earlier quoted context omitted.

> You can write safe code that crashes in rust. That absolutely violates the safety guarantee whatever the reason for it. You can write Ruby code that calls into unsafe C code and SEGVs. This is a bug in the C code you called. It should have exposed a safe interface. You can write Rust code that calls into clearly delineated unsafe code and SEGVs. This is a bug in the unsafe code you called. It should have exposed a…

I'm not arguing any of these points. I'm just saying there are these two misconceptions: - if you write safe rust code, your code can't segfault This isn't true if your code path contains any unsafe code. - Rust code can't segfault This isn't true at all . Sure, if it does segfault its a bug in the c code / unsafe code. You're absolutely correct. ...but bugs aren't deliberate. Obviously no one is going to deliberatel…

> The misconception is that if you're using rust you're safe from the bugs that other programmers may have made... which is not true.

Of course it's not true, but the libraries you're using will (hopefully, for the most part) be written in Rust, which increases the level of trust.

> There's a trust chain involved; if you depend on a library you trust it's bug free and won't delete your harddisk and crash your program, but there's a difference between trusting a library is not malicious, and trusting a library is bug free.

> If you have to trust the library is bug free, you're really no better off than using C++ are you?

The libraries are written in Rust, so have all the benefits of that. It is nonsense to say that "libraries can have bugs so you might as well use C++".

Post reply on HN