The sunk cost fallacy at Jane Street is strong.
Wait til you hear about PHP at Meta...
OxCaml - a set of extensions to the OCaml programming language.
61–70 of 128 posts
Re: OxCaml - a set of extensions to the OCaml programming language.
#62Re: OxCaml - a set of extensions to the OCaml programming language.
#63The 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.
[deleted]
Re: OxCaml - a set of extensions to the OCaml programming language.
#64Earlier quoted context omitted.
The linked podcast episode mentions it.
There's no mention of a library called zero, or even JavaScript.
> This is what I like to call a dialect of OCaml. We speak in sometimes and sometimes we gently say it’s zero alloc OCaml. And the most notable thing about it, it tries to avoid touching the garbage collector ...
Re: OxCaml - a set of extensions to the OCaml programming language.
#65The 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...
Anonymous labeled structs and enums are some of my top wished-for features in programming languages! For instance, in Rust you can define labelled and unlabelled (i.e. tuple) structs struct Foo(i32, i32); struct Bar{sum: i32, product: i32} But you can only e.g. return from functions an anonymous tuple, not an anonymous labelled struct fn can() -> (i32, i32) fn cant() -> {sum: i32, product: i32}
It's interesting that languages which start with purely nominal structs tend to acquire some form of structurally typed records in the long run. E.g. C# has always had (nominally typed) structs, then .NET added (structurally typed) tuples, and then eventually the language added (still structurally typed) tuples with named items on top of that.
Re: OxCaml - a set of extensions to the OCaml programming language.
#66Re: OxCaml - a set of extensions to the OCaml programming language.
#67The 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…
*Jane Street
Re: OxCaml - a set of extensions to the OCaml programming language.
#68The 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...
Anonymous labeled structs and enums are some of my top wished-for features in programming languages! For instance, in Rust you can define labelled and unlabelled (i.e. tuple) structs struct Foo(i32, i32); struct Bar{sum: i32, product: i32} But you can only e.g. return from functions an anonymous tuple, not an anonymous labelled struct fn can() -> (i32, i32) fn cant() -> {sum: i32, product: i32}
PHP has it all!
I think the main dividing line here is whether you want to lean into strict typing or whether you prefer a more loose typing structure. The extremes of both (where, for instance, the length of an array is part of its type definition or there are not contractual guarantees about data) are both awful. I think the level of type strictness you desire as a product is probably best dictated by team and project size (which you'll note changes over the lifetime of the product) with a lack of typing making it much easier to prototype early code while extremely strict typing can serve as a strong code contract in a large codebase where no one person can still comprehend the entirety of it.
It's a constant push and pull of conflicting motivations.
Re: OxCaml - a set of extensions to the OCaml programming language.
#69Re: OxCaml - a set of extensions to the OCaml programming language.
#70Earlier quoted context omitted.
In Dart, we merged tuples and records into a single construct. A record can have positional fields, named fields, or both. A record type can appear anywhere a type annotation is allowed. So in Dart these are both fine: (int, int) can() => (1, 2); ({int sum, int product}) alsoCan() => (sum: 1, product: 2); (int, {int remainder}) evenThis() => (1, remainder: 2); The curly braces in the record type annotation distinguis…
How do you distinguish a tuple with both positional and named fields from a tuple that has a record as a field Like how do you write the type of (1, {sum:2}) ? Is it different from (1 , sum :2)?
The syntax is a little funny for mostly historical reasons. The curly braces are only part of the record type syntax. There's no ambiguity there because curly braces aren't used for anything else in type annotations (well, except for named parameters inside a function type's parameter list, but that's a different part of the grammar).