Hacker News Reader

Comment by Koshkin | Hacker News Reader

F# (and ML in general, despite having been around for a while) looks like a programming language of the future. It occupies just the right place between the two extremes - one being purely functional languages (Haskell, Scheme, etc.) and the other being taken by all sorts of imperative languages (C, PL/1, Java, etc.), which - from a certain standpoint - could all be viewed as derivatives of the assembly language, and which, therefore, should have been long abandoned in favor of languages worthy of the name 'language' as the medium of human thought.

(Unfortunately, the two modern languages - Go and Rust, despite showing so much promise, appear, from this perspective, to be following the wrong path.)

View on HN

Not sure about the contrast, I looked at F# after Haskell exposure and "it seems fairly similar to me". Sure you have some minimal notion of some OOP constructs so as to be able to do the .net interop where necessary/beneficial, but other than that, I remember looking at it and thinking "oh cool, in .NET there's something with a lot (more than enough) in common with Haskell, good to know on the off-chance I might land a .net rewrite gig (or win app dev gig) where I get to have a say about language choice but not platform choice"

Go and Rust aren't "following the wrong path" IMHO but are great tools fit for purposes other than the ones Haskell or F# can excel at. The former are great for high-speed crunching, OS/network interops and transformations of massive volumes of say byte (more so than richly parsable text) formats, state machines, simple SIMD parallelism (where locks/mutexes etc aren't a major concern).. whereas the FPs excel at richer expressiveness for business domain models, workflow rule engines, of course also (and certainly even related) (e)DSLs and parsing / AST transformations+rewrites, propositions etc

JAHO (just another humble opinion). In the end they're all turing-complete so you "can" use any for anything

I'm also generally a fan of multi-paradigm languages (such as OCaml, Scala, and F#), as pure languages often run into the problem (somewhat simplified) that they handle 80% of all problems well, 10% adequately, and 10% poorly.

At the same time, I'm extremely skeptical of naming any single language the "programming language of the future". Application domains are simply too diverse for their problems to be solved adequately by any single language. On top of that, different people seem to think very differently: some have an easier time with a predominantly functional style, others get more mileage out of object-oriented programming (which again is completely alien to others) and so forth.

If there's one thing that I'm fairly certain of is that there's no such thing as a one-size-fits-all solution in the realm of programming languages and environments.

Rust is very much ML. It's the systems programming token salad that makes it look like C++, but if you squint you can see it looks a lot like ML. As does swift.

Rust was originally written in OCaml. The ML languages are great for writing compilers.

When I did my CS degree, Lisp, Prolog and (back then) Caml Light were forbidden in our compiler design assignments, because it would be "too easy".

I honestly can't see that. Functional programming and ownership are concepts that just don't mix well. Just think about OCaml's Set module (which uses balanced trees with partial sharing of subtrees as the result of set operations, if you look at the implementation).

Linear types (ownership) are used in another ML-inspired functional programming language, ATS.

> Functional programming and ownership are concepts that just don't mix well.

Of course they do, ownership is part of substructural type systems, more precisely affine types.

The particular problem I was getting at was that the structural sharing required by purely functional data structures is not a natural or easy task when you're restricted by affine or linear types.

Several idiomatic functional programming techniques are similarly difficult to express with the additional invariants of affine types.

Yet there are quite a few programming languages considered functional with substructural type systems.

Being easy or hard is not what defines FP.

Well, that was in the context of the claim that "Rust is very much ML". We weren't talking about (say) BitC here.

I've got nearly two decades worth of ML code lying around (mostly OCaml, some SML and F#) and for most of it rewriting it in Rust would require significant redesign for the reasons I mentioned. This starts with even very simple things like List.rev.

> We weren't talking about (say) BitC here.

No, we are talking in the context of ATS, LinearML, Idris, Mercury, F* and a few others.

When writing high perf F#, I wished for ownership capabilities to rely less on the GC and really get some speed. While Rust is a bit verbose, doesn't have custom operators, can't do pointfree, etc. -- it's not a bad FP language. And all the while, I get to think of how fast the code is, so that's often worth it. Rust does FP better than C# has done.

I've implemented balanced trees with partial sharing of subtrees in Rust too. Just use Rc everywhere.

Well, that's my point. Rc<T>/Arc<T> essentially mean: "I can't figure out ownership here; let's use automatic memory management instead". The thing is that this is pervasive in ML (even simple functions like List.rev – functionally reversing a list – are a problem), so you end up having Rc<T>/Arc<T> all over the place. The underlying problem is that pure functions from data structures to data structures create multiple ownership naturally.

Remember that this is about the claim that "Rust is very much ML". It really isn't. It's a totally different programming paradigm. That's not bad. Rust does some things very well that ML has a hard time with. But it's not the same.

> Go and Rust,

Rust is not ML but takes a lot of ideas from ML and functional languages, such as options, pattern matching, traits and "type classes" ...

Go is just bad feature wise for a language born after 2005. It's a good language for managers that don't trust their developers with their intelligence though, and will lead to a generation of developers who can only code in Go, because using anything else is "too complicated"...

> Go is just bad feature wise for a language born after 2005. It's a good language for managers that don't trust their developers with their intelligence though, and will lead to a generation of developers who can only code in Go, because using anything else is "too complicated"...

I've argued that some minor updates to SML with actors/csp and a couple more primitive datatypes (esp unicode strings) would result in a language that is both easier and far more powerful than go.

And the same can be said for elm on the web dev world. It's a nice compromise between haskell and friendliness, allowing a greater adoption. In the not-so-long future, Elm will be able to take advantage of web assembly and ditch javascript (almost) completely.

By no means imperative languages will disappear, but I too share the opinion the future is bright for f#, elm, erlang etc.

Ditching JavaScript for Web Assembly in a language like Elm would require Elm to ship with a GC. Certainly possibly, but it doesn't sound like fun.

WebAssembly has no way of directly interacting with the DOM. It has to use JS interopt which is quite slow. It'll take a couple years to get Wasm up to speed. It'll be a couple more years to add the rest of the low-level interfaces and even more time to deliberate about a GC spec (you don't want to ship apps with entire language environments attached). It'll be a couple more years to deliberate over new DOM APIs and a couple more to implement them. After that, it'll be a half-decade or more until old browser share drops low enough to use it without needing a JS equivalent.

Rust has a large ML influence from what I've seen. Pattern matching, restricted mutation, sum and product types, and traits immediately come to mind.

Are traits really an ML thing? To me, they seem more similar to Haskell's typeclasses (and by "more similar to", I mean "almost exactly the same thing as"). From my somewhat limited experience with OCaml, it seems like the closest thing it has to traits is modules/functors, which seem to work fairly differently (i.e. traits are "added" to existing types, whereas functors are used to create new types).

Yep traits are definitely like typeclasses.

Well F# might get it when Shapes gets into C# (C# version of traits/typeclasses which is being discussed)

Having used F#, I find Rust to be much closer to following the "right path". F# may have mode some good choices initially, but it strays back and forth between intuitive and straight-up senseless regularly. It lacks most of the elegance in other MLs and lacks much of what makes C# usable with its own feature set, rather choosing to create a weird concoction of the two styles with little thought behind it.

> one being purely functional languages (Haskell, Scheme, etc.)

You can easily do imperative programming in Haskell using IO. There are even lots of straightforward bindings to C libraries, directly exposing C functions. There are IORefs and so on.

Not sure about Scheme, usually lisps are quite imperative.

In Scheme, variables bind to locations, and you can reassign values in those locations. So no, not pure in any meaningful way.

Reply on news.ycombinator.com