4 ms·

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

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.

MichaelGG 11y ago
The most mainstream lang similar to what you're talking about is F#. Excellent tooling support; lots of libraries via .Net, and a reasonable ML with some fun stuff like active patterns. Web dev can use the ASP.NET stack or F# specific stuff like WebSharper (cross compiler to JS, plus web framework).
- yokohummer7 11y ago
  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?
  - MichaelGG 11y ago
    F# has very slick interop. It has first class support for .Net objects, so nearly all C# libs work fine from F#. There are a few exceptions, where library writers take really moronic shortcuts to make up for C# lack of basic features, like tuples and list literals. But that just makes them sightly silly to use, that's all. That's probably less than 5-10% of libraries. F# contains some sugar to gloss over a lot of ugly C# idioms so things generally work surprisingly smoothly. What I find more confusing is C#'s love of mutation. For instance, "fluent" interfaces, where you call an object's method and it returns the same object. I find it confusing in C#, and it seems even more out of place in F#. F# feels less complex than C# - less "axioms". I've not evaluated this even remotely formally, but it's the feeling I have, being familiar with both. F# really is faster and easier to work with. While yes, F# can't eliminate null references (even inside the language, you can force null) it is far less of an issue. F# has some of its own libraries, and then also you'll find wrapper libraries to F#-ise other libs. The F# community seems very helpful and excellent. Even the F# team is far more engaged than C#'s ever was. I'm so impressed that once I emailed them with an issue, and Don Syme offered to get me a custom build to tide me over until my problem was officially fixed. This was well after F# has started gaining stream. They are very nice people, and amazingly competent.

MichaelGG 11y ago

The most mainstream lang similar to what you're talking about is F#. Excellent tooling support; lots of libraries via .Net, and a reasonable ML with some fun stuff like active patterns. Web dev can use the ASP.NET stack or F# specific stuff like WebSharper (cross compiler to JS, plus web framework).

yokohummer7 11y ago
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?
- MichaelGG 11y ago
  F# has very slick interop. It has first class support for .Net objects, so nearly all C# libs work fine from F#. There are a few exceptions, where library writers take really moronic shortcuts to make up for C# lack of basic features, like tuples and list literals. But that just makes them sightly silly to use, that's all. That's probably less than 5-10% of libraries. F# contains some sugar to gloss over a lot of ugly C# idioms so things generally work surprisingly smoothly. What I find more confusing is C#'s love of mutation. For instance, "fluent" interfaces, where you call an object's method and it returns the same object. I find it confusing in C#, and it seems even more out of place in F#. F# feels less complex than C# - less "axioms". I've not evaluated this even remotely formally, but it's the feeling I have, being familiar with both. F# really is faster and easier to work with. While yes, F# can't eliminate null references (even inside the language, you can force null) it is far less of an issue. F# has some of its own libraries, and then also you'll find wrapper libraries to F#-ise other libs. The F# community seems very helpful and excellent. Even the F# team is far more engaged than C#'s ever was. I'm so impressed that once I emailed them with an issue, and Don Syme offered to get me a custom build to tide me over until my problem was officially fixed. This was well after F# has started gaining stream. They are very nice people, and amazingly competent.