frowaway001

  1) You basically have both () and [], wasting one of the scarcest
     resources in syntax (brackets).

     Some people might argue that getting a value from an array is totally 
     different from getting the same value from a function or a map, and
     deserves special syntax. If we look at languages which did away with 
     this made-up difference we see that pretty much no person is missing 
     it.

     Even if you disagree with this reasoning and consider arrays to be 
     something very special, deserving its own syntax – guess what? Rust 
     developers introduced the traits Index and IndexMut, so all the great 
     ideas about some type being special and knowing what happens when you 
     read [] went straight out of the window.

     If we dig deeper and try to understand why they did something so 
     astoundingly mis-designed, we basically hit an interesting issue:

       They overloaded their [] operator to do two completely different 
       things, depending on whether there is an & in front.
       Thing A: return the value at the given index
       Thing B: return an address pointing into the indexed data

     This of course doesn't translate well into the () syntax, given that 
     Rust devs are proud that they don't support overloading.
     (I guess []'s overloading doesn't count for some reason ... and doing 
     the little dance with traits doesn't count either.)

     Taking a step back, if it would have been considered acceptable to 
     pick two different names for doing two different things, the whole
     issue wouldn't exist, e. g.:

       Thing A: values(1)
       Thing B: values.at(1)

  2) Yes, we agree. Having different sets of rules for a) language 
     designers and b) language users has shown consistent results:
     It never worked out.

  3) Yes. I have nothing against terse syntax, it should just be 
     consistent. (I favor not abbreviating things though, because it's
     difficult to be both terse and consistent, considering that things 
     can be abbreviated in more than one way.)

  4) Yes, I know what they do. I just thought it was a nice example of two
     related constructs having different casing style and abbreviation 
     style.

  6/7) See 1). The sad thing is that [] can do whatever the developer 
     wants. All guarantees went out of the window with Index/IndexMut.

  9) What I meant was that not every macro wants to define some weird 
     language DSL. There are plenty of things which only exist as macros
     because the language lacks varargs. (vec! for instance.)
     If the language ever adds varargs, vec! can't just stop being a macro, 
     because that would break source compatibility: They would need to keep 
     the macro version of vec and introduce a new non-macro version of vec,
     and hope people migrate from vec! to the "new" vec.

     It's a design which makes the common 90% suffer for the benefit of the 
     most complex 10%. Sometimes it is worth it, but in this case I think it is
     not.

 10) I had the combination of picking a symbol which is both hard to read and
     hard to parse in mind.

     Every language that chose <> has weird cruft and therefore it shouldn't 
     haven been too surprising that Rust is also suffering issues, but in 
     Rust's case the problems have been shokingly severe. There are loooong 
     discussions about it if you want to read them. (So it's not just me.)

 11) Sorry, I meant structs.

 12) URLs are an option. There are also alternatives. I think the essence is
     that it's possible to deal with these issues without entering Java's
     tld.mycompany.mycontinent.mygroup.myproject.mydogsmiddlename madness.

Not to mention you are quite puzzlingly wrong on many accounts.

I'd love to see an example where this is the case.

you're still iterating over the list twice

There is nothing about higher-order operations that would require developers to implement xs.map(...).map(...).map(...) or xs.Select(...).Select(...).Select(...) or whatever as multiple traversals over the data structure.

The problem with the fancy syntax is that it makes it too easy to write suboptimal code that you'd never write if you were writing plain old for loops, like the above.

Maybe Google should just invest in hiring better people? I know it's getting increasingly harder to find people who still haven't evolved from the 1960ies mindset, but still ...

It is perfectly fine that many design choices in Rust evolved from "let's copy what $random_language did", but mentioning the drawbacks of that kind of approach to language design suddenly requires "scientific studies demonstrating your points"?

Are you kidding me? That's exactly what I meant with "Rust people are actively hostile toward input".

It is even more "I don't want to hear what you say" than it appears on the first look, because we both know that counting all "scientific studies" about language design probably wouldn't require more fingers than a human usually has.

So all we have is some empirical knowledge. You even got some findings for free! Things no one ever said:

  - "Having two different ways to call/invoke/execute stuff
     made it much simpler to learn the language."
  - "Making the casing of types inconsistent really helps 
     when reading code."
  - "Dropping random characters in functions and types made 
     me feel at home coming from C! I would be terribly 
     confused if ptr was called pointer, vec vector, fmt 
     format, iter iterator or rt runtime. The only thing I 
     don't like is FromStr, it should really by FrmStr 
     instead! .. I love str's rsplitn btw!"
  - "Calling Strings Strings and String views str ... that 
     makes a lot of sense!"
  - "Having used both <> and [] extensively, <> is much 
     more readable."
  - "It was a really great idea to have special syntax for 
     arrays, so the language designers could overload [] 
     with two completely different meanings."
  - "Having both () and [] available is great because you 
     can write code where foo(x) and foo[x] do different 
     things!"¹
  - "Not having varargs really worked out! Nevermind that 
     most popular macros exist solely to emulate varargs!"
  - "Despite most macros not needing the do-whatever-
     you-want syntax, let's require ! for all of them. This 
     way, macro writers don't have any reason left to try 
     making their macros behave predictably! Isn't it great 
     that they can just claim 'you knew that all bets where 
     off when you wrote that !, so stop complaining!' 
     instead of fixing their macro?"
  - "Fucking up Generics so badly that it requires 
     different ways of writing them depending on the 
     context really paid off. It's certainly not an issue 
     which is hit by every person writing something Generic 
     for the first time."
  - "Inventing unnecessary differences between modules and 
     objects is great, because it forces you to think 
     whether you need to use . or :: and breaks use-sites 
     of that code when migrating from one to the other."
  - "Given all the lessons of terribly broken dependency 
     management systems out there – let's just ignore them 
     all and put every package in a global namespace ... 
     what could ever go wrong?"

So why bother evoking any more excuses in different places? Rust-the-bad-parts is basically unchangeable now.

So what's left? I think it's only honest if Rust devs would be more open about the mistakes they made, and wouldn't require outside expertise to point out the issues.

¹ WAIT ... that's actually what Rust devs said when they defended having both () and [].

It says a lot about Rust's culture. If they are not only _not_ interested, but actively hostile towards input, why should I bother?

Just look at the replies. Sure, it's possible to hand-wave issues away by setting the standards low enough with "Java did that mistake, too", "we just copied that from Python", "this looked more familiar" ... I think no one disagreed with that.

It's 2015, and having marketing along the lines of "we only made half of C++' mistakes" just doesn't cut it for me anymore.

For other people it might be good enough, but I'm worried that Rust won't get enough traction if the language is not drastically better on average than its incumbents, but just messy in different ways.

Yes, but getting 8 downvotes in two comments ... why should I care?

At least people use it, which is more than what could ever be said about Haskell, so it had a larger impact overall ... while getting things done at the same time.

You only need to have one look at it's module system/Cabal/Hackage to see that it was never intended for larger code bases than people's PhD thesis.

Yes, it can scale: In the same way PHP and JavaScript does.

Apart from the Rust's usual rule to invent some abbreviations, but only apply them half the time.

Then "types start with an uppercase letter" except when the language creators break their own rule.

Then the fun "sometimes we use () and sometimes we use [] to do practically the same thing".

Then the various insanities with ::.

Then Generics. How many examples of languages which tried to use <> for Generics do we actually need before people learn the lesson?

I really wished some people took Rust, and wrote a new frontend to get rid of all the pointless inconsistencies and other "C did, so it has to be good"-isms (like_all_this_underscore_stuff or the ridiculous abbreviations), because many ideas of Rust are not only good but brilliant and deserve to be put into languages which don't belong to the purely-academic category.

I really wish Rust to succeed, but can we stop this approach of "3 steps forward and 2 steps backward" to language design?

Most other things (like the ones you mentioned) require a level of expressiveness that Go lacks.

  SQL: Pointless without Generics.
  Cache layer: Pointless without Generics.
  ORM: Pointless even with Generics.

What reason is that?

Groovy made Java slightly less painful too use, but added its own warts.

Today we have languages which are better than Java without adding all of Groovy's mistakes.

They're an Apache supported project now.

You mean the place where software projects go to die?

Groovy and Grails have lost their reason for existence years ago, and without the sponsoring they are both dead.

Not everyone wants good enough; some people want an excellent, purpose built language for the web with all of the goodies we’ve come to expect on Day 1--no polyfills, no hacks, no waiting for a years long standards process to run its course.

Yes, absolutely; and Dart just doesn't fit that bill.

It's kind of telling that they feel that they first need to tell Go developers what an AST is ... PHP redux?

"Why should I ever wash my hands before a medical procedure? It just makes things more complex!" –– Surgeon, ~1700.

Compilation to JS is a few additional seconds during development, and the rest of your comment is right to the point.

So why would I use this given there are languages which

  - are much better than Dart,
  - run in the browser and
  - run on a crossplatform VM which is much better than DartVM?

Then pick Scala.js.

Solid, mature, great libraries and one of the best languages out there, even when competing against real (in the sense of not compile-to-JavaScript-only) languages.

Sounds more like you never actually checked the available options.

Scala.js, Elm, PureScript, ...

Dart is the innovation.

Dart is the most ambitious compile-to-JS option.

Wait WHAT?

Not sure if this is supposed to be irony, but if not I'd like to understand your opinion on this.

This is only about the Dart VM, not about the Dart language.

The writing is on the wall already. If Dart hasn't the chance to become a natively supported language, why would anyone pick it as a compile-to-JavaScript language, given there are so many superior options?

If you ever wondered why Lispers were considered condescending, arrogant, self-absorbed dorks back in the old ways reading LoL might give you a few hints.

I can't recommend that Clojure people read Hoyte's masterpiece, because Clojure is the first "larger" Lisp without a completely horrible community and I'd like to keep it that way.

Just when people thought that we had one less useless language to deal with ...

Or just terrible syntax choices like in Java or Rust.

I think pron knows what he's talking about, considering that's all what he does in pretty much every Scala-related submission.

He's not hating Scala, he's just desperate selling his 5 years out of date opinion about it on every occasion he can find.

Currently, Scala is an impure language.

There is some research going on how Scala can start checking and enforcing purity. Having an IO type constructor with the usual monadic convenience operations is one possibility, but people are actively looking into other approaches.

OCaml compiles pretty fast, especially if you target bytecode.

Yes, but OCaml doesn't "offer very similar functionalities".

Haskell is quite a bit slower if you consider that you often have to compile not only your own code, but also the sources of your dependencies in the beginning. Additionally, you have to fight with Cabal, which tends to be very unpleasant due to the lack of any reasonable support for exotic things like "versions". Then you might discover hacks like "sandboxing". Hours not spent coding.

    It's crazy that in these slides he says "I wanted a
    hipster language" -- most languages use [] for arrays so I 
    used (). WHY!!!!? Just to be different? No actual real 
    advantage? That's a terrible reason and a great way to 
    make it hard for new people to adopt your language.

Scala does things for a good reason. Not caring to figure out the reason doesn't mean the language is wrong.

There are some really really desperate people in this thread who keep posting this "the sky is falling!!!" type of claim in every Scala-related submission. :-)

One issue I have with it. I don't think it's complex, but I think people are not spending the right time learning it. People learn the subset of features they like and stay with it, and because there are so many ways to skin a cat with it, everyone have their own style. It could have benefit from the concept that other languages have of "there is always one best way to do things".

I think that's the dark side of having both the OO side and the FP side working well.

I'm not sure if I want something like OCaml, where everyone tells you to just ignore the OO part of the language.

---

I think the talk mentioned all the right things, and shows that the people in charge listen and address issues raised by the community.

Also, just look at the productivity. Which other language can claim that people work on a redesigned compiler, a new IR, a shared bytecode backend, and a rewritten macro engine at the same time, in addition to developing and evolving the current language, compiler and library?