zerofan

Rust did a nice job with algebraic data types. Haxe has a very similar approach, and I've loved it since I first saw it. I think this is a very elegant way to define data structures. I listed plenty of complaints about Rust in my other comment, but this one stands out as a "single interesting thing" worthy of praise.

To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries.

I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operators that I can overload from the left and the right, integer parameters for my templates/generics, copy semantics as the default (opt-in for moves), placement new, explicit destructors, and maybe a few other niceties. Rust does none of these things the way I want, and so I'm stuck with C++.

There are a few other things where I think Rust just made the wrong choices and didn't improve over C++. I've always hated the dichotomy in C++ strings between const char* pointers and an actual string class. Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str.

Speaking of integers, Rust's choice of 32 bit integers as the default for literals is painful given that every machine most of us will ever care about is now 64 bit. I routinely deal with arrays and files that are too large for a 32 bit integer. This means I have to remember to suffix all of my integers in for loops etc... C++ has this wrong too (backwards compatibility), but Rust had a chance to make a clean start and did not.

Rush hour traffic is due to human drivers making bad decisions. They knee-jerk the brakes just in case, they rubber neck by accidents, they take too long to accelerate, they try to cut other people off from merging, etc etc etc...

Computer drivers could make much better use of the existing bandwidth on freeways. I'm guessing 6X better, since my 15 minutes drive takes 1.5 hours during rush hour.

It could be a long time before we ever have enough automated cars to realize this benefit. But when that days comes, we could safely increase speed limits too (computers generally have better reaction times).

Taxis are usually disgusting too. I won't take a cab because I frequently feel like I need to shower after sitting in one. I rate Uber drivers almost exclusively by their cleanliness, which is usualy very good.

UTF-8 is a nifty compression scheme - like a Huffman encoding that doesn't require a table to implement, but the committee doesn't deserve any credit for that (unless Thompson and Pike were on the committee, which I doubt).

Besides, the reason most of us actually like UTF-8 is because it leaves ascii alone (which is all I ever use) while pretending to handle the general case. It doesn't help end users or programmers deal with any of the nonsense around multiple ways to encode glyphs (combining codes vs accented codes), deal with surrogates (yes, people encode surrogates in UTF-8), lexical sorting, or anything else. I'll bet there are dozens of incompatible ways strings are UTF-8 encoded in the real world, each of them a bug for interoperability, and all of that blame falls on Unicode being a terrible standard.

So yes, I'm sure.

Unicode is a terrible mess. I remember reading about it with enthusiasm in the nineties, but it didn't take long to realize the committee of designers simply punted on every difficult decision instead of making a stand. They dumped everything on the programmers. At this point, I think it would be less work to convert 7 billion people to using ascii than it would to enable 10 million programmers to use that pile of a standard robustly. History lessons won't help us here.

My last project saturated a cluster of computers for days at a time. Not everyone writes crud screens for day to day work, honest.

Parallelism is about performance, and it seems contradictory to do parallelism well on top of a slow language. Yes, Erlang can call out to other languages, but so can shell scripts.

Erlang is elegant and noteworthy, but you'll get more computation done in a single-threaded C program.

Is there some reason Erlang had to be slow for single threaded things? Mixed language programming isn't desirable for many of us. I suspect Erlang could be fast, with just a few changes, but it never will be.

If you think Rust is ready for high performance computing, I suspect you don't do HPC for a living and you haven't tried to do it with Rust. It's not just missing the needed libraries.

Call it emotional if you like, but I won't use a language that has an off by one error built into its specfication :-)

> I have mentioned in previous threads on the subject that julia's 1-indexed arrays don't matter much in practice because the generic APIs hide that fact most of the time.

My guess is that most people who prefer zero-based feel strongly about it, and most people that like one-based don't care that much. If it really doesn't matter that much, I think Julia should've gone with zero. FFTs, Vandermonde matrices (least squares), polynomials, and pretty much anything where the array subscript relates to the mathematics is cleaner with zero-based arrays.