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

Why I love OCaml (2023)

mccd.space

Post reply on HN
Print view View original

301–310 of 313 posts

Re: Why I love OCaml (2023)

#301

Post by kragen »

mbac32768 wrote: post #300
kragen wrote: post #220

Earlier quoted context omitted.

Caml was developed in 01985, Linux was first released in 01991, and Caml was extended into OCaml in 01996. I don't think the developers were using Linux at the time; SunOS 4 would be my best guess. I didn't work on it, but I was in the sort of internetty environment that OCaml came from, and I was using Solaris at work and got my first Linux box at home. As another commenter mentioned, the command line follows Unix c…

Forgive me for implying the Linux lifestyle and UNIX lifestyle were anything close to the same thing. I will turn in my Plan 9 install media and my copy of The Design and Implementation of the 4.3BSD Operating System at the nearest DEC service center.

It's just sort of anachronistic. Caml was no more designed by people deep in Linux life than James Clerk Maxwell was into aviation or Christopher Columbus liked to visit the Massachusetts Bay Colony. They probably would have been, but the timelines didn't allow it.

Re: Why I love OCaml (2023)

#302

Post by mbac32768 »

kragen wrote: post #301
mbac32768 wrote: post #300

Earlier quoted context omitted.

Forgive me for implying the Linux lifestyle and UNIX lifestyle were anything close to the same thing. I will turn in my Plan 9 install media and my copy of The Design and Implementation of the 4.3BSD Operating System at the nearest DEC service center.

It's just sort of anachronistic. Caml was no more designed by people deep in Linux life than James Clerk Maxwell was into aviation or Christopher Columbus liked to visit the Massachusetts Bay Colony. They probably would have been, but the timelines didn't allow it.

Sure. The larger point was about Windows. You would or would not agree that people doing PL research on SunOS workstations (or whatever UNIX) would also not give a shit about Windows?

Re: Why I love OCaml (2023)

#303

Post by yujzgzc »

debugnik wrote: post #295
yujzgzc wrote: post #273

Earlier quoted context omitted.

Ocaml has exactly the same kinds of escape hatches, like Obj.magic or unsafe accessors. The way I see it. it's a matter of community practice more than language capabilities. Typescript in practice has has the safety net of being interpreted rather than compiled, so I guess people tend to abuse its type flexibility more. But if you write without the escape hatches in both languages, in my experience the safety is exa…

First off, the escape hatches in TypeScript are way too accessible compared to OCaml: `JSON.parse(...) as MyInterface` is everywhere and completely broken. And second, you're dismissing the fact that TypeScript is unsound, even worse it is so by design. Easy examples: uninitialized variables holding undefined when their type says they can't [1]; array covariance [2]; and function parameter bivariance, which is part o…

Thanks, these are good examples of holes in typescript that I wasn't aware of. I guess I haven't pushed it enough yet to run into them. I agree Ocaml wouldn't fail.

> I can't see what are you speficially missing here that pattern matching and maybe an additional variant type doesn't get you in OCaml. You get exhaustiveness checking and can narrow the value down to the payload of the variant.

A couple things, being constrained to pattern matching in places where imperative programming would be more natural, having to declare lots of special purpose types explicitly vs being able to rely on ad hoc duck typing.

Re: Why I love OCaml (2023)

#304

Post by dontlaugh »

thw_9a83c wrote: post #283
Syzygies wrote: post #209

Earlier quoted context omitted.

To decide on a language for a math research project, I implemented a toy problem in many languages: What is the distribution of cycle counts for signed permutations on n letters? Use all cores in parallel. C++ 100 19.57s Rust 96 20.40s F# 95 20.52s Nim 75 26.04s Julia 64 30.40s Ocaml 48 41.07s Haskell 41 47.64s Chez 39 49.53s Swift 33 58.46s Lean 7 278.88s Tarjan, n = 10 Nyx - Apple M4 Max - 12 performance and 4 effi…

F# is a nice language, but it depends on .NET, so a direct comparison to OCaml is not possible. The .NET runtime dependency often makes things unnecessarily complex and fragile. There must be a reason why Golang (no VM runtime) is successful despite entering the market very late after Java and C# had already established clear dominance.

Easier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there.

Go was made by Google flawed, but with clarity of purpose and consistently usable libraries.

.NET spent years forked into framework and core and unclear open source future.

Java struggled to scale down and Oracle caused similar distrust as Microsoft.

Re: Why I love OCaml (2023)

#305

Post by thw_9a83c »

dontlaugh wrote: post #304
thw_9a83c wrote: post #283

Earlier quoted context omitted.

F# is a nice language, but it depends on .NET, so a direct comparison to OCaml is not possible. The .NET runtime dependency often makes things unnecessarily complex and fragile. There must be a reason why Golang (no VM runtime) is successful despite entering the market very late after Java and C# had already established clear dominance.

Easier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there. Go was made by Google flawed, but with clarity of purpose and consistently usable libraries. .NET spent years forked into framework and core and unclear open source future. Java struggled to scale down and Oracle caused similar distrust as Microsoft.

While I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such problems are non-existent if you don't have a separate VM runtime dependency.

Re: Why I love OCaml (2023)

#306

Post by dontlaugh »

thw_9a83c wrote: post #305
dontlaugh wrote: post #304

Earlier quoted context omitted.

Easier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there. Go was made by Google flawed, but with clarity of purpose and consistently usable libraries. .NET spent years forked into framework and core and unclear open source future. Java struggled to scale down and Oracle caused similar distrust as Microsoft.

While I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such pr…

I don’t think that has anything to do with VMs, the same happens with C++ runtime libraries.

The difference is Go really focused on continuity and compatibility, while .NET didn’t.

Re: Why I love OCaml (2023)

#307

Post by thw_9a83c »

dontlaugh wrote: post #306
thw_9a83c wrote: post #305

Earlier quoted context omitted.

While I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such pr…

I don’t think that has anything to do with VMs, the same happens with C++ runtime libraries. The difference is Go really focused on continuity and compatibility, while .NET didn’t.

> ...the same happens with C++ runtime libraries

I don't think so. Upgrading to a newer major version of the C++ runtime essentially involves recompiling, unless you're dealing with an application that's 15 years or older. You can even instruct the compiler to use an older C++ standard if your code won't compile with the newer one. There is also an option to compile the runtime statically, though it is obviously not recommended.

.NET is a different story [1]

[1]: https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

Re: Why I love OCaml (2023)

#308

Post by bfors »

bsder wrote: post #179
7thaccount wrote: post #144

Earlier quoted context omitted.

Do those devs actively use OCaml? I thought most of the folks writing OCaml were writing the actual trade algorithms as opposed to infrastructure folks. My post was made off what I recall their lead technologist saying.

Yes, everybody in JaneStreet is expected to be able to use Ocaml, Neovim, and R/Julia/etc. Everybody in the company is expected to be able to sling numbers in text on a computer super efficiently.

They also build custom emacs tooling

Re: Why I love OCaml (2023)

#309

Post by kragen »

mbac32768 wrote: post #302
kragen wrote: post #301

Earlier quoted context omitted.

It's just sort of anachronistic. Caml was no more designed by people deep in Linux life than James Clerk Maxwell was into aviation or Christopher Columbus liked to visit the Massachusetts Bay Colony. They probably would have been, but the timelines didn't allow it.

Sure. The larger point was about Windows. You would or would not agree that people doing PL research on SunOS workstations (or whatever UNIX) would also not give a shit about Windows?

Windows didn't exist in 01985. I mean, Microsoft did release a product by that name at the end of the year, but it wasn't an operating system.

I remember that in 01998 or 01999 I asked Andrew Tanenbaum, a different European CS professor, what he thought about Linux. His impression was still that it was some kind of hobbyist project for people who (paraphrasing here and reading between the lines) couldn't afford a real computer. So I suspect that, even when Caml became OCaml, its developers saw Linux as belonging to the same crowd as Microsoft Windows, rather than to the systems they were used to.

But even that Windows/Unix OS dichotomy didn't exist when the programming language was designed. They might have been thinking about Unix vs. VMS, or Unix vs. GCOS, or Unix vs. Oberon, or BSD vs. System V, but definitely not Linux vs. Windows.

Re: Why I love OCaml (2023)

#310

Post by globnomulous »

thw_9a83c wrote: post #305
dontlaugh wrote: post #304

Earlier quoted context omitted.

Easier deployment helped, but nowadays it’s common to put a single Go executable in a container anyway. .net core doesn’t have much if any disadvantage there. Go was made by Google flawed, but with clarity of purpose and consistently usable libraries. .NET spent years forked into framework and core and unclear open source future. Java struggled to scale down and Oracle caused similar distrust as Microsoft.

While I agree with most points, .NET or JRE introduce additional complexity that may not be welcome in every setting. I've worked for several companies where upgrading to a newer version of .NET was always a major pain point, especially for applications that weren't very actively developed. There is limited security support for each major .NET version, so at some point, you and your customers need to upgrade. Such pr…

> I've worked for several companies where upgrading to a newer version of .NET was always a major pain point,

This was so difficult for the teams I work with that the person who became the team specialist in MSBuild, dotnet, and C# basically punched his ticket and received a couple of promotions. The work is so miserable and challenging that basically no one else Will take it.

I've struggled to understand why .net upgrades are so painful and laborious despite the maturity of the languages and ecosystems. I had assumed that, as with Powershell, C# and .net behind the scenes are undergoing enormous changes as Microsoft attempts to improve or add support for historically neglected platforms and hardware, and so I had assumed also that these were temporary problems, just badly managed growing pains on a path to major improvement, but I gather from your comment that the problem has a long history and is systemic. Awful.

MSBuild has been a huge source of the suffering I've experienced while working on these projects. The documentation is, in my experience, a nightmare: exhaustingly verbose, full of jargon, and uncanny in its ability to talk around an issue, concept, or functionality without clarifying anything conceptually or practically. I find this throughout Microsoft docs.

Post reply on HN