Hacker News new | ask | show | jobs
by AtlasBarfed 1651 days ago
r/Haskell/Lisp -> same problems

The functional language conceit exists and its a problem.

It's interesting that Go is mentioned as a target of the conceit. Well, there is a LOT of important software in modern IT systems that is golang based. There has been impressive productivity from that language and its programmers, and I'm someone that doesn't like golang.

Functional languages just haven't produced something on the scale of Kubernetes, or a database, or a web framework, or... really anything. Not even something like Ruby on Rails, which is now replaced with JS flotsam/React, but was significant.

Functional languages seem to assume that you build it and they will come. It hasn't happened.... like ever. The quip is if you keep doing the same thing expecting a different outcome, then that is insanity.

What functional languages need is a significant application. Since they are (theoretically) better for multicore and we are in the age of core scaling rather than serial speed improvement, and have been for a decade... WHERE IS YOUR APP?

It has to be the IQ filter. I simply think that FP requires higher IQ people, and that filters out a massive amount of people that just want to get stuff done and go home to their families or rave. Once you get over a certain IQ threshold, then the people in that cohort actually repel other people. If you've ever been to a Mensa meeting, you should know what I mean.

I think Rust is fine, it is focused on practical goals: rewriting vulnerable C programs, improving Firefox speed and safety, etc.

3 comments

The only Haskell program I have heard of normal people using is Pandoc. Some people use Git-annex.

I don't know of any Rust program many people not coding Rust need. There are plenty of rewrites of existing programs, such as ripgrep and alacritty, but neither offer compelling reasons to switch. (Grep speed has never been an issue, for me, and kitty is much faster than alacritty.)

Rust still has no compelling usage story, such as a program that people need that would be so hard to write in some other language, instead, that no one has succeeded. (People talk up Servo, but who is using it?)

I am not a rust coder at all. Rust is doing a pretty big and ambitious project that isn't the typical "hey here's a new language to try". Rust goal is to be an ecosystem-mature replacement/alternative for the C/C++ toolchain, libraries, infrastructure.

That's a biiiiiig ask. Absolutely massive. The fact that there is some Linux movement in supporting rust in the kernel shows it is largely successful. While you're right it doesn't rise up to "show me the apps" criticism, it is a big win.

"Show me the apps" is not a criticism that you CAN write apps in it. All I'm saying is that something is culturally wrong, because the people that want to write practical, useful, mass-market software choose NOT to use functional programming, even though it has allegedly massive advantages and superiority.

The lisp essay by Paulie guy is informative: it enabled a really smart programmer to outscale a team of programmers, but it hit its limits. It did not scale beyond that, and was, I suppose, too inscrutable to be picked up and supported by others.

So was it Lisp that allowed him to compete for a while? Or the fact that he wrote it and knew it top to bottom and was really really smart and motivated? Probably a bit of both, I personally would argue 80% superprogrammer, 20% language.

The Rust in Linux thing is a lark. Anything you might do in the Linux kernel that you might do in Rust would be much more cleanly and easily achieved in C++, if not for Linus's rabid diatribes: every single thing he criticizes in C++ is in Rust, too. The inventor of the RCU synchronization primitive the kernel relies on spends most of his time with C++.

So, I expect Linux kernel Rust will fizzle, regardless of what happens elsewhere. Maybe Redox will get traction, or Fuschia kernel will be recoded in Rust.

Wait until you find out about Elixir and its web framework Phoenix. $10 hosting, 2000+ reqs/s with 100% parallelism.

Before you say it, it's quite popular and used already. But there's a barrier beyond which a lot of programmers just don't tread, and will stay in Python / PHP / JS regardless (while raving about how awesome Elixir is).

My guess is market size and job security concerns but who knows, maybe some of what you say applies as well.

This is more apt than you know.

If Rust finds only the amount of penetration that Erlang has, it will have failed.

I guess this will always be a contention point since the definition of "failed" is very flexible.

I'm well aware that Erlang/Elixir are still niche, and Rust is kind of niche as well. But by what measure? Usually it's a comparison with e.g. Python, Java, JS popularity and usage. In that regard 99% of the technologies out there have "failed".

I find such comparisons meaningless however. In the segments of the technologies I work with there are a lot of things happening, there are very good money to be made, and productivity is usually very high compared to the "successful" technologies.

So everybody is free to look skeptically at the "failed" technologies and "wisely" conclude that if they were THAT good they surely would have displaced the mainstream ones by now, right? Hence they can't be that good, m-hm, no sir.

I have no objection to people thinking that shallow. In the meantime, a lot of us make very good money and are not forever stuck on problems that have 20-year old StackOverflow threads. It feels really good.

Failed, or fizzled, means that when somebody working on a project leaves, you can't can't count on finding anybody to hire in to replace them. Allowing anything essential to be coded in the language, then, is an existential risk for a small company or division.

It means nobody wants you working on anything essential unless they have already bet the company on that thing.

I am well aware of that adage as well. But there's mounting [anecdotal from many directions] evidence that people get very easily onboarded in Elixir (sadly doesn't apply to Rust or Haskell or OCaml though).

So when trying to analyze this situation today, at the brink of 2022, it pays off to also add factors that haven't been there before e.g. newer tech that people can easily pick.

I am not trying to convince you to pick a new language btw, but I find your opinions to be just parroting some common wisdom that's fairly outdated at this point. Even if its basic premise still stands the devil is always in the details, and those details favour some of the more fringe tech a little bit more compared to some mere 5 years ago.

Mastering a tool that nobody else has, and that is radically better than what others are using, can be akin to a superpower. But Spider-Man and Doc Ock are not happier than other people. What they are, mostly, is alone.

So, a niche tool may be best for you if you like to work alone.

Clojure is a very good success story of a functional LISP running on the JVM.
Show me the apps.
I have no inside knowledge, but I expect there are a great many significant and very successful Clojure apps…that are single-purpose within single companies, never discussed publicly. Clojure conference videos seem to support this notion.
Roam Research
metabase
datomic