Hasura migrating to Rust?

Links
#61

I’m not exactly sure what chrisdone means by the FFI, but:

Haskell has a family of libraries prefixed with inline, which uses quasi-quotes to allow you to embed slightly modified code from other languages into Haskell, alongside having FFI support. This ends up providing an extremely ergonomic form of FFI.

Inline-c is the most mature inline / FFI library.

There’s also Tweag’s inline-js, which seems abandoned, as well as Juspay’s inline-js fork.

Ideally, this would solve Haskell’s ecosystem problem at a stroke; F# has access to the .NET ecosystem, Clojure and Scala have access to the JVM ecosystem, but in theory, Haskell can have ergonomic access to the .NET, JVM, npm, cargo, AND Python ecosystems, which would be an extremely strong selling point for Haskell in production use.

And some of the most successful Haskell projects, in reality, are just wrappers around C++ (SC’s Mu dialect system and Meta’s Sigma), but C++ FFI is generally challenging. A world of Haskell wrapping Rust (also challenging to FFI) is actually a pretty cool world in my book.

1 Like
#62

FFI doesn’t really solve the ecosystem issue. It’s just one way with its own downsides.

I use (and have written bindings for…I prefer hsc2hs) many C gamedev libraries. Same idea - C gamedev is mature; let’s borrow it!

It kinda works but also kinda doesn’t. Some libraries port better than others to Haskell.

The secret sauce is writing a Haskell layer on top. Verbatim bindings to other languages are a good starting point, but if you don’t write idiomatic Haskell on top, you don’t really get much benefit.

7 Likes
#63

It was okay (compared to python, js, and other mainstream stuff) when I started in 2011 and since then got better by leaps and bounds. It is still vastly better than the flaming clownshow that is packaging in a typical language, mainstream or not.

I was tracking a large-ish codebase for many years, dragging it from GHC 7.8 into 9.2 (bless all the Stackage maintainers :pray:). It was a minor mechanical task - follow GHC messages to chill and unwind after meetings. Occasionally I had to consult changelogs… Maybe if I had to do it with 25 projects in parallel, it would be a different story. But maybe not, since I kinda did that with my own side-projects.

Yeah, many languages beat Haskell in one aspect or another. But I can’t see any that beats it comprehensively across the board. There’s no Condorcet, only Blubs.

6 Likes
#64

"Haskell wrapping Rust:
https://well-typed.com/blog/2023/03/purgatory/

2 Likes
#65

@chrisdone

How much do you think a better interpreted mode for Haskell would work? GHCI isn’t the best, and it doesn’t optimize well, but if you want to compete with Go in terms of build speed, the best way to get around Haskell’s poor compile times is to have a strong interpreted mode; i.e, load the project into GHCI, then go hack in interpreted mode to get around the crappy compile times.

#66

I use GHCi in -fobject-mode and it’s pretty fast. In interpreted mode it will take several minutes to fire up GHCi, in objec mode it’s only a few seconds.

#68

20mn to compile the full project, but that’s once in while.

#69

The novelty budget is better translated as ROI. Haskell may be a nice dainty language for people to play around with, but it has not shown a proven ability to deliver business promises at a higher ROI. Using Haskell means you get longer onboarding times, more time spent on R&D, more time spent vetting libraries, more time spent refactoring, more risks with ecosystem and tooling churn, but does all of that really lead to faster delivered features and lowered development costs ala the lisp/python/ruby/go effect?

Unfortunately for companies betting on haskell, its not apparent that this is happening, and the cost spent to even breakeven is already prohibitive for most smaller companies unless they stick to a tight discipline of using Simple Haskell or some variant.

2 Likes
#70

does all of that really lead to faster delivered features and lowered development costs…?

In my employer’s experience, definitely. We do cultivate a Haskell dialect, but not down to strict Haskell98 or Simple Haskell or any other specific initiative. We allow things like lens-within-reason and use generic-lens with -XOverloadedLabels to make records much nicer, but we often avoid heavily GADT-based or typelevel solutions if they seem too complicated.

The reliability of software we write in Haskell has been much better for us compared to equivalent code written in Ruby, and even basic features like completeness checking of patterns or liberal use of newtype help a lot. Many services don’t need maintenance beyond a quick recompile to get the latest dependencies, and then they just keep on working. On the library vetting front, we found that Ruby or JS libraries actually need more thorough vetting than the Haskell equivalent. A Ruby library that hasn’t been touched for six months could be dangerously outdated, while a Haskell library that has been untouched for three years could well be complete.

As for ecosystem and tooling churn? Hasn’t been a problem for us. Besides, the JS ecosystem is famous for its rate of library releases, and I’d worry more about Python inventing new build tools.

Yes, sometimes we have to write our own web service bindings, but that’s generally been fast enough when we had to do it (thank you, servant-client), and in other languages we’d sometimes find ourselves doing that anyway because we couldn’t trust the existing libraries.

9 Likes
#71

I concur with @jackdk ; in my experience (I wrote about it here), we were able to calculate the cost of dynamical typing / non-null-safety and found it to be very expensive. Using Haskell (as we’ve started doing) will objectively pay for itself. This may not be applicable to all industries, though.

4 Likes
#72

Being the advocate of the devil, cost is much more than just developper cost and bug cost/lost.
You’ve got hiring costs, wages cost. What happend if in n years the main Haskell devs leaves or threaten to do it unless they get a significant pay rise ? How fast can you replace a team, what happen in the mean time. How does that scale (develope wise) etc …
There are long term costs which you can’t predict until you actually survived a few years. I’ve heard that 90% close within 5 years.
If you are a small company and manage to survive, chances are that you’ll get bought buy a bigger one and they rewrite everything in another language …

What I mean is yes in theory Haskell should pay off, but the proof is in the pudding and if Haskell was a silver bullet every big company (which are aware of Haskell) would be using Haskell more than they do.

Don’t get me wrong, I’m the boss of a company and we use Haskell and it pays off, but that doesn’t mean it can be generalized.

4 Likes
#73

Re: hiring, fungibility; I think this is probably because this has not been a focus of the Production Haskell community.

In general, Haskell is seen as hard to learn, and a way to get a hold of highly experienced and talented Haskellers, then maybe make them write Rust ;).

However, what would happen if we tried to focus on quickly training Haskellers?

Serokell’s certification program actually presents a fairly good opportunity; i.e, if people were to experiment with speedrun-training on Serokell’s Proficient level, what’s the shortest we can get the time without completely throwing “Avoid Success At All Costs” out the window? 2 weeks seems to be the minimum thus far, possibly involving talented programmers and reduced idioms, but what happens if we can get it down to 1-2 weeks?

That makes Haskell developer fungibility much better; you will still need senior Haskell developers who know what they are doing, but if the request is to give them cats to herd, you can just hire an “ordinary intelligent developer” and push them through your training program.

1 Like
#74

I don’t think speed is what matters here. And the reason Haskellers are popular in industry (even for non-Haskell positions) is because they’re deemed self-driven, excited and knowledgeable engineers.

We need better education material. But I don’t think we should optimize it for “learn Haskell in 2 weeks”.

6 Likes
#75

Speed does matter because, one, firms that adopt Haskell do not want to take 6 months to retrain their staff or hire a new development team.

Moreover, the current Haskell brand image and recruiting base is great, but as with the Rust vs Haskell thread, we need to locate demand for new or otherwise overlooked use cases. The old use cases saw limited success and got a bit stale.

I agree, however, that a book titled “Learn Haskell in 2 Weeks” would be harmful, as creating a competent Haskeller from that would be impossible, and bad Haskell code is bad for the brand. There are already similar books, aimed at people who are trying to pass a Haskell class, like Haskell From The Very Beginning.

What is needed isn’t a book targeted at learners, but rather teachers: “Teach Haskell in 1-4 Weeks” is a lot more useful since firms want rapid onboarding, and lacuna and misunderstandings can be handled through pair programming and code review over time greater than the 1-4 weeks promised.

3 Likes
#76

Haskell brand image … is great

Unfortunately outside of Haskell blogs I’m seeing the opposite.

When I’ve asked tech leaders – people who choose platforms – about Haskell’s reputation, its branding is bad: Bloated, academic, impossibly complex, not worth the pain.

So there does appear to be a branding issue, at least among some tech leaders.

Related topic arose around the Haskell survey, it needs to look beyond the immediate fan community.

9 Likes
#77

I’m not sure that feedback carries a lot of value.

There’s really not much Haskell can offer to people who just need an ok general purpose programming language. It would indeed be an odd choice.

And I’m being fairly diplomatic here with my wording.

4 Likes
#78

It’s important to not lose “avoid (success at all costs)” in these discussions.

There are a lot of reason tEcH lEaDeRs don’t like Haskell that are core values to the language. I hope we never compromise them and create some bleh language. Tech leaders aren’t gods they’re just people who honestly make dumb decisions all the time lol. I guess years in the industry inevitably erodes the respect :joy:

5 Likes
#79

I think my industry experience matches yours.

6 Likes
#80

I like to be cynical too, but for a community has gotten this large this attitude can really prompt the existential question. Or are we all okay with being industrial renegades?

I wish this thread dies out but I am contradicting and adding fuels…

Could someone just close it with a hopeful tone?

2 Likes
#81

Question: If Hasura was instead switching to the likes of e.g. Agda, Idris or Epigram…would this thread even exist?