yokohummer7

> Can you provide a good example of affine types and how they help with expressiveness?

For example, let's say there's an HTTP server handler that must send each header line first, and finally send a body. So you should:

  conn.send_header("HTTP/1.1 200 OK");
  conn.send_header("Connection: Close");
  conn.send_header("Content-type: text/html");
  conn.send_body("Hello, world!");

In Rust, you can construct the API so that you cannot call `send_body` before any occurrences of `send_header`. So if you do:

  conn.send_body("I'm sent first!");
  conn.send_header("Content-type: text/html");

you will get a compile error. This greatly reduces the risk of having incorrect logic in your program. In this case Rust helps ensuring our intention: `send_body` can only be the last call of the request handler. I consider this a good example of expressiveness of Rust (and affine types).

Sorry, I don't have specific numbers. I was saying generally for all GC'ed languages.

> D is more pragmatic

Being pragmatic is a very questionable claim. Its exact meaning varies from time to time, and a property that a certain people consider to be pragmatic can be considered to be not pragmatic by another people. It's mostly meaningless.

For example, for embedded devices D is a no-go from the beginning. I'm not just saying the reliance on GC. D has a few ridiculous behavior that may cost significantly on the low resource devices, such as http://forum.dlang.org/thread/mr6bl7$26f5$1@digitalmars.com D is never pragmatic in this area. But of course, D may be pragmatic in other areas.

> expressive

D and Rust have different kinds of expressiveness. While D has much better compile-time metaprogramming, how do you express affine type in D? In Rust affine type is very fundamental and we can utilize it to define the exact meaning of our programs.

> and generally has better performance (e.g. bounds checking is optional).

What? How can a GC'ed language be faster than a non-GC'ed language? Besides simple numeric evaluation, D is generally more heap-allocation-heavy than Rust, so it can never beat Rust. After all, there's no point in Rust if it's slower than a GC'ed language. The benchmarks you linked are questionable too, as their results say D is faster than C. Are you really sure D can outperform C in general cases?

Actually, as I'm so used to the articles that place benchmarks at the end, I immediately scrolled down to the bottom after reading the preface. Then I realized the pretty graphs are at the beginning.

Anyway, this is an excellent way to present an idea to the public.

That's not my experience. Most Haskellers are indeed good people, but quite a few "vocal" ones are extremely arrogant and intellectually dishonest. Let me give some examples that I've met recently:

- A Haskeller once said Haskell is just as easy as Go to learn. I mean, yeah, many moderately complex languages might be as complex as Haskell, but seriously, Go? It is designed to be as simple as possible. Hell, it even doesn't have generics, which is considered pretty essential in nowadays' statically typed languages. And this claim isn't an outcome of ignorance. He is the author of a very popular Haskell learning material.

- Another said: "Steep learning curve is an interesting expression, because what it actually means is that one is learning quickly." Ok, that's not my interpretation of "steep learning curve" of Haskell.

- "The average Java programmers are worse than the average Haskell programmers" thing. This sentiment even existed in one of the "how to spread Haskell to the industry" presentation. I'm pretty sure if Haskell does be accepted by the industry, it will have the exactly same dumb programmers using it. So, what's the point?

You must be lucky if you haven't met any of them in the Haskell community. Actually, their reputation outside of the community is quite terrible. This must be resolved if Haskell wants to succeed. (And yeah, please stop saying "avoid success at all cost". I know it can be interpreted as "avoid $ success at all cost", just stop it.)

Yeah, actually I recently installed Visual Studio and wrote some elementary F# code. Seeing the IDE and the debugging facility work out of the box was quite pleasant. I'm also sure I could get advantages from the huge .NET ecosystem, although I have no idea where to start because I haven't used MS products until recently. MS's recent open sourcing move made me think about liking and using their products.

That said, I have a few concerns before actually being sold to F#.

1. F# must interact with the remaining of the .NET ecosystem. So, I think F# may have some interoperability features to ease the process. Wouldn't that increase the complexity of the language? This is a similar concern when I evaluate Scala as an alternative to Haskell. The feature set of Scala looks a bit messy to me, nearly on a par with C++. It could be OK if I use only the "functional" subset of the language. But does it really make me free from e.g. null pointer dereferences?

2. Do F# guys actually develop their "native" libraries not relying on the .NET ones? This is similar to #1 but slightly different. I think if the two languages are somewhat similar, and even share the ecosystem, there may arise a tendency to make libraries that work on both languages. But if one makes a C#-focused library it must not be very easy to use in F#. Is this not a concern in the F# community?

That's interesting, it seems that I'm biased because I've primarily seen desktop-ish libraries.

Regarding your usage of `bad_alloc`, I think relaxing the current behavior of aborting will help implement such a behavior. Long-running Rust applications should be resilient to panics anyways, so request handler may regard OOM as just like many other panicking situations. But I have no idea how it would be hard to change Rust's OOM handler to panic. Currently it just aborts.

If you can write programs without garbage collection, why should you use it? Because using it makes your life easier?

To me, Rust is easier to use than both Go and Haskell. Regarding Go, I don't like its inexpressiveness.

Regarding Haskell, I'm tired of its various aspects like

1. Insane defaults. `String` being `[Char]`, `-Wall` is almost always necessary, no record types, `import` imports all names by default, etc. Haskell is clearly showing its age.

2. Lazy evaluation. Not only does it complicate inspecting what's going on, but also it leads to memory bloat. Don't say you can manage it easily. I had tried that.

3. No stack trace. No, enabling profiling won't help, because thanks to lazy evaluation the exact location of the error will not be given to you.

So, to me, Rust feels like a "saner Haskell". Having a trait system similar to Haskell's type class, but without many of its warts.

That said, if there's a mainstream language that is more similar to Haskell but uses strict evaluation, I will definitely be sold. Idris is one of the contenders, but it isn't quite mainstream yet.

You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that doesn't mean it is quite viable. Even popular C libraries just abort when memory allocation failed. Regarding C++, is there really a code that even tries to capture `bad_alloc`? If so, did they test the various OOM situations that the program may encounter? I highly doubt it.

I don't think that the "just panic" strategy used by Rust is pretty. It is mediocre at best. But I also don't think the way C/C++ handle OOM is great. They produce similar results in practice.