phaylon

Is there a way to enforce a particular style across a project? From what I've read the abiliity for projects to be internally consistent, even with third party library usage, seems to be one of the big advantages of this design-wise. So if you had an optional setting somewhere that enforces it, it might help communicate the intention of the feature.

I'm more thinking about the documentation effect of such a wrapper type. Both in the data structure and in the parts of the code that are foced to use unsafe.

I've been wondering if it would make sense to encapsulate internal fields that are part of the unsafe machinery in a type forcing you to use unsafe blocks, even inside the type impl. [edit: Removed note about UnsafeCell since it's not really like the thing described above]

I haven't really played with it though, most of my unsafe use is FFI.

Google suggests "affine memory management" is not yet used as a term.

> I feel that a lot of HN visitors do not at all check out the "new" page.

My simple reason: It doesn't have an RSS/Atom feed.

> Please make an effort to read and understand my point.

Please don't assume disagreement implies I didn't make an effort. I understand your point, I just vehemently disagree with it. Bringing up the word "bikeshedding" when discussing putting people in danger of death is just something I can not agree with.

> Yeah, maybe there was a case when a couple peoples' lives were at stake but nothing happened.

This is exactly why I so vehemently disagree. If we found all the people who were in traffic with them at the time, do you think they'd agree that doing experiments in public traffic next to them is a purely aesthetical issue? Recklessness isn't defined by the outcome, but by the possible outcome.

> The real issue is that tens of thousands or hundreds of thousands of peoples' lives are at stake RIGHT NOW, under conditions that are much less controlled than what people are deriding as uncontrolled conditions. But people are griping about the 1-2 instead of the 10,000-400,000.

Yes, and I'm saying both are very important issues. Experiments on public roads in actual traffic are something that should not ever happen. I'm also not sure I'd put the amount of people they endangered in the 1-2 range, since there was at least one other person in the car, one in the truck behind, and others in the cars that passed them.

I also wouldn't go so far as calling this controlled, since that usually means a controlled setting, safety precautions and such.

> How is this not dead simple to understand? I don't get it.

As said, I do understand, I just disagree. It would also make it much easier to talk about this if you weren't trying to insult me and others.

I agree that the flaw itself is a very big issue. I disagree that the way the experiment was done isn't. And nobody here is arguing that it's good that the cars have that fault, so it's quite natural for the discussion here to be around topics people disagree on.

You know what the perfect location and media would have been for such an experiment? A television car show with a dedicated track and a big audience of people driving cars.

No, when people's lives are at stake, I extremely disagree about calling that "bikeshedding".

> Why is most of the discussion here about the minor issue? Why is everyone so eager to derail discussion from the major issue? I thought HN was trying to be a reasonable place.

I find these criticisms _extremely_ reasonable. Plus, the big discussion is not about them doing something illegal, the big discussion is about people here being totally fine with it.

And given that the topic you (I assume) want to discuss is something along the lines of "negligent behavior in technology", I also find it very relevant that negligence is countered with more negligence.

Or to continue the train of thought, what about things that it did ship with that could have been excluded? :)

Personally I'm starting to dislike index operations since they can panic (and are the shortest way to access), and I rather use the explicit Option based APIs. Though I'm not too worried about those, since a lint disallowing them shouldn't be too hard.

I found consuming Reddit is a lot easier when you treat it like Usenet. So I have RSS subscriptions for the subreddits that interest me in my RSS reader.

That also means I can easily organize them myself by topic. In the dev related area are things like /r/rust, /r/perl, /r/rust_gamedev. And even /r/programming, which many people dislike, but I appreciate for the purpose of having people from different communities interact. I found some interesting links in discussions in there in the past that I wouldn't have run into otherwise, because it's not directly related to anything I currently do.

There's a bit of change over time in what subreddits I read. If I find myself not going back to a specific one (entries always maxed out), I just remove it.

Nitpick: Result<T, E> instead of Result<T> assuming Result is std::result::Result.

> Exceptions have the good property that they can't be ignored - if they're not handled, you get a reasonable program termination.

This would probably be the main point where I'd disagree. To get the same guarantees as you currently have, the exceptions would have to be checked exceptions like in Java. And, in contrast, the advantage (to me) here is that all error handling in Rust basically works like handling anything else.

Personally, I'm rather fond of the way Rust does it. Which surprised me, coming from a dynamic background.

It would be a compile-time error saying (in essence) "multiple applicable methods in scope" and giving you a list of the available methods.

Trait methods are only visible when the trait is in scope. So a conflict would only appear when both traits are imported and the method is called, in which case you'll have to disambiguate.

Do you mean this[1] port? I can't remember one that had statistics on incremental builds during development, unfortunately.

[1] https://ruudvanasseldonk.com/2014/10/20/writing-a-path-trace... (See "Performance")

Rust solutions would probably be the following: Some kind of runtime assistance (`Rc<T>`, `Arc<T>` et al), using indices as you mentioned (though with `list.get(index)` you'd still have to deal with the fact that it might not be valid, since `get` will return an `Option<T>`)[1] Another solution might be to allocate the textures in an arena that lives outside of the scope of your game logic, and have both the texture list and sprites contain borrows (Note I'm not sure about this, as I haven't done much with arenas yet).

Although I'm unsure where the `not nil` as discussed above comes into play here. What part in Nim would be `nil` here where Rust would have `Option<T>`? The difference between `Option<&Texture>` and `&Texture` is that you have to somehow deal with the possibility of no texture when handling the former.

[1] I should note that actual indexing behavior (`list[index]`) will assume you know there is one in there and panic if it isn't. This is one of the things I dislike and hope there will be an optional (no pun intended) lint post-1.0.

Ah, good to know. So Nim does static analysis on conditionals where Rust would use an explicit pattern match to get at the contained value.

Might be a good example for http://nim-lang.org/manual.html#not-nil-annotation

> Rust must either treat every Option<> reference as a potential 'loan path', which would significantly diminish their usefulness as a references, encouraging indexing for these scenarios, which leads to almost identical potential for out-of-bounds crashes... or it's relying on some kind of more complex mechanism (lifetime vars maybe?).. or additional runtime overhead.

Can you give a concrete example of this? I'm a bit confused, but it might just be a terminology thing. In Rust, `Option<T>` does not imply a reference. If you have a `Option<i32>` there are no references involved. An `Option<T>` also owns the `T` if there is one. You can get a reference to it, but you have to check that it indeed holds a `T` (via `match` or `match` using functionality).

Note: I should clarify: What's confusing me is the indexing stuff. I'm not sure if this is referring to something about the `Option<T>` or something else.

Out of curiosity: How do you convert from a nilable `Foo` to a `Foo not nil`? As in, what do you do if you have a function maybe returning a `Foo` and want to pass its value to a function taking `Foo not nil`?

It might be a terminology thing. Assuming MyStruct only contains values, it will fully live on my_func's stack and nothing needs deallocating on drop. When take_ownership is called a copy of it's value would be passed in, and the original location marked unusable (assuming MyStruct doesn't implement Copy). So yeah, there's isn't any specific memory location being taken over, since there's two locations involved.

I think he was more talking about the unique ownership part, especially that values themselves follow the same rules.

Which I find fitting, since in Rust, the Box is (at least to me) more about indirection. The single-owner semantics just come in because Box follows the same rules as anything else, while for unique_ptr they are part of the pointer concept.

I would say it is familiarity, but in another sense. You can use something like

    path.file_name().and_then(|f| f.to_str()).unwrap()

but that really doesn't buy you much.

Where familiarity comes in I believe is in what that line communicates to me: There might not be a file name (like having '/' as path), and that getting a string slice out of it might fail (the kind of string the platform uses for paths might not be UTF-8 compatible).

Plus, the unwrap()s tell me that whoever wrote the code considered it an assertion failure if one of those is happening.

I read a lot more Rust than I write, and it really helps that the code communicates a lot. And with knowing about OsString/OsStr beforehand, I only had to lookup when file_name() returns None, the rest is rather implicit by convention, or familiarity.

I'm not really a C guy, but isn't #include about using a module in the current scope? Because Rust's mod is for project structure definition.

Another thing which I don't see often mentioned, but which alleviate most of the compile-time waiting-pain for me (and I'm actually a dynamic language guy) is the fact that since optimizations are usually what takes longest, the compiler is quite quick about telling me about errors.

But maybe my projects just haven't been big enough :)

I should've taken a deeper look at your CSV handling code earlier. That's quite a nice demonstration of an API using Decoder/Decodable.

My thoughts are that at some point it might become more easy to just change your identity.

Well, MetaCPAN has a leaderboard of modules, but it could be a bit more prominent: https://metacpan.org/favorite/leaderboard

Could "'" count as type-parameter sigil for lifetimes? It could at least look like a sigil on a first look.

If it is just for a first try to experiment with structuring those kinds of application, or if your needs aren't even that complicated, it can even be quite close to trivial sometimes. But it's hard to know what is out there, and how useful it would be. Things that I've done on the side that weren't too hard and even more fun than I imagined beforehand:

* Media Players (Video and Audio) with GStreamer (0.10 can be okay'ish, 1.0 is very nice so far)

* Text Editors (via Gtk-Source or embedded GVim)

* I've tried building a specialized browser with WebKit. Was also quite easily used, except that I gave up when trying to get the Flash plugin to run turned out to be not-fun. Others may have more motivation.

Note that I mostly try these things in Gtk2/3 with either Perl 5 or Vala. Python seems to have very good Gtk/GObject bindings as well, so that should mostly apply the same way. And I'm sure if you look at the Qt and Wx ecosystems there will also be many preexisting useful components, or ways to plug them in.

That is true, and unfortunately I have used Python only sparingly until now, and have no experience using PyGtk at all.

I took a quick look at PyGObject[0] (unsure if that is what one would actually use for this), and the most helpful part seems to be [1], giving some hints on extending GObject.Object, which should be translatable to extending other existing GObject type classes.

As for porting, I agree that can be a pain in that case. When bindings move from a manual implementation to inflating it from an external description. You often end up with good tutorials for the first, and good API reference for the second. If I need to understand other kinds of Gtk bindings, I search for examples on custom TreeModels or other potentially messy things like that to get a feel for it.

[0] https://wiki.gnome.org/action/show/Projects/PyGObject?action... [1] http://python-gtk-3-tutorial.readthedocs.org/en/latest/objec...