--- Log opened Mon Apr 08 00:00:16 2013
15:06 < gmaxwell> HM: I was surprised to see you complain about rust's syntax. I guess ocaml and haskell (and C++, in different ways) have distorted a bit of what "bad syntax" is, but a major goal for rust is making advanced language functionality more accessible to programmers by avoiding highly irregular and cryptic syntax.
15:06 < gmaxwell> HM: the rust devs spend a lot of time thinking about discoverability and obviousness of the syntax. .... if you've got some specific syntax nits, and they're not just personal preference but things you've found will actually bite people, you should go bug the rust lists, because they can still fix syntax nits.
15:23 < HM> the pointer types are insane
15:23 < HM> and it contains unnecessary terseness
15:23 < HM> i don't believe the numbers of characters i can type a second is the bottleneck of programmer productivity
15:26 < HM> in C++ you have weak_ptr and shared_ptr and unique_ptr, which are verbose, but at least you can't make one moments brain fart and use the wrong pointer type
15:27 < HM> example
15:27 < HM> for [1, 2, 3].each |item| { ... }
15:28 < HM> ick
15:28 < HM> anyway, I reserve my right to find it horrid
15:31 < HM> I read up on Rust a few months back
15:31 < HM> right now I can't even remember which pointer is which
15:32 < HM> let y = @*x; <-- i have no idea what this does
15:40 < HM> C++ also has that for loop syntax btw
15:40 < HM> for (auto i: {1,2,3,4,5}) {
15:42 < HM> auto can be replaced by int, double, or any type implicity convertible from an arithmetic type
15:44 < HM> you could probably implement all of Rusts garbage collection semantics by replacing weak, shared and unique ptrs with types that used your garbage collector
15:52 < gmaxwell> You can't generally do GC in C++ because you can't reliably keep pointers from 'escaping' the box. I know it works in theory, but it doesn't work in practice as confirmed by many parties.
15:53 < gmaxwell> HM: Most of the time using the wrong pointer type in rust will result in something that fails to compile and gives you a useful error.
15:53 < gmaxwell> I dunno if thats enough, indeed.
15:53 < HM> because you can always call operator-> on a smart pointer and pull out the raw pointer?
15:54 < gmaxwell> HM: yes, and because actually using them results in you leaving around pointers in local memory, inside other objects, etc.
15:55 < HM> sure, but raw pointers were inherited from C
15:55 < HM> you don't have to use them
15:56 < HM> Rust has the nice luxury that its concurrency and garbage collection can be designed to work well together
15:56 < HM> in C++ you have neither as part of the standard library or language spec
15:56 < gmaxwell> You can try to legislate against it, but even when you control the codebase this observably doesn't work well (there are reasons why it must be violated, or why container objects violate it while you're not looking) - though I'm the wrong person to be debating that.
15:56 < HM> (well except std::thread)
15:57 < gmaxwell> The rust people would argue (with plenty of data to back it up), that in C++ you're basically encouraged to do the 'wrong' thing at all turns due to inertial, legacy, and complications of the right thing.
15:57 < gmaxwell> inertia*
15:57  * HM shrugs
15:57 < HM> i think it's more that you can, and people are lazy
15:57 < gmaxwell> The idea is that rust tries to make it so that when you're lazy you do the right thing.
15:58 < gmaxwell> I dunno if they'll be successful, but thats very much the goal.
15:58 < HM> I like the premise of Rust
15:58 < HM> it's the closest thing out there atm to actually being a new C
15:58 < HM> or C++
15:59 < gmaxwell> And they make the compiler more able to detect the wrong things, facilitating that in the language when they can, and they make you explictly request the wrong behavior (e.g. it takes more work)
15:59 < HM> yep
16:00 < HM> I spent like 2 days this week gone just staring at C++ errors containing type names longer than this conversation
16:00 < HM> i hate it
16:01 < HM> but it's not such a burden to use words instead of symbols all over the syntax map
16:01 < gmaxwell> yea, and partly that comes from really deeply core features of C++ being implemented not as part of the core language but via templates.
16:01 < gmaxwell> You say this, but java's verbosity is a major reason people oppose it. For things which are components a programmer should be using daily it's not clear that its a good thing.
16:02 < HM> sure
16:02 < HM> but const, volatile, shared, "local", would have been good short readable alternatives to ~, @, &, *
16:03 < HM> in a new language, you don't have to worry about squeezing things in to reserved names and syntax constructs
16:03 < gmaxwell> e.g. if you can't keep the pointer types in your head clearly mapped to their symbols you're going to be making a lot of other (perhaps non-detectable errors). There is a right thing to make sugar and a wrong thing. Keep in mind that they're also at least trying to have some appeal to people who believe that specifying types is a huge burden programers shouldn't have to deal with.
16:03 < HM> get back to me when you have a highly parenthesised line of code containing half a dozen @, ~ and &s
16:04 < HM> another example
16:04 < HM> C++11 got hammered for using an ugly lambda syntax
16:05 < HM> ...Rust is using the same syntax for all functions
16:05 < HM> fn recursive_factorial(n: int) -> int { }
16:05 < HM> C++11 lambda:
16:05 < HM> [](int n) -> int {}
16:05 < HM> almost the same
16:06 < HM> I think they've made a tonne of really bad choices
16:07 < HM> at least C++ had the excuse of having to maintain some semblence of backward compatibility with 30 years of C and C++ source code
16:08 < HM> and what about this
16:08 < HM> `fmt!` is a macro that statically verifies a format string.
16:08 < HM> println(fmt!("%d", *item));
16:08 < HM> eesh
16:09 < HM> Boost.Format got formatted strings right
16:09 < HM> don't make the programmer encode type information twice
16:09 < HM> %d = double
16:09 < HM> the compiler already knows the type of item
16:09 < gmaxwell> the C++ lambdas are panned because the syntax is complete moonlanguage especially when its anonymous. Seriously you're complaining that the prototype puts the return type on the right?
16:10 < HM> no, i'm questing why they changed it from C or C++ at all.
16:10 < HM> questioning
16:11 < HM> and kept a lot of other bad garbage around
16:11 < gmaxwell> because the C style leads to severe visual (and in C++ parsing) ambiguity.
16:11 < HM> just because it's familiar
16:12 < HM> what about other weirdness
16:12 < HM> let i: int = 50;
16:13 < HM> let i = 100u;
16:13 < HM> let i = 100i32;
16:13 < HM> one minute the type info is on the left, the next it's on the right
16:13 < HM> ok, so that's copying Cs integer literals
16:13 < gmaxwell> In the latter case the type of i is inferred by the data its being assiged to.
16:13 < midnightmagic> This week, on language wars.. some guys discuss the relative merits of C++ vs. Rust, absent twkm!
16:14 < HM> but in C++ you can do "auto i = 50ul;"
16:14 < HM> or unsigned long i = 50;
16:14 < midnightmagic> HM: May I enquire as to where you were originally complaining about Rust syntax?
16:14 < HM> in -dev
16:14 < gmaxwell> HM: typing litterals is something that can't be avoided... but the actual language feature you're complaining about there is the inference.  E.g. let i = foo();  works and gets the type from foo's return.
16:14 < midnightmagic> oh
16:15 < HM> let y: uint = x as uint;
16:15 < HM> ^ wtf?
16:15 < gmaxwell> yes, thats a cast.
16:16 < gmaxwell> same as float x = (float)double_returning_function();  so that static analysis tools know you mean to do it and won't whine about the narrowing.
16:17 < HM> auto x = (float) double_ret_func();
16:17 < HM> only typed the type i want once
16:17 < HM> the Rust code has 2 operators/keywords and you type it twice
16:17 < gmaxwell> HM: you might well be completely right, what do I know. Smarter people than I create this stuff... C++ is just an endless _sea_ of total wtfs. I don't assume the C++ designers were morons, though it often seems so— I assume language design is subtle and hard.
16:18 < HM> it is
16:18 < HM> and C++ is disgusting
16:18 < HM> but I think Rust should have done better given it's starting fresh
16:18 < gmaxwell> let y = x as uint works in rust.  I'm not sure why you would do let y: uint = x as uint; .. but I don't know that much about rust and haven't written anything other than total toyes in it.
16:19 < HM> well i pulled the example from the tutorial on the rust-lang.org site
16:19 < gmaxwell> HM: it's very likely that each of these things has a reason that someone considers good... or— if you really believe they don't— then hell: post to the list! they are still _actively_ changing the syntax in a way that breaks code. And if crap like that is actual oversight then they would fix it.
16:20 < HM> Nah
16:21 < HM> It's too established to change now
16:21 < HM> that's the style they've chosen
16:21 < gmaxwell> If nothing else they should write a FWTFS that explains these things that apparently offend some on first blush.
16:21 < HM> I'm not talking about quirks, i dislike the overall style
16:23 < gmaxwell> well, many of the things you've complained about here are outright quarks, and I know some are well justified, e.g. the function syntax prevents type ambiguity and the AA BB(CC) problem.
16:24 < HM> ok
16:24 < HM> riddle me this
16:25 < HM> if the Rust function declaration syntax looks a lot like a C++11 lambda
16:25 < HM> why does the Rust closure syntax look completely different?
16:26 < HM> I guess because "fn" is an abbreviation for "function name"
16:26 < HM> seems more like a hint to the compiler than to make it more readable for the programmer
16:27 < HM> let square = |x: int| -> uint { x * x as uint };
16:27 < HM> i would probably expect this to be
16:28 < HM> they use the ||'s for the for each syntax
16:28 < HM> it's just weird
16:29  * HM goes to watch GoT
16:33 < HM> apologies for flooding :S
--- Log closed Tue Apr 09 00:00:18 2013