4 ms·

> What complexity is that? First and foremost ownership shenanigans. The complexity spill over the entire ecosystem. You can't write a fizz buzz without discov

> What complexity is that? First and foremost ownership shenanigans. The complexity spill over the entire ecosystem. You can't write a fizz buzz without discovering the standard library has 2 types of strings because of that. > not having exceptions makes code significantly easier to understand Both error codes and exceptions have their place. Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. > confused about the problem and needed to rethink my whole approach No amount of rethinking gonna help when you need a graph data structure in your code. Ownership shenanigans making graphs complicated in Rust, fundamentally so.

lmm 6y ago
> Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which is notoriously error-prone. If you have to have paths for propagating errors through your code, it's better to have them visible where you can reason about them, even if the actual handling has to take place at a different level. > No amount of rethinking gonna help when you need a graph data structure in your code. If you need a graph with cycles and you don't have a clear owner for the graph as a whole, sure. That's a pretty rare situation IME.
- Const-me 6y ago
  > you have to do things like make sure resources are closed correctly. Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. > a graph with cycles and you don't have a clear owner It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs to update multiple nodes at once, but Rust only supports a single writeable reference per object instance. All practical Rust implementations of graphs, trees and linked lists I saw use unsafe to workaround the fundamental language limitation. That's OK for linked lists because so simple and a standard library implementation is often enough. Graphs and trees however are very different based on use cases, can't implement just once and call it a day.
  - lmm 6y ago
    > Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. Code doesn't deal with resources until it does. Similarly with everything else that forces you to reason about control flow - you don't care about thread management until you do, you don't care about action logs until you do, you don't care about performance until you do... and from the other side, code doesn't need to be exception-safe until it does. The trouble with this kind of "magic" language feature is that correctness becomes non-compositional: you can take two working pieces of code and put them together and get something that doesn't work.

lmm 6y ago

> Imagine a streaming parser of some XML/JSON/mpeg4/whatever. There's nothing you can possibly do in the parser to handle socket errors. Exceptions make parser's code more readable, essentially you pretend sockets never fail. Disagree, because even if you can't handle errors in your code you have to do things like make sure resources are closed correctly. So you end up having to reason about exception safety, which is notoriously error-prone. If you have to have paths for propagating errors through your code, it's better to have them visible where you can reason about them, even if the actual handling has to take place at a different level. > No amount of rethinking gonna help when you need a graph data structure in your code. If you need a graph with cycles and you don't have a clear owner for the graph as a whole, sure. That's a pretty rare situation IME.

Const-me 6y ago
> you have to do things like make sure resources are closed correctly. Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. > a graph with cycles and you don't have a clear owner It's hard in Rust even for acyclic graphs with a clear owner, due to updates. Code that mutates the graph often needs to update multiple nodes at once, but Rust only supports a single writeable reference per object instance. All practical Rust implementations of graphs, trees and linked lists I saw use unsafe to workaround the fundamental language limitation. That's OK for linked lists because so simple and a standard library implementation is often enough. Graphs and trees however are very different based on use cases, can't implement just once and call it a day.
- lmm 6y ago
  > Not all code deals with resources. Streaming parsers normally don't. When you don't open/close any resources, manually propagating errors complicates code for no good reason. Code doesn't deal with resources until it does. Similarly with everything else that forces you to reason about control flow - you don't care about thread management until you do, you don't care about action logs until you do, you don't care about performance until you do... and from the other side, code doesn't need to be exception-safe until it does. The trouble with this kind of "magic" language feature is that correctness becomes non-compositional: you can take two working pieces of code and put them together and get something that doesn't work.