Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

51–60 of 219 posts

Re: A better build system for OCaml

#51
post #30

Earlier quoted context omitted.

This means the architecture is also bad, and that is what needs to be fixed.

so simple huh? since you fancy yourself an architect can you let me know how we might fix the architecture of https://github.com/llvm/llvm-project such that CMake is no longer needed?

Not in a glib response, no.

Re: A better build system for OCaml

#52
post #4

I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love. I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.

There's also pandoc written in Haskell. Facebook used it for it's spam-protection too, at some point (it might still do that, but I don't know).

Re: A better build system for OCaml

#54
post #13

The only thing worse than a complex codebase is a complex build system. I think CMake is an abomination. “Hey go learn this new language to compile this other language!”

The only thing worse than a complex build system is a simple build system that can't build what you need to build. :(

>> Complexity has to live somewhere. If you are lucky, it lives in well-defined places. In code where you decided a bit of complexity should go, in documentation that supports the code, in training sessions for your engineers. You give it a place without trying to hide all of it. You create ways to manage it. You know where to go to meet it when you need it. If you're unlucky and you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn't stop existing.

>> With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around and leave, our understanding of it erodes.

>> Complexity has to live somewhere. If you embrace it, give it the place it deserves, design your system and organisation knowing it exists, and focus on adapting, it might just become a strength.

- Fred Hebert, https://ferd.ca/complexity-has-to-live-somewhere.html

Re: A better build system for OCaml

#55
post #4

I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love. I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.

Certainly. There's also a good amount of F# in production. It's a fantastic option for building high quality programs with broad interop with existing systems.

Re: A better build system for OCaml

#56
post #4

I have to respect Jane Street for proving that HM-typed functional programming can be production-ready and extremely fast when given enough love. I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.

> HM-typed functional programming Mercury also uses Haskell for their backend https://mercury.com/

Standard Chartered also uses their variation of Haskell.

Re: A better build system for OCaml

#59

Earlier quoted context omitted.

> HM-typed functional programming Mercury also uses Haskell for their backend https://mercury.com/

Standard Chartered also uses their variation of Haskell.

Yeah, I actually interviewed for a Haskell position there in 2023. They didn't hire me, but it was kind of fun to do technical questions in Haskell for an interview instead of the boring JavaScript or Python that I usually use.

Re: A better build system for OCaml

#60

Earlier quoted context omitted.

> more familiar Linux build systems What's a 'familiar Linux build system'? make?

They likely mean 'generally used with other languages'. make is an example.

Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".
Post reply on HN