Hacker News Reader

Comment by jerf | Hacker News Reader

There's always room for another language.

What's hard is cracking into the very, very top tier, the C++, C#, Java, etc. tier. I am also increasingly of the opinion that it simply takes massive corporate backing to get to that level, based on the observation that I haven't seen anything get to that level without it. Python's the only one that has arguably gotten there, I think, and it's still debatable.

That said, I do think that if you want to make a new language right now and really see it take off, you do need to find some problem that isn't well-solved, or come up with a reeaaalllly novel combination of things that didn't exist well before. It seems to me that this project is going to be shadowed by Haskell in a lot of ways.

But that's only if you want to see it take off. Not all languages are put out there with that intent.

View on HN

Seems a bit contradictory. Which is it, corporate backing or novel ability?

I would like to see language advantages better quantified. How confident can we be a language is a practical improvement, in what contexts is it true, and what do the improvements buy in cost, quality, innovation, etc.

If we had all this data for a new language it would probably be easier to gain critical mass.

No one is funding these studies, so I wouldn't hold your breath. It is down to you to decide for yourself. As an anecdote, I switched to Haskell professionally 5 years ago and am both happier and more productive.

Interesting. Would you say it's the most productive language you've ever worked in?

What's your best guess as to how well this would apply to developers in general?

Once I used a tool chain with a steep learning curve, but I felt the rewards were clearly worth it. However, with that particular team it was difficult to get buy in. It seems not everyone is interested in a little pain for a lot of gain, especially if the concepts are very different.

Not the OP, but I don't think Haskell will ever be drop-in replacement for mainstream langs for cultural reasons, but that doesn't mean that those who do engage w/ it don't get get tremendous value from it or fail to find it their favorite language (I.e. Doesn't contradict what willtim said). And I think that's OK. (No, you're probably not going to convince a bunch of rubyists to use haskell). You can even train entire teams of willing Haskell developers from scratch, if needed. But the desire / buy in has to be there. IMHO anyways

Part of the problem is that dev is so large that it is hard to make "in general" statements anymore.

It's easier to talk about concrete/specific instances or cases

Yes I agree. Haskell is a powerful principled general-purpose language, but not everyone will need this.

But this does not mean I am happy with the current mainstream status quo :)

For me personally it is the most productive and expressive language I have worked in.

There is a steep learning curve, which will make one a better programmer, but not without significant buy in. There is no free lunch.

Haskell is very expressive with its types, especially with regard to when effects happen, which makes it excellent as a shared design language. It's interesting for me to see Java/C# programmers struggle to explain some of their more modern stream abstractions to each other:

http://stackoverflow.com/questions/28459498/why-are-java-str...

The answers above are unable to explain succinctly what the APIs are doing, because the authors lack the necessary common language. They have to answer with wordy essays describing various scenarios and use cases.

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

Ocaml is close. Not sure how their concurrency is going, but I'm sure the act of mentioning that will bring someone out to bring us up to date.

Compared to Go, OCaml is unfortunately a rather large language. It has many non-orthogonal features, some of which are not used widely. The impression I get from Go programmers is that the small size of the language is one of the chief attractors.

> Compared to Go, OCaml is unfortunately a rather large language.

I agree. That said, ML is definitely a small language like Go, without OCaml's extras like the object system.

Alas, ML lacks Go's awesome and very modern standard library, which is a key part of Go's allure.

But yes, I would adore a functional language with Go's best features, particularly the standard library, solid concurrency, simplicity/ease-of-learning, fast compiles, binaries, static, etc.

There's also Standard ML, which smaller, and fully specified, with multiple implementations.

But I think part of the problem with both is tooling. Build and dependency tooling in particular. Opam was a good step in the right direction, but I think OCaml and SML could both benefit from a Cargo-like tool, that made managing projects and their dependencies simpler.

There are several libraries for concurrency: - Lwt: https://github.com/ocsigen/lwt - Async https://realworldocaml.org/v1/en/html/concurrent-programming...

However pulling these over more than 1 core is still a problem. OCaml 4.05.0 should have infrastructure for that (although OCaml multicore has been somewhat a `duke-nukem forever` story)

How about Rust, no fast compile though.

With

  cargo check

It's significantly faster than before for type checking etc during development, which is I assume the point at which most people complain about compile speeds.

Rust?

Rust doesn't have fast compile, and I think it's hard to argue that a language without TCO is a functional language. Recursion is a critical part of the functional paradigm.

Also, I think a lot of people are attracted to Go because it's very simple to learn and use. Rust with its borrow checker is definitely not simple to learn and use.

But it's true Rust has some functional features.

That simplicity comes at a cost. The cost is duplicate code, less strict error handling and the billion dollar mistake.

I know that some people downplay the importance of these things; I find that because Rust has strong guarantees in these areas it helps to reduce work, reduce bugs and increase confidence in the software.

And use 'cargo check' during Dev for faster compiles.

> That simplicity comes at a cost. The cost is duplicate code, less strict error handling and the billion dollar mistake.

In Go, I agree. But that's not necessarily the case for all simple languages. Take ML, for example. It's a very small, easy-to-learn language with excellent abstraction features that make it easy to avoid duplicate code, as well as excellent static checking and error handling.

Unfortunately, ML lacks a comprehensive, modern standard library like Go has.

Haskell?

Some of it's parallelism and concurrency features should look familiar to you (it has an M:N threading model), complete with channels, and some stuff you've probably never heard of like STM. It compiles to a binary, has a type system much more powerful and expressive than Go's, and the community is very helpful.

I will say the compile times aren't very speedy, I assume you want fast compile times in order to type check your code, and for that there is ghc-mod.

"It compiles to a binary..."

That's one of the things I love best about Go. Compile for your platform, then copy the binary somewhere else and run it. Awesome.

I really want this to be true for Haskell too, but there's a glaring exception with libgmp. Google "haskell libgmp" for many stories of people thinking they could just copy their haskell program to a new system and run it, only to realize they were wrong.

I'm sorry I don't understand, the results seem to be about people having difficulty installing GHC, not deploying a binary. I can say anecdotally I've never had any problems.

edit: Ah ok, apparently libgmp is dynamically linked in binaries, but you can pass a flag to GHC to statically link all runtime dependencies. Is that what you were talking about?

this thread is like that time when there was a post about common lisp and then everyone started talking about clojure

There was a small attempt to what you describe: https://github.com/oden-lang/oden

Reply on news.ycombinator.com