Haskell's Children

https://owenlynch.org/posts/2020-09-16-haskells-children/

by xiaodai • 6 years ago

176 187 6 years ago

johnday• 6 years ago

Interesting article. I think it's worth explicitly calling out that rather than proclaiming the death of Haskell, this article is talking about the children of Haskell and what they are capable of doing from a clean slate and with a clear goal.

IMO Haskell remains as the go-to language for teaching functional programming and for experimenting with PL concepts. Long may it remain.

Athas• 6 years ago

I also read it as there simply being some domains where Haskell is not well suited.

I like using Haskell for writing compilers, but I would probably not like to use it for numerics code. While I could replace Haskell with Idris, I'm still a bit lukewarm on the cost-benefit of heavy use of dependent types for many programs (although Idris has other nice advantages unrelated to the type system).

k_bx• 6 years ago

To me, Haskell got great at "get things done quickly". With Stack (and Stackage), initiatives like "Simple Haskell", and upcoming RecordDotSyntax, it truly becomes a weapon of pragmatic choice to knock out working software as quickly as possible. And a combination with Elm (and code-generation of Api.elm from Servant types) makes a perfect match for SPAs.

mark_l_watson2• 6 years ago

I just looked through the Simple Haskell web site. I had not seen that before. I liked the Graham Hutton quote on having a secret plan to just use Haskell 98. For years, I enjoyed using Hugs via the iOS app Raskell. I still use Raskell but sadly it is no longer stable after an iOS update a year ago. Hugs, being an interpreter, is so fast for happy hacking activities.

choeger3• 6 years ago

As I said elsewhere, the main contribution of Haskell is the science of programming languages. Without Haskell, we would be stuck with "practical" or "pragmatic" languages like C or Java that do not care much about soundness. Haskell is the science to Rust's engineering, IMO.

johnnycerberus4• 6 years ago

Haskell is the science to Rust's engineering, IMO.

Wut? Rust doesn't have the purity and the capability to isolate side-effects that Haskell has. Rust is popular because of its ownership model that got into the mainstream. We still don't know what are the costs of it.

The only similarity between them is that both are statically typed, expression based languages (ex. Scala, Ruby, Wolfram, LISP) and moved the task of proving stuff from analysis tools to the programmer. But that doesn't mean that Haskell "is the science" behind anything. For what it's worth, Rust is closer to the ML (OCaml) family than Haskell, focusing on performance rather than purity. Though that is also debatable since it doesn't feature a GC and comes with zero-cost abstractions.

Rust has its very own merits. I'm eager to see how it will evolve and what hidden costs will be uncovered.

pjmlp7• 6 years ago

For me the biggest merit Rust brings into the table is that affine types got out of the research lab, and now everyone is looking at ways to balance GC with affine types in most mainstream languages.

scns• 6 years ago

Niko Matsakis wrote his thesis in Scala IIRC. So Scala might have better shot at "the science behind Rust".

pjmlp7• 6 years ago

As if Ada, Standard ML, Modula-3 weren't there first.

When I learned those, Haskell was still Miranda.

johnnycerberus4• 6 years ago

SML inspired many languages: Elm, F#, F*, OCaml, Python, Rust, Scala, Modern Java(which looks more and more like an OCaml on the JVM), Julia

I really don't know why people think Haskell is the pinnacle of everything in PL design.

throwaway17_17• 6 years ago

While I know you are correct chronologically, it is 2020 now I think ‘network effects’ have come to dominate this perception (that Haskell is the language that gives the basis for breaking away from “practical languages). I think Haskell’s presence in the group consciousness of CS-minded developers is, at this point, due to the comparatively large web presence and semi-PR done on its behalf. Simon Peyton Jones almost single handedly pumps Haskell (and I love him for it) more than anyone pushes ADA, SML, and Modula put together.

Ma8ee• 6 years ago

What is genuinely new in Haskell that didn’t already exist in academic languages in the eighties?

kryptiskt2• 6 years ago

Type classes and monadic IO (and having a type system being able to express monads as a thing).

Hammershaft2• 6 years ago

No write up on Unison? https://www.unisonweb.org/

For me, Haskell is on the list of languages (right next to Smalltalk and Forth) that I would like to learn in the future just to experience problem solving from that vantage point, but it's taken me so long to work through SICP that I wonder if I have the time to meaningfully experience all these languages.

eru16• 6 years ago

Just as an aside:

I have fond memory of first working through SICP in my teens. But having recently revisited the book, I realised it's mostly nostalgia.

There are better books about programming than SICP nowadays.

Hammershaft2• 6 years ago

It still has some mindblowing insights to share, but the length is a little intimidating. What books would you recommend instead?

dwhitney2• 6 years ago

Unison is truly doing something different and new. Totally worth checking out.

pjmlp7• 6 years ago

Julia is a child of CLOS and Dylan, nothing to do with Haskell.

https://en.wikipedia.org/wiki/Common_Lisp_Object_System

https://opendylan.org/documentation/

_query3• 6 years ago

Haskell is not at a tipping point yet where it's losing it's excitement. E.g. with RecordDotSyntax and the new haskell language server many longstanding pain points will be solved soon. There's especially lot's of excitement around haskell and web web development. Take a look at what we're doing with IHP: https://www.youtube.com/watch?v=UbDtS_mUMpI&feature=emb_titl... https://ihp.digitallyinduced.com/

Soon you can even deploy haskell web apps in 15 seconds: https://twitter.com/larsparsfromage/status/13066539171876495...

Growing between 5% and 10% weekly. Many new people are starting their journey into haskell with IHP :-) While the community might be changing, it's definitly not dying.

klelatti• 6 years ago

Could you please specify what is growing between 5% and 10% weekly and for how long? Thanks.

mxschumacher• 6 years ago

maybe OP is referring to memory allocation during compilation?

_query3• 6 years ago

Community size. Measured by: Downloads, GitHub Stars, people in our gitter channel, twitter followers, Newsletter Subscribers, Youtube Reach.

E.g. on Sep 1. we had 870 GitHub stars and 321 Twitter Followers. Now (23 Sep) we're at 970 GitHub stars and 487 followers.

IHP has been launched around 3 months ago. So we're measuring it since then.

Olumde• 6 years ago

You can grow by 15% even if you have 20 or 25 users :-P .

I am a huge Haskell fan though. The 'problem' with Haskell is that, because of its roots in academic research the language will not chase success at any price (read hacks); and tends to eventually find solutions to its problems even if it means not being popular for a long time. I like that. Watch out for stuff like linear types[1] coming to GHC soon.

[1] https://www.tweag.io/blog/2017-03-13-linear-types/

dangirsh• 6 years ago

There was a fantastic talk at JuliaCon 2020 about applied category theory in Julia: https://youtu.be/7zr2qnud4XM

fnord1233• 6 years ago

It manages to be much faster than most dynamic languages ... It would be unfair to compare the performance of Rust and Haskell, because Haskell is optimized for things other than performance.

Hmm...

When I first started using Rust, I really missed monads.

Option and Result are Monads. Surely he misses do-notation.

This all being said, I think it is worth looking at the features that are prominent in Haskell that ended up going to Rust ...[list of features that Rust got from SML/ocaml]

Here are the officially stated Rust influences: https://doc.rust-lang.org/reference/influences.html

To say that Rust is a child of Haskell is really overstating the case.

eru16• 6 years ago

Option and Result are Monads. Surely he misses do-notation.

Well, functions and lists are also monads. I guess what the author means is that the language recognises the similarity of those disparate structures.

dimitrios15• 6 years ago

IIRC Rust was influenced more by OCaml than Haskell, but I could be wrong.

The article really rubbed me the wrong way with this tidbit

(we don’t talk about Go…)

So since the author is speaking of "premier system’s language" we choose to ignore the world's premier cloud language? Interesting.

zingplex2• 6 years ago

I'm pretty sure that was just a joke about Go's primitive type system.

JulianMorrison• 6 years ago

I was amused at that. It's clear this author is not Go's constituency. You cannot use types to ensure consistency in Go, you just have to write the algorithm correctly. But Go fronts the algorithm and keeps the noise around it to a minimum. They are opposed but equivalent strategies.

steveklabnik9• 6 years ago

Rust was initially implemented in OCaml, even. But that said, it gained a lot of more Haskell like features later on; we ended up with type classes, not ML modules, for example.

EDIT: also, strictly speaking, Rust doesn't use Hindley-Milner, and we don't have parametric polymorphism.

cgh• 6 years ago

Yes, this was my favourite line:

However, in 2020, the premier system’s language is surely Rust.

Yesterday I was speaking with a friend who runs a small company doing contracted embedded programming (the embedded OS is often Linux but often not) and he'd never even heard of Rust. Maybe it's a little lower level than what's meant by "systems" here but still, the article's statement is just delusional.

rowanG0775• 6 years ago

How is Go the premier cloud computing language? I would say that crown goes to Python. I almost never encounter Go when working with cloud computing.

sweeneyrod• 6 years ago

What does "premier cloud language" mean?

eru16• 6 years ago

Are you saying Go is the 'premier system's language'?

creata3• 6 years ago

Option and Result are Monads. Surely he misses do-notation.

You can find monads everywhere if you look hard enough. But Haskell actually lets you use those discoveries for massive code reuse, while Rust forces you to write stuff like Result::and_then and Result::map over and over again.

To say that Rust is a child of Haskell is really overstating the case.

Right, most of these are common influences. I'd say Rust's main contributions are (a) the ownership system, and (b) painting a thin coat of C++ syntax over ML features to make them more palatable, and neither of these seem all that inspired by Haskell.

fnord1233• 6 years ago

Rust forces you to write stuff like Result::and_then and Result::map over and over again.

The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.

Ar-Curunir4• 6 years ago

You can totally use macros to reimplement do notation in rust, and that's what many crates on crates.io already do.

skybrian• 6 years ago

I guess you could call shorter ways to write and_then or map code reuse, but it's at such a small scale that it seems more like terseness?

Little abbreviations might be widely used, but when people talk about code reuse I'm hoping to hear about ways to share larger chunks of code, not having shorter idioms.

homami• 6 years ago

Haskell's killer feature here is higher kinded types. do notation is just a syntactic sugar. But (with the exception of Scala or PureScript) almost no other every-day language supports the ability for defining abstractions over higher kinded constructs like monads.

bad_user3• 6 years ago

I'm primarily a Scala developer, that also likes Haskell. And you're right.

With the caveat that some languages support an encoding of HKTs. You can encode HKTs in OCaml, Kotlin, or TypeScript for example, and there are FP libraries taking advantage of that. I believe the encoding was inspired by this paper:

https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki...

It kind of sucks, but it does let you work with a Monad type class, and it's better than not doing it at all.

I'm not sure if such an encoding is possible in Rust. I've been told that F# has a hard time with it, not sure why (possibly because of reified generics). In TypeScript and Kotlin it works because the runtime and the type systems are relaxed and you can just force downcasts if you're in trouble.

eklavya• 6 years ago

> When I first started using Rust, I really missed monads.
Option and Result are Monads. Surely he misses do-notation.

Surely you are joking if you are trying to say someone writing haskell would say rust has monads in any practical sense. Sure, all languages have/can have A (or two) monad.

the_duke4• 6 years ago

Option and Result are Monads. Surely he misses do-notation.

Rust does not have higher kinded types, which are required to have abstractions like the Functor and Monad type classes in Haskell.

Option and Result are monadic, but they must implement their own, separate methods and can not share a common interface. Which takes away a lot of expressive power.

There is a accepted proposal for something similar, known as GAT [1] (generic associated types). But that is blocked on other work and might never actually be implemented.

[1] https://github.com/rust-lang/rust/issues/44265

steveklabnik9• 6 years ago

But that is blocked on other work and might never actually be implemented.

In a theoretical sense, sure, but in a practical sense, my understanding is that GATs already exist in chalk, and so it's still a matter of putting in the work, not a question of "is this possible or not."

josephcsible• 6 years ago

Option and Result are Monads. Surely he misses do-notation.

That's part of it. Option and Result are concrete instances of Monads. He misses the Monad abstraction.

ianhorn• 6 years ago

To add to what everyone else is saying, higher kinded types (HKTs) are what make monadic code really reusable. It lets you write code that is polymorphic over a variable kind of monad, rather than code that works for a specific monad like a list. Without HKTs, you might have a polymorphic type signature List[<T>] of a list of some variable kind of elements, or a Set[<T>], or a Maybe[<T>]. In haskell syntax it's List a, Set a, Maybe a.

When you write code that operates on something like a monad, without caring about what the monad is, you want code that has a type like <T1>[<T2>]. In haskell syntax, it's m a. <T1> (or m) in this case is a type that takes another type as an argument to complete a concrete type. AFAIK, rust doesn't have type variables that take type variables (or types) as arguments like that.

Reisande• 6 years ago

https://docs.rs/functional/0.0.5/functional/trait.Monad.html

chriswarbo3• 6 years ago

I'd claim that Scala is also heavily inspired by Haskell: it's probably closer to ML, but so is Rust (which is on the list). Heavy use of 'flatMap' (i.e. monadic bind) is clearly Haskell-inspired, and this is more obvious in popular libraries like scalaz and cats. The 'for comprehension' language feature is clearly inspired by 'do notation' (IIRC Python's list comprehensions are inspired by Haskell's too).

Elm is a more special-purpose child, but seems to have had an impact on JS practices, as a 'gateway' to functional programming. PureScript is also interesting but hasn't had as big an effect.

I agree with the article that Idris is really nice; although I'd lump Agda in with it as a dependently-typed child of Haskell, and contrast them both against Coq (rather than lumping Agda and Coq together).

I've also played around with Curry and found it quite interesting (functional logic programming), although it's essentially a research language.

AzzieElbab3• 6 years ago

More so by ocaml according to Odersky. I would argue that unhealthy obsession with bringing all of Haskell features to Scala actually hurt the language making it seem way more complicated than it actually is

gnulinux4• 6 years ago

I code real life programs in Agda. Some part of my server and my tools are in Agda. One time I was in #haskell freenode IRC channels and people started acting out as if I'm some crazy person. Agda has seemless integration with Haskell. There is almost no friction writing 20% of your program in Haskell (unsafe) and 80% in Agda (safer).

I personally believe, agda is an excellent programming language. It's stdlib is good, concepts and construct are very well-thought out, it's very safe and works surprisingly well. I've been programming in agda for years and almost never had issue implementing anything even though it's not Turing complete. Using sized types you can prove most sane things to terminate anyway. And if you really need infinite loops (say, you're implementing an interpreter of a Turing complete language) then you have many options: (1) disable termination checking for a single function (2) use Haskell to implement a single function (3) use Rust, C, C++ etc to implement a function then with GHC ffi link it to agda.

Maybe I'm just being near sighted, but I'm really surprised more people don't use Agda or Idris in production. The number of times the type system saved my ass is uncountable. You can literally write unittests in your type system it fekkin runs your custom unittests while type checking. How is this not revolutionary? I don't understand.

chriswarbo3• 6 years ago

Wow; I was impressed when I saw someone run an Agda program (rather than declaring success once it compiled).

My main gripe with dependently-typed languages is the amount of wheel-reinventing that's involved; e.g. I might have crafted a "ListOfIncreasing comparisonFunction" type, which is perfectly suited to the problem I need to solve, but then I find myself implementing a map function, a filter function, an append function, a length function, etc. Then I find myself needing a "length of appending commutes" lemma, and an "empty is left identity of append" lemma, and an "empty is right identity of append" lemma, and so on.

It's really nice when it works, as a nice self-contained little module; but any more can get exhausting. I haven't tried integrating Agda with Haskell, but that sounds like a nice tradeoff: do all of the "boilerplate" in Haskell (string plumbing, etc.) to get a "Maybe InputsForMyAgda" value, pass it into whatever tricky algorithm we've managed to implement thanks to Agda keeping us in check, then send the result back into Haskell for throwing into whatever external monstrosity we're interfacing with.

m_j_g• 6 years ago

Did you tried to incorporate cubical agda into some real world development? For me it is cool to let internal machinery handle isomorphism between different types, but cubical agda library is still much smaller than std agda library ;/

Cybiote2• 6 years ago

I enjoyed reading the perspective given in this essay and agree Haskell's been (and continues to be) an influential language. So take this criticism as maybe my being overly particular about the meaning of descendant.

Idris as a descendant of Haskell I have no argument with.

Rust however, is more correctly viewed as (primarily) a descendant of ML languages, which all possess the properties the articles lists as derived from Haskell. Perhaps it is more correct to call Haskell and Rust cousins, both deriving from the same lineage of languages.

I would also not call Julia a child of Haskell. As it is more correctly viewed as an interpretation of Matlab as a Lisp, I'd therefore call Julia a descendant of Lisp. That Haskell single handedly popularized the utility of category theory in computing and that a category theory library is written in Julia does not make Julia a child of Haskell any more than it would have made Ocaml a child of Haskell (there used to be a category theory library written in Ocaml).

The popularization of functional programming, Domain specific languages as algebras, reactive (not FRP), property based testing, parser combinators, model view update for UIs, design principles secretly based on monads are all but a few of the ways Haskell has influenced programming. Which is the core point of the essay and with which I am in full agreement.

This thread somewhat has the air of an eulogy but it goes without saying that just because something is not the most popular in fashion does not mean it is dying.

ChrisRackauckas• 6 years ago

But Catlab.jl is definitely a child of Haskell: the developers have said many times how much inspiration they've gotten from Haskell.

feanaro• 6 years ago

Rust however, is more correctly viewed as (primarily) a descendant of ML languages, which all possess the properties the articles lists as derived from Haskell.

Why would that be more correct? Would Rust have these features if they were not popularized by Haskell? I don't know the answer, but it seems like discussing which language some feature was taken, when more than one contemporary language has it, is a kind of meaningless pedantry.

wtetzner• 6 years ago

Given that the original Rust compiler was implemented in OCaml, it seems natural to assume that's where some of these features were inspired.

Though I'm not really sure that it matters.

chubot2• 6 years ago

I agree, I would call OCaml, Haskell, and Rust cousins, more or less ... descendants of ML.

Though the original Rust compiler was written in OCaml, so depending on your viewpoint it could also be its child. I'm not sure if Rust lifted any features or syntax from OCaml specifically. I think the "O" in OCaml was not influential ...

----

edit: I found a list of influences, and it does credit Haskell with typeclasses, but SML/OCaml and C++ are credited first:

https://doc.rust-lang.org/reference/influences.html

I always thought of Rust as a mashup of OCaml and C++, but Haskell is in there too.

bitdizzy2• 6 years ago

While Haskell has a lot of influence from ML it is also a descendant of the highly influential line of programming languages designed by David Turner starting with SASL. If Miranda weren't a closed source language it perhaps would be what all of us are talking about now.

Some History of Functional Programming Languages (David Turner) https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf

fanf23• 6 years ago

Rust’s two most prominent type system features are lifetimes and traits. Traits aka type classes first appeared in Haskell and are not a feature of ML.

I would be interested to learn of features in Rust that came from ML and that aren’t features of Haskell - not counting strictness :-) I can think of a non-example: one of ML's distinguishing features is its functional (in the FP sense) module system; Haskell and Rust have more conventional module systems.

You could maybe argue that a Rust enum definition is more like an ML type definition than a Haskell data definition because the constructor parameters are tuples rather than curried, but it isn’t clear to me whether this is actual influence from ML, or Rust aiming to be more C-ish.

As I understand the history of algebraic data types and pattern matching, they first appeared in Hope, and from there they were added to ML, and on the separate branch of lazy functional languages they were inherited by Hope’s successors Miranda, Orwell, and Haskell.

Cybiote2• 6 years ago

You raise good points and I suppose valid differences in focus will alter one's notion of nearness. Here's why I made the claim I did:

Rust that came from ML and that aren’t features of Haskell
As I understand the history of algebraic data types and pattern matching, they first appeared in Hope, and from there they were added to ML, and later adopted by Hope’s successors

They appeared first in a practical form in Hope but I'm taken to understand that these ideas could already be found in Programs and their Proofs: An Algebraic Approach and the core ideas are clearly present in this 1968 paper by Burstall: http://www.cse.chalmers.se/edu/year/2010/course/DAT140_Types...

Creators of HOPE, VAX ML (which also had limited patterns and case analysis) and LCF/ML all influenced each other and played prominent roles in the design Standard ML, which would in turn strongly influence future functional languages, including Haskell and Ocaml. It's tricky to untangle the history but I don't think it's controversial to say SML popularized functional programming as prototypically understood today (before Haskell evangelized it further).

Rust’s two most prominent type system features are lifetimes and traits

Other than the initial prototype being written in Ocaml, I'd say Rust's pragmatic feel: eager evaluation, immutability by default but a hatch to mutability and the implementation of the features listed in the posted article all make it feel more like an ML. I agree, though, that this is a subjective take.

_3sno• 6 years ago

I am a fan of Haskell, the biggest problem for me was installing stack/cabal. I eventually got there, but I recall it was a very painful and frustrating process. With that in mind I can advocate for it in good conscience. Managing ghc versions and creating/generating projects should made easy.

I think rust got this right, rustup and cargo are great tools that are easy to install and work with.

tome• 6 years ago

I'm starting a (completely unofficial) project to understand the difficulties involved in getting started with Haskell. If you have the time and inclination I'd be much obliged if you would file a new issue explaining in more detail what points of pain and frustration you encountered: https://github.com/tomjaguarpaw/tilapia/issues/new

mark_l_watson2• 6 years ago

I hear you. I have made playing with Haskell much more enjoyable by doing two things: rely of stack and by have a fast multi core VPS so that long Haskell builds whenever I update to a new stack resolver version. I don’t do much Haskell on my laptops anymore.

agambrahma• 6 years ago

IMO the suggestion for anyone new to Haskell should be "just use Stack". It's easy to install, works out of the box.

Cabal has fixed the problems from a few years ago, and Nix is a nice ecosystem to plug into, but these can get in the way at the beginning, at a point where the goal is to "create my first project, write my first program, build it, test it, run it".

nautilus122• 6 years ago

Haskell done right (TM) is objectively by every means slower. Both in terms of implementation and execution. You end up trading maintenance cost related to design for implementation cost and maintenance cost related to scaling which I may argue isn't really feasible in a pure Haskell approach. I base this upon personally experience witnesses a haskell system serve something like 10 requests per second when a comparable implementation in Scala or rust or go could have easily done 10000

the_af• 6 years ago

How do you know this Haskell system was "Haskell done right"? I'm not trying to be snarky, this is a genuine question. I have witnessed enough disasters (performance or otherwise) in multiple languages to know not draw conclusions from just one or two failures. Of course, consistent failures by multiple teams do point to a problem with the technology itself.

(Then again, maybe you do have multiple examples and/or have strong evidence this system was indeed "Haskell done right", which is why I'm asking).

nautilus122• 6 years ago

Well, its hard to tell not being a haskell advocate, but the people building the systems were haskell experts with years and years of that being their only language and were extremely particular about the implementation, which is part of the reason why they justified the 10 requests per second part, is because it was "done right". My understanding is that haskell is designed is such a way that certain things are impossible to do any way but the "right way", so its also just fundamental by merit of the fact that they were using haskell to solve those particular problems. But it was mostly clout and the fact that the implementation was so thorough and the people building it were like phd level experts in haskell/category theory.

AzzieElbab3• 6 years ago

Elm should have made the list. It is a dsl for creating web uis. Nothing comes close to Haskell’s being a dsl for creating dsls

dwhitney2• 6 years ago

Elm, but not PureScript?!? :)

I use PureScript everyday, and I love it. It's nearly identical to Haskell, with a few small changes that can be described on about a page

AzzieElbab3• 6 years ago

Yeah, forgot about Purescript. Always thought of it as just basically Haskell :)

a_imho• 6 years ago

Rust, Idris, Julia - pretty arbitrary imo.

jjice• 6 years ago

I personally think that the most important impact that functional languages make isn't in their direct use (which can be very powerful), but more so in their influence. Bringing functional features into more main stream languages allows everyone to take advantage of powerful features/patterns.

The first one that comes to mind is pattern matching. All your ML derivatives have had it for years, and it's an extremely powerful concept. Unfortunately, most people (myself included) had never heard of it until it hit more main stream languages like Rust and C#. Streams and the more wide spread use of anonymous functions is another great example of functional concepts making imperative languages much more expressive and powerful.

I don't like writing in pure functional languages very much, but I do enjoy a lot of the power the have and how we can make these concepts more accessible to traditional imperative languages.

callamdelaney• 6 years ago

Erlang pattern matching makes using the language a pleasure, I find Rust's implementation less flexible.

sevensor• 6 years ago

The author seems to like Julia for numerics -- have the language and community improved since Dan Luu's damning review six years ago? https://danluu.com/julialang/

I use Python / numpy heavily, and the giant hole numpy opens in my type annotations causes me grief daily. If there's something better out there, I want to try it, but it has to work. It has to work not just in the "I'm putting together a journal article and I need it to run" sense, but in the "I'm building a system that crunches some heavy engineering numbers all the time, and customers expect consistent results" sense. Can Julia be trusted?

ddragon• 6 years ago

That was just around 2 years after the language became public and 4 years before it became stable, so I wouldn't really call the language "mature" back then (I didn't use the language then to have the insight even if I got before 1.0). From what I can see, the core developers seem to take seriously bug reports, even implementing sophisticated ways to accurately find the source of bugs [1] and running tests on the entire ecosystem before each new tagged release to catch bugs early. There are many large scientific projects using Julia [2], and there are industry leader packages in the area like DiffEq.jl.

The "time to first plot" (a consequence of the aggressive JIT that compiles large programs with heavy optimizations, as Julia doesn't have an interpreter outside of the debugger) still exists, but it is also improving at a fast rate.

[1] https://julialang.org/blog/2020/05/rr/

[2] https://juliacomputing.com/case-studies/

[3] https://github.com/JuliaPlots/Plots.jl/issues/2838#issuecomm...

eigenspace• 6 years ago

Even back then, Dan's blogpost was misleading at best.

lioeters• 6 years ago

The most recent relevant discussion about Julia I found is:

JuliaCon2020: Julia Is Production Ready - https://bkamins.github.io/julialang/2020/08/07/production-re...

Discussion: https://news.ycombinator.com/item?id=24082281

There are comments suggesting that Julia is plenty capable, with libraries covering equivalent (or more) features provided by Python libraries like NumPy. YMMV.

contrafunctor• 6 years ago

OP here.

I just have one thing to say.

In the real world (i.e., unlike in a tree), children have multiple parents.

earthboundkid• 6 years ago

I've made this comment before, while Haskell has succeeded in terms of inspiring other programming languages, as a language for use itself it's a non-entity. Here's a list of all the popular open source Haskell software:

- XMonad

- Pandoc

- Shellcheck

Everything else is just tools for using Haskell (Cabal etc.).

Seriously, compare:

- Haskell https://github.com/search?l=&o=desc&q=stars%3A%3E1000+langua...

- Rust https://github.com/search?l=&o=desc&q=stars%3A%3E1000+langua...

- Dart https://github.com/search?l=&o=desc&q=stars%3A%3E1000+langua...

Haskell has been around for a long time. It's not just "avoiding success at all costs," it's a nothing. It inspired good features like Option and Maybe in other languages, but it itself is on the same scale as Dart.

ehw3• 6 years ago

As someone too dumb to learn Haskell or Category theory, it blows my mind that someone who says he is four years from being a teenager wrote this.

bad_user3• 6 years ago

Working with Haskell requires no Category Theory.

It's a fun language, and if you play with it and its ecosystem, it might give you ideas to import in your own environment.

Pick up a good book, and learn it, because it's fun. And no, you're not too dumb to learn it. Java and its ecosystem can be more complicated IMO, you don't realize it because you've put years in learning it.

da39a3ee• 6 years ago

Agreed it requires no category theory, but I'm an experienced programmer in a few languages and I've found it very hard to learn. I can get to a basic level, where I write rather verbose programs because of all the recursion and immutability, and I sense that I need to make better to use of the core abstractions that the language is known for (those with names which point to concepts in abstract algebra and category theory), and I've totally failed to do that in the two times I've spent a few weeks trying to learn.

Advice gratefully received!

bogomipz2• 6 years ago

The author states:

"The type system in Rust is obviously very influenced by the type system of Haskell, but they also implemented “ownership” which allows for the killer feature garbage-collection free automatic memory management."

I always assumed that garbage collection was simply a convenience offered by a particular language.

I was also under the impression that memory leaks were the class of problems that were addressed by garbage collection and that memory safety was a class of problems that was concerned with things like buffer overflows and corruption and addressed by runtime checks.

However after reading I feel like I have failed to understand the role of garbage collection in enforcing memory safety. Is memory management and memory safety not so cleanly divided?

Could someone explain or point me to a good resource for understanding how garbage collection is used to enforce memory safety?

steveklabnik9• 6 years ago

You can think of it as kind of the inverse of leaks; if fixing a leak is "hey, this isn't used anymore, let's clean it up," fixing memory safety is "hey, this is still used, don't free it yet!"

Does that make sense?

bogomipz2• 6 years ago

Yes both of these responses were helpful. Cheers.

Jtsummers4• 6 years ago

The common memory-related bugs are:

- use after free

- memory leaks (failing to free)

- concurrent and uncontrolled access from multiple threads (race conditions)

Garbage collection helps with the first two. The system will not free memory until it is certain (by whatever method is being used) that the memory is no longer in use. But this comes with a run-time cost. Rust's innovation here is a more reliable way of tracking memory usage statically, and removes some of the run-time cost. Paired with its ownership/borrow mechanisms it also works to solve the third issue, which GC doesn't deal with at all.

adchari• 6 years ago

Garbage collection is also limited, you can still effectively create “memory leaks” if you hold a reference to something you’re not longer using.

markstos• 6 years ago

Perl 6 was also inspired in part by Haskell.

An early version of Perl 6 was written in Haskell, which led to further Haskell influence on the language.

lizmat• 6 years ago

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

zeckalpha2• 6 years ago

All these languages existed 5 years ago... I’m not sold on the time travel premise.

Haskell's Children

Related Stories