Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The road to OCaml 5.0

discuss.ocaml.org

Post reply on HN
Print view View original

71–80 of 118 posts

Re: The road to OCaml 5.0

#71

Post by short_sells_poo »

hajile wrote: post #15
short_sells_poo wrote: post #2

I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…

If your language doesn't worry about lifetimes, they don't go away. It just means you have to worry about them yourself instead. Sometimes that is great. Other times, that will be very hard and error-prone.

When you are trying to solve a complex optimal payoff problem, you really don't want to get bogged down with lifetimes. That's a completely orthogonal concern to what you are trying to establish. You are not writing production code, you are doing research. It's the core reason why languages with easy REPL and immediate feedback (like matlab, R, python, julia, etc...) are used for research, because you get immediate and interactive feedback. The keyword is interactive.

Once you have to think of types and lifetimes, a lot of the productivity goes down the drain.

99% of the stuff you do in research ends up being consigned to the cutting floor because it doesn't work. The 1% that ends up being useful is the only part worth productionizing.

Re: The road to OCaml 5.0

#72

Post by dropofwill »

Zababa wrote: post #64
thingification wrote: post #61

Earlier quoted context omitted.

> Frontend there is that ReasonML/Reason/ReScript thing that Facebook it trying to do. It offers an alternative syntax but nearly nobody uses it because they changed the name and I think also the syntax three times already. So it is all a mess. "Nobody" uses ReasonML / Reason. Plenty of people use ReScript. I wasn't a big fan of the ReScript split, but I think by now it's unfair to speak of these as if they're one co…

> The compiler for that language just happens to still understand OCaml syntax, for now. I think another important point is that the compiler is a fork of the OCaml compiler. That means that to contribute/maintain the compiler, you need to know OCaml. This is probably going to stay this way for a very long time, since the speed of the compiler is important. > Really that's the main story -- not so hard to grasp? What…

That's the main story for targeting JS, but reason native is not dead (unless something has changed recently, I haven't been actively working with it for a while).

Re: The road to OCaml 5.0

#73

Post by thingification »

bigjimslade wrote: post #52

I really wanted to like OCaml, still do. I gave it a good shot a couple of years ago, wrote a few basic programs and loved it. But it to me seemed packaged like many languages in the days of yore, when a language shipped simply as a compiler, and nothing more. The way of the world today to me seems to be a compiler, together with a complete standard library and consistent packaging system. My experience with OCaml wa…

Not sure when you tried it, but as a newcomer I have the impression packaging has got a lot better in the past few years.

I didn't have the experience you described (not yet anyway!).

Re: The road to OCaml 5.0

#74

Post by pjmlp »

AzzieElbab wrote: post #54
bobbylarrybobby wrote: post #53

Earlier quoted context omitted.

Out of curiosity, what problems does Haskell's compiler(s) (I think it's really just GHC these days?) face that OCaml's doesn't?

speed. Ocaml compiler is probably as fast as Go one

GHC has many backends and there is GHCi as well.

No need to always go through the slowest path.

Re: The road to OCaml 5.0

#75

Post by sidkshatriya »

ithrow wrote: post #55
cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

multicore ocaml won't change adoption of the language in any significant way

In some strange way, that is what I like about the language. OCaml is not about amassing the largest possible user base but making a great programming language. Of course, these two objectives are not contradictory but the point here is that OCaml aspires to be a language on which you can write ground breaking and innovative software, not necessarily _popular_ software.

OCaml has an academic flavor -- maybe it's not as academic as Haskell but it moves in similar ways. There is a desire to be correct and have a theoretical framework instead of amassing a ton of language features. OCaml is the foundation for Coq and other interesting compilers, type checkers and theorem provers. Over the years, the language has grown more mainstream and you can build a decent web backend on it today, for instance.

So fine, maybe multicore won't change adoption of the language in significant ways. But I foresee that the introduction of multicore will allow some amazing software to be written in OCaml in the future. Software that is truly groundbreaking and innovative. Take the example of Coq itself -- it is an important foundational software today in Computer Science. Multicore will allow Coq to potentially speed itself up and that will bring more real world applications in the ambit of Coq.

Re: The road to OCaml 5.0

#76

Post by hajile »

typon wrote: post #20
hajile wrote: post #15

Earlier quoted context omitted.

If your language doesn't worry about lifetimes, they don't go away. It just means you have to worry about them yourself instead. Sometimes that is great. Other times, that will be very hard and error-prone.

An extremely simple thing like having two objects stored in a struct where one object has a reference to the other is a Herculean task in Rust. This is not a language designed for prototyping...

This is perhaps where I get hate from both sides, but I think such cases are best done in unsafe code blocks.

A tool that makes something much harder without any meaningful gain should be avoided. Rust provides the tools to not have to fight the system and they should be used in these situations.

Re: The road to OCaml 5.0

#77

Post by Zababa »

thingification wrote: post #70
Zababa wrote: post #64

Earlier quoted context omitted.

> The compiler for that language just happens to still understand OCaml syntax, for now. I think another important point is that the compiler is a fork of the OCaml compiler. That means that to contribute/maintain the compiler, you need to know OCaml. This is probably going to stay this way for a very long time, since the speed of the compiler is important. > Really that's the main story -- not so hard to grasp? What…

> I think another important point is that the compiler is a fork of the OCaml compiler. That means that to contribute/maintain the compiler, you need to know OCaml. This is probably going to stay this way for a very long time, since the speed of the compiler is important. Important to the maintainers, absolutely -- but not directly important to users of course: it's firmly the goal that you don't need to know any OCa…

> Important to the maintainers, absolutely -- but not directly important to users of course: it's firmly the goal that you don't need to know any OCaml to use ReScript (and I think it's mostly true by now).

That's true, and according to the maintainers, with the recent improvements it should be easy to maintain. And using tools written in other languages is not a first for JavaScript users (ESBuild comes to mind).

Re: The road to OCaml 5.0

#78

Post by Zababa »

CactusOnFire wrote: post #43
cardanome wrote: post #29

I really hope to see more interest in OCaml in the future. It is probably one of the most underrated programming languages. The perfect marriage between state of the art functional programming and pragmatism. A great static and strong type system. Solid performance and an insanely fast compiler. Also compiles to JS if you need that. Multicore support will make it quite perfect. Only thing that is holding it back more…

I find it really interesting how I had never heard of OCaml before frequenting HN, but how incredibly passionate so many people here are about the language. It honestly seems like a great lang, and I hope I get to try it out for a project sometime soon.

"I find it really interesting how I had never heard of before frequenting HN, but how incredibly passionate so many people here are about " is one of the thing I love about this place. There are always people ready to share their knowledge and passion about something I didn't know before.

Re: The road to OCaml 5.0

#79

Post by short_sells_poo »

jstimpfle wrote: post #4
short_sells_poo wrote: post #2

I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…

> last thing one wants is a language that requires a lot of thought about lifetimes etc. I challenge you: A lack of understanding about the data lifetimes in a program means lack of understanding about the data. Not saying you can't have a lot of short-lived data items that you don't want to manage one-by-one. I'm saying that for the vast majority of data items, one should be able to give a reasonably well defined li…

Thanks, but I think we may be talking cross purpose here. 99% of the research code ends up being thrown away (well, archived). Not because it's bad code necessarily, but because the idea that was being prototyped is a dead end. This means it's paramount that the language you use has to be as low friction and interactive as possible.

Imagine you are trying to establish whether there's a relationship between timeseries X and timeseries Y. You just want a tool that allows you to quickly calculate some summary statistics of these timeseries, clean them, convince yourself that they behave according to your expectations and then run some form of regression.

Nowhere in this process do you care about lifetimes. It's literally irrelevant. In fact, as long as all your work fits into memory, you don't even care about memory management. Your objective is to answer the primary question, everything else is a costly distraction.

The 1% of ideas that ends up being worthwhile is what gets productionized and needs to be robust. But obviously rewriting everything from language A to radically different language B adds it's own headaches.

Re: The road to OCaml 5.0

#80

Post by short_sells_poo »

nerdponx wrote: post #17
short_sells_poo wrote: post #2

I run a hedge fund. On any given day I hear a large number of complaints from the technologists that complex python systems are difficult to look after and we should use something else instead. There's some Rust being used, but there's little chance to get a quant to use Rust to do research because research is an exploratory process and the last thing one wants is a language that requires a lot of thought about lifet…

Have you looked into Julia, Nim, Clojure, or even Common Lisp? I'm not sure bout Python interop with CL, but Nim and Clojure seems to have some kind of beta-grade interop, and there's a solid interop story in Julia. And all of those languages have some of their own "native" data analysis and scientific computing toolkits (Julia having more than "some", of course). That said, complicated Python systems can be improved…

Thank you, we've dabbled with Julia and indeed it works very well. We are just a bit worried about betting the barn on it so to speak. It's still very niche and we are just not seeing the kind of meteoric rise that Rust is exhibiting for example. we would ideally not want to become the sole caretaker of some niche language. Jane Street can afford it with Ocaml, but we can't :(

For that reason, Julia is being closely watched, but so far we are not thinking of pulling the trigger.

Post reply on HN