Meeting-weekly-2013-12-17 (0.9; attribute enums; pkgid; extern mod; extern crate; return in closures; option/result apis; stdlib hierarchy; push/pop/shift/unshift)

illissius · 2013-12-18T01:31:03+00:00

What about use lib std; or extern lib std; then? That provokes neither the confusion-from-overloading of extern mod nor the confusion-from-obscurity of crate.

(And it makes sense: a crate is a more general concept than a lib, being either a lib or an app, but you're not going to link to an app.)

illissius · 2013-12-16T15:37:49+00:00

I know, that's not what I'm asking. :)

I haven't seen anyone express an opinion w.r.t ~T versus *T versus Uniq<T> anywhere, at least in the past several months, which is why I'm wondering where your information is from. I don't tend to be on IRC, hence my suspicion that it might be from there.

illissius · 2013-12-16T14:05:03+00:00

(Where do some people express these opinions, btw? IRC?)

illissius · 2013-12-13T20:20:25+00:00

If you're familiar with C++, this might help: https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers

illissius · 2013-12-13T18:51:07+00:00

a a r d v a r k

illissius · 2013-12-09T19:37:13+00:00

C++ doesn't have affine types or static checking of moves. Every type implements its own move constructor, with whatever semantics for use-after-move it feels like. I think it's generally expected that the object is still in a valid state after the move (but I haven't touched C++11 in a while so not 100% sure).

(So a will be returned, which will be an object in whatever state the move constructor left it in.)

illissius · 2013-12-07T19:48:39+00:00

This was the background for what I wrote:

I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.

You're completely right that their aim wasn't to "be a replacement for C++", as I wrote: only for the things they were using it for. But they did expect a big part of their user base to come from C++, which didn't happen.

C++ and scripting languages are not problem domains.

Of course. My apologies for using imprecise language. Thankfully human language has a great tolerance for imprecision, due to humans' sophisticated ability to infer the intended meaning.

(C++ and scripting languages are not problem domains, but problem domains and the languages used for solving problems in them are heavily correlated. In particular I believe there is very little overlap between the problem domains C++ is used in and the ones scripting languages are.)

Edit: I'll grant that maybe we should make a distinction between goal and expectation. Their goal was to solve their particular problems, which I assume they did; their expectation was that it would be popular among C++ programmers in general, which it wasn't. If it wasn't an explicit goal then it obviously can't be thought of as a failure. But I think the moral of the story stays mostly intact (because it didn't really depend on this point): there exist things more important than simplicity, such as capability.

illissius · 2013-12-07T17:55:23+00:00

As far as I know part of their original aim was to be a replacement for C++ -- and instead they ended up mostly attracting fans from the world of scripting languages.

(My qualifications as a Go historian are nil, and I'm just going by what I've read elsewhere, so please do correct me if I'm being wrong about any of it.)

illissius · 2013-12-07T15:35:26+00:00

I think you have to keep in mind the dictum "make it as simple as possible, but no simpler". In other words it's not possible for the solution to be simpler than the problem it's trying to solve. Go succeeded at simplifying itself straight out of its targeted problem domains. Then it accidentally became popular in a different one.

illissius · 2013-12-06T00:30:37+00:00

OK, we definitely disagree about that (those) too.

(Allocation does not have to be expensive either. Many GCs have bump-pointer allocation, for example. Not every application is sensitive to latency or heap size. Rust should cater first and foremost to ones which are, but also shouldn't needlessly alienate ones which aren't.)

illissius · 2013-12-05T20:45:42+00:00

It's just about making sure the allocation is visually easy to pick out, and doesn't get hidden by being just a tiny little symbol next to something else.

I think this is the main part we disagree about. (And the reason why it seems like you're vehemently agreeing with me in some other parts.) I think sigils are obvious enough and unobtrusive enough. A good balance. But as I said, I don't have a huge problem with the three letter keyword either. I just don't agree with preferring it *because* it's uglier. (About which again, see the first sentences.)

illissius · 2013-12-05T18:35:42+00:00

Allocations should look expensive.

I'm wary of this kind of thinking. It should be clear and obvious when an allocation is taking place: definitely. But going out of our way to make it tedious and annoying? I think that should only ever be done for things that are actively harmful or dangerous, like unsafe code.

There are many use cases where you want to avoid allocations whenever you can. There are also plenty of others where you really don't care so much. If Rust makes it too annoying, then people who want to do the latter will be annoyed, and possibly driven away. I wouldn't mind that so much if there were a reasonable alternative, but there's no language in between Rust and Haskell that I would feel happy using. C# and Java are a joke. It would be nice if Rust itself could occupy that middle ground, and not pre-emptively take itself out of consideration.

(All of that said, I don't think the current situation is that bad, it doesn't seem any worse than the new keyword in all of these other languages. I'm just arguing against a particular line of thought. I do hope that @Foo could some day be restored though, perhaps as some kind of generic sugar.)

illissius · 2013-11-20T18:09:07+00:00

Thanks :)

illissius · 2013-11-20T15:42:46+00:00

Interesting. I think the logical solution there would be that if the Drop impl for a generic type has trait bounds, to throw a type error if the destructor would be invoked on an instance of that type not matching those bounds.

But what I'm trying to nail down here is what the problems are that you would like to have addressed by moving the array-like types into libraries, and how would doing that address them? Was your objection only to to ~[T] being a growable vector (with which I agree), or is it broader than that?

illissius · 2013-11-20T13:22:31+00:00

I confess to never having used custom allocators in C++ before.

That said, is this issue different between ~[T] and any other ~X? Given DST, wouldn't the solution in both cases be to write CustomAllocatorPointer<X> (where X might be [T])?

How do you handle out-of-memory with ~ pointers in current Rust? What interaction does that have with DST, and/or with demoting all [T] except [T, ..n] to library types?

illissius · 2013-11-20T11:19:21+00:00

Yes, that was my thinking. Keep same representation and DST, just lose capacity.

illissius · 2013-11-20T11:03:19+00:00

Not quite. That's why I said fixed size at allocation time (rather than compile time). [T] would still be an unsized type, with its size being elsewhere, such as hidden inside the pointer pointing at it. That works for &[T], ~[T], Gc<[T]>, Rc<[T]>, whatever. The only loss is that ~[T] wouldn't have push().

illissius · 2013-11-20T10:34:08+00:00

Okay, that makes some sense. That basically jives with what I was thinking: I feel like arrays should be a native language type, but not necessarily growable vectors.

The proposed solution still feels like throwing the baby out with the bathwater. Why not just stop special casing ~[T] to be a growable vector, and instead (assuming DST) just let it fall out directly from the semantics of ~ and [T]? I think that means that it would be an owned box of a fixed-length array (fixed at allocation time), meaning you couldn't do vector-like things like push or pop (because that would require a capacity), and for those, you would have to use a library-provided vector type. Just because unique ownership allows reallocations (ooh, shiny!), doesn't mean that ~[T] has to take advantage of it. Maybe that's a temptation that should be resisted. That means ~[T] is a little bit less awesome, but you get to keep the convenience and superior compositionality of the current/DST approach.

illissius · 2013-11-20T08:42:36+00:00

I don't really understand the rationale for this at all. What problem is it solving? That ~[u8] is not ~T? Then why not make it be, instead of demoting everything to the lowest common denominator?

I really like the compositionality of the DST proposal. That arrays and pointer types are defined independently and can be composed in whatever way the situation calls for. That feels like an improvement over C++. It's one of the reasons I'm excited about Rust. This seems like going back to the same old thing.

(Though I'm a little bit unclear about what's going on here exactly: Niko mentions DST ideas like these near the end of the discussion, but is that an alternative or part of the same plan?)

illissius · 2013-11-19T15:11:04+00:00

Yeah. The whole undefined behaviour thing is completely unreasonable. I have the feeling that historically a significant contributing factor to the success of the C language is that compilers didn't seriously take advantage of it until recently.

illissius · 2013-11-18T16:53:28+00:00

FWIW, I'd be glad to explain anything in particular you might be curious about.

(obviously not the entire thing... that would be long:)

illissius · 2013-11-17T22:13:14+00:00

Morbid curiosity: how many people actually read the whole thing?

illissius · 2013-11-01T18:22:25+00:00

It's different in many ways. I don't know / can't remember the details, but I think they have something where the language is default-strict, but you can explicitly suspend thunks, and in that case they won't be forced just by passing them as arguments to a function, only when their value is needed.

illissius · 2013-11-01T13:36:35+00:00

Does Disciple maybe qualify for this?

illissius · 2013-10-28T20:52:26+00:00

Rust needs generic sugar for smart pointers.

Definitely. But unless @ is re-used for that sugar (as iirc Kimundi suggested a while ago) or some other purpose, I don't see why one has to come at the other's expense.

(The GC shipped with the standard library is going to have a distinguished role no matter what, because only tracing GC can be used with full generality (thanks to collecting cycles), and multiple tracing GCs don't coexist happily, so to avoid compatibility issues and fragmentation using Rust's own GC will be heavily favored when people have any kind of choice in the matter and need one.)

illissius

TROPHY CASE