Live data from Hacker News

OxCaml - a set of extensions to the OCaml programming language.

oxcaml.org

31–40 of 128 posts

Re: OxCaml - a set of extensions to the OCaml programming language.

#31
post #21

Earlier quoted context omitted.

Hmm. Let me first check that I've understood what you care about struct First(this: i8, that: i64) struct Second(this: i8, that: i8) struct Third(that: i64, this: i8) struct Fourth(this: i8, that: i64) struct Fifth(some: i8, other: i64) You want First and Fourth as the same type, but Second and Third are different - how about Fifth? I see that this is different from Rust's existing product types, in which First and F…

they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. a lot of times with tuple return types you're left wondering what that random `usize` is supposed to represent, so having names for it would be very convenient. i don't see why, under the hood, it couldn't just be implemented the exact same way as current tuple return types

> they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around.

And their point is that the two boil down to the same thing, especially in a non-trivial program. If switching field positions around changes their semantics, tuples may well the most sensible choice. As for "what that random usize is supposed to represent" that's something that can be addressed with in-code documentation, which Rust has great support for.

Re: OxCaml - a set of extensions to the OCaml programming language.

#32
post #7

The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…

You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close).

Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.

Re: OxCaml - a set of extensions to the OCaml programming language.

#33
post #7

The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…

You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close). Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.

Is that really a viable solution for a timeframe of 6+ hours?

Re: OxCaml - a set of extensions to the OCaml programming language.

#34

The first feature that originated in this fork to be upstreamed is labeled tuples, which will be in OCaml 5.4: https://github.com/ocaml/ocaml/pull/13498 https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-4...

> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returning the pair in the wrong order, or mixing up the order of the initial values.

Hmm, I think I like F#'s anonymous records better than this. For example, {| product = 6; sum = 5 |}. The order of the fields doesn't matter, since the value is not a tuple.

Re: OxCaml - a set of extensions to the OCaml programming language.

#35
post #7

The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic. [0] https://signalsandthreads.com…

GC compactions were indeed a problem for a number of systems. The trading systems in general had a policy of not allocating after startup. JS has a library, called "Zero" that provides a host of non-allocating ways of doing things.

Couldn’t find this after 6 seconds of googling, link?

Re: OxCaml - a set of extensions to the OCaml programming language.

#37

Earlier quoted context omitted.

You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close). Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.

Is that really a viable solution for a timeframe of 6+ hours?

You can just add more RAM until it is viable.

Re: OxCaml - a set of extensions to the OCaml programming language.

#38

Earlier quoted context omitted.

You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close). Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.

Is that really a viable solution for a timeframe of 6+ hours?

Sure, if you know how much you allocate per minute (and don’t exceed your budget) you just buy enough RAM and it’s fine.

Re: OxCaml - a set of extensions to the OCaml programming language.

#39
post #35

Earlier quoted context omitted.

GC compactions were indeed a problem for a number of systems. The trading systems in general had a policy of not allocating after startup. JS has a library, called "Zero" that provides a host of non-allocating ways of doing things.

Couldn’t find this after 6 seconds of googling, link?

The linked podcast episode mentions it.

Re: OxCaml - a set of extensions to the OCaml programming language.

#40
post #21

Earlier quoted context omitted.

they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. a lot of times with tuple return types you're left wondering what that random `usize` is supposed to represent, so having names for it would be very convenient. i don't see why, under the hood, it couldn't just be implemented the exact same way as current tuple return types

> they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. And their point is that the two boil down to the same thing, especially in a non-trivial program. If switching field positions around changes their semantics, tuples may well the most sensible choice. As for "what that random usize is supposed to represent" that's something that can…

Also, if it's not just a "random usize" then you should use the new type paradigm. In a language like Rust that's not quite as smooth as it could possibly be, but it's transparent to the machine code. Rust's Option is the same machine code as C's int file descriptor, but the same ergonomics as a fancy Haskell type. We can't accidentally confuse "None, there isn't a file descriptor" for an actual file descriptor as we so easily could in C, nor can we mistakenly do arithmetic with file descriptors - which is nonsense but would work (hilarity ensues) in C.

If these aren't "random" usizes but FileSizes or ColumnNumbers or SocketTimeouts then say so and the confusion is eliminated.

Post reply on HN