<discocaml>
<joohnym> Yeah, the similarities are very superficial.
<companion_cube>
are they?
<companion_cube>
rust is an acceptable topic at the ML family workshop, it seems :)
trev has joined #ocaml
<companion_cube>
(also: it has `let`, sum types, and type inference. What else do you need? :p)
oriba has quit [Ping timeout: 255 seconds]
azimut has quit [Ping timeout: 255 seconds]
<discocaml>
<RegularSpatula> Yeah I’m not sure what you mean by superficial
<discocaml>
<RegularSpatula> But even if you do think they are superficial similarities, many people do not see them as superficial, including that author and the rust reference book: https://doc.rust-lang.org/reference/influences.html
<discocaml>
<RegularSpatula> Of course I don’t have numbers, but it does seem that people go to rust looking for a “modern” ml like language, if you believe the many posts which bring it up. Which I do find interesting with ocaml sitting right here
<companion_cube>
tooling, ecosystem, momentum; that's where rust outshines OCaml
chrisz has quit [Ping timeout: 248 seconds]
chrisz has joined #ocaml
<discocaml>
<RegularSpatula> Yeah that’s true
<discocaml>
<RegularSpatula> In my silly hypothetical, we would set aside ecosystem of the two. Of course you can’t do that, but I can still hope for a bunch more people to come to ocaml who otherwise choose rust when they don’t actually need that low level stuff rust gives
<companion_cube>
there's also a lot of conveniences rust has that OCaml doesn't
<companion_cube>
stuff like builtin deriving, including Debug, macros, operator overloading
<discocaml>
<RegularSpatula> Oh yeah that’s a fair point. Deriving debug and the macros are sweet
<companion_cube>
easier syntax for most people
<discocaml>
<RegularSpatula> Operator overloading idk about as much but I guess that’s personal preference
spip has quit [Quit: Konversation terminated!]
<discocaml>
<RegularSpatula> Tho you don’t have that order of operations problem in the math libraries like you do with owl I suppose
<companion_cube>
I mean, you don't even have +. and the likes
<companion_cube>
you don't have .{} or .[] or .() or .%{}
<discocaml>
<RegularSpatula> Okay that is a good point…I hate that bit of syntax
<companion_cube>
means you have nice syntax even for user defined data structures
<companion_cube>
and bigints
<companion_cube>
an OCaml with rust's syntax (ie mostly Reason) and traits + deriving would be a killer
<companion_cube>
(and cargo…)
<discocaml>
<RegularSpatula> Ha of course that would be awesome
<companion_cube>
even with refcounting instead of a GC, it'd be awesome
<discocaml>
<RegularSpatula> We can “just” write some grants and do some phds to get it done! 🐪
<discocaml>
<RegularSpatula> how much of modular implicits work is still at the research stage btw?
<companion_cube>
idk, I'm not sure it'll ever happen
<companion_cube>
I think ML modules are great, but maybe they're not worth it if you can get traits instead, idk
<companion_cube>
given that traits give you easy overloading and stuff like Debug/Clone…
<discocaml>
<Kali> i personally prefer ocaml's syntax over rust's
<discocaml>
<Kali> if there was a rust with ocaml-like syntax, i would definitely use it
<humasect>
why not just ocaml then, though? (i prefer ocaml syntax)
<discocaml>
<Kali> that's why i use ocaml, yeah
<discocaml>
<Kali> i do not need rust's speed, ocaml is plenty fast for me
<discocaml>
<Kali> but rust does interest me
<discocaml>
<Kali> especially due to its superior windows support
<discocaml>
<Kali> not that i use windows; but it's difficult to recommend ocaml to windows users at the moment
<humasect>
ocaml has better web support, if state is still the same
<humasect>
on windows i would use WSL
<humasect>
(and emacs, tuareg, merlin etc)
humasect has quit [Quit: Leaving...]
<discocaml>
<Kali> that is true
<companion_cube>
better web support? uhm
<discocaml>
<Kali> that is true (as for using WSL)
<discocaml>
<RegularSpatula> humasect: do you mean wrt backend frameworks like actix or rocket?
<companion_cube>
I mean, async in rust is still messy, but in general, it has web frameworks
<discocaml>
<masterbuilder> Why I don't think Rust is really an ML off the top of my head:
<discocaml>
<masterbuilder> - No built-in lists with nice syntax, any kind of classical FP list recursion algorithm is going to be quite a lot more verbose to do in Rust
<discocaml>
<masterbuilder> - No partial application
<discocaml>
<masterbuilder> - Nested functions are not closures
<discocaml>
<masterbuilder> - The use of closures can be awkward in general due to the borrow checker
<discocaml>
<masterbuilder> - No garbage collector which makes some programming patterns that ML languages are well suited for awkward in Rust
<discocaml>
<masterbuilder> - The Rust module system is completely different, though, like somebody mentioned it has traits instead so simplifying the module system is reasonable
<discocaml>
<masterbuilder>
<discocaml>
<masterbuilder> Rust has the shape of an ML for sure but something about it seems distinctly un-ML in some ways,it's really just like ML-flavored C++, in fact that's pretty much the basic pitch for Rust, memory-safe C++ with nice syntax
<discocaml>
<masterbuilder> that being said Rust is a very cool language and in many ways a joy to program in, I like it
<discocaml>
<masterbuilder> Can also be very annoying
<discocaml>
<RegularSpatula> "I like it, but can be very annoying" <- yeah that's a good way to put it
<discocaml>
<RegularSpatula> fwiw, I don't think that author was claiming that rust is an ML, more that it is ML-inspired
<companion_cube>
heh, fair enough on the partial application and closure
trillion_exabyte has quit [Ping timeout: 256 seconds]
trillion_exabyte has joined #ocaml
bgs has joined #ocaml
chrisz has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
chrisz has joined #ocaml
wingsorc__ has joined #ocaml
wingsorc has quit [Remote host closed the connection]
bgs has quit [Remote host closed the connection]
bartholin has joined #ocaml
mro has joined #ocaml
waleee has quit [Quit: update & reboot]
waleee has joined #ocaml
Techcable has quit [Ping timeout: 240 seconds]
Techcable has joined #ocaml
waleee has quit [Ping timeout: 252 seconds]
ns121 has joined #ocaml
rak_ has joined #ocaml
hsw has quit [*.net *.split]
infinity0 has quit [*.net *.split]
henrytill has quit [*.net *.split]
sleepydog has quit [*.net *.split]
immutable has quit [*.net *.split]
reynir[m] has quit [*.net *.split]
rak has quit [*.net *.split]
farn__ has quit [*.net *.split]
lisq has quit [*.net *.split]
Absalom has quit [*.net *.split]
ns12 has quit [*.net *.split]
ns121 is now known as ns12
olle has joined #ocaml
Serpent7776 has joined #ocaml
sleepydog has joined #ocaml
immutable has joined #ocaml
infinity0 has joined #ocaml
reynir[m] has joined #ocaml
hsw has joined #ocaml
henrytill has joined #ocaml
farn__ has joined #ocaml
lisq has joined #ocaml
Absalom has joined #ocaml
duckie has quit [Ping timeout: 260 seconds]
mclovin has quit [Ping timeout: 246 seconds]
reynir[m] has quit [Ping timeout: 248 seconds]
glondu[m] has quit [Ping timeout: 252 seconds]
tjnhxmzhmqgytuwt has quit [Ping timeout: 252 seconds]
technomancy[m] has quit [Ping timeout: 268 seconds]
zebrag[m] has quit [Ping timeout: 246 seconds]
lobo[m] has quit [Ping timeout: 260 seconds]
Tuplanolla has joined #ocaml
spip has joined #ocaml
mclovin has joined #ocaml
lobo[m] has joined #ocaml
glondu[m] has joined #ocaml
duckie has joined #ocaml
lobo[m] has quit [Quit: Bridge terminating on SIGTERM]
mclovin has quit [Quit: Bridge terminating on SIGTERM]
glondu[m] has quit [Quit: Bridge terminating on SIGTERM]
duckie has quit [Quit: Bridge terminating on SIGTERM]
mclovin has joined #ocaml
bartholin has quit [Quit: Leaving]
lobo[m] has joined #ocaml
duckie has joined #ocaml
reynir[m] has joined #ocaml
zebrag[m] has joined #ocaml
tjnhxmzhmqgytuwt has joined #ocaml
technomancy[m] has joined #ocaml
glondu[m] has joined #ocaml
humasect has joined #ocaml
<discocaml>
<EduardoRFS> In general my gut feeling for Rust is that if you just recognize Rust linear nature, you can write code as you would in a linear OCaml, just that by default the incentives are there to make it looks like a C clone
<discocaml>
<EduardoRFS> If you get any linear calculus, closures become a problem as the closure could only be used once, as such a closure on a List.map would not be allowed to access anything on the environment, the traditional solution is just to not allow scope capture for closures in traditional ways.
glondu[m] has quit [Ping timeout: 240 seconds]
reynir[m] has quit [Ping timeout: 252 seconds]
tjnhxmzhmqgytuwt has quit [Ping timeout: 252 seconds]
duckie has quit [Ping timeout: 246 seconds]
technomancy[m] has quit [Ping timeout: 265 seconds]
mclovin has quit [Ping timeout: 260 seconds]
lobo[m] has quit [Ping timeout: 265 seconds]
zebrag[m] has quit [Ping timeout: 265 seconds]
humasect has quit [Quit: Leaving...]
<discocaml>
<psychokitty> It's still pretty turgid by comparison. My own experience of transliterating OCaml into Rust was just a lot `Box`ing and terribly ugly code. People have a tendency to see ADTs and pattern matching and go "is this an ML?". The answer is no.
tjnhxmzhmqgytuwt has joined #ocaml
technomancy[m] has joined #ocaml
<discocaml>
<EduardoRFS> ADTs, Pattern Matching, Nominal Typing and no mutation. Additionally I already try to make code linear by default, it was a discovered pattern to me, so it is not a problem in general in my code.
<discocaml>
<EduardoRFS> The closure problem is the most annoying one in Rust, when compared to OCaml, but you can solve a lot of it with CPS, it would be easier if Rust had graded types instead of just linear types
humasect has joined #ocaml
<discocaml>
<Le condor du plateau> what is linear code ?
<humasect>
imperative, procedural?
reynir[m] has joined #ocaml
<discocaml>
<EduardoRFS> in terms of lambda calculus, linear just means it is used once
<discocaml>
<psychokitty> isn't affine more accuraet
<discocaml>
<psychokitty> isn't affine more accurate
<discocaml>
<EduardoRFS> affine is discouraged even in Rust, it gives you a warning, yes technically Rust is an affine system, but modeling linear systems in my head is easier
<discocaml>
<EduardoRFS> `fun x -> x + 1` is a linear function as x is used only once, but not `fun x -> x + x` so to work around this you would say that x is an immutable reference and allow it to be duplicated
<Armael>
'linear' is "used exactly once" and 'affine' is "used at most once (possibly 0)" afaik
<Armael>
'affine' allows you to drop stuff
<discocaml>
<EduardoRFS> the amazing thing about a linear calculus is that it allows you to use "mutable" data structures, without suffering the violation of locality provided by mutation, so in fact a linear mutable calculus is isomorphic to a linear immutable calculus
<discocaml>
<EduardoRFS> for that you need an implicit return, `val Array.set : 'a array -> int -> 'a -> 'a array` would become `val Array.set : &mut 'a array -> int -> 'a -> unit`, but those are the same
<discocaml>
<EduardoRFS> due to that value restriction is not needed in a linear calculus
<discocaml>
<EduardoRFS> I actually like the very verbose version, but I'm a functional programmer
lobo[m] has joined #ocaml
<discocaml>
<EduardoRFS> prefer*
duckie has joined #ocaml
<discocaml>
<EduardoRFS> additionally it seems like you can encode all of affine types in a linear system, if you allow for rank-2 polymorphism or linear growing types
Haudegen has quit [Quit: No Ping reply in 180 seconds.]
Haudegen has joined #ocaml
azimut has joined #ocaml
glondu[m] has joined #ocaml
zebrag[m] has joined #ocaml
mclovin has joined #ocaml
mro has quit [Remote host closed the connection]
<discocaml>
<froyo> koka, I believe, can talk about linearity but in an opt-in manner. What clears up the value restriction is the effect type system. Seems more ergonomic than having to talk about linearity _everywhere_
<discocaml>
<froyo> (the linearity is limited to effect declarations iirc)
neiluj has joined #ocaml
humasect has quit [Quit: Leaving...]
mro has joined #ocaml
<companion_cube>
Ah that'd make sense if you mean the effect handlers can be linear
<companion_cube>
(as they are, de facto, in ocaml 5 afaiu)
<discocaml>
<Kali> continuations in ocaml are technically affine, but the manual says that you should treat them linearly
<discocaml>
<Kali> >>> While the “at most once resumption” property of continuations is ensured with a dynamic check, there is no check to ensure that the continuations are resumed “at least once”. It is left to the user to ensure that the captured continuations are resumed at least once. Not resuming continuations will leak the memory allocated for the fibers as well as any resources that the suspended computation may hold.
<companion_cube>
Yeah, for cleanup
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<discocaml>
<EduardoRFS> @hyphen about linearity everywhere, you can have ergonomics and linearity everywhere if you do something like Graded Types, where the usage count can be hidden and it can be any natural number, similar to GrTT. And because the "grade" is a simple type it can be inferred in almost all cases with HM inference
<discocaml>
<EduardoRFS> this is one of the things that I've been toying with, it makes most code looks normal, the only downside is that some operations on grades must be added to allow for traditional closures
<companion_cube>
in 10 years, `a -> b` will actually mean `a ~[e]_n~> b` 🤔
<companion_cube>
with effect [e] and grade n
waleee has joined #ocaml
<discocaml>
<EduardoRFS> that's exactly where I'm going, hopefully not in 10y
<discocaml>
<froyo> soon™
<discocaml>
<Kali> effects are supposed to become typed eventually, right? i can't remember
<discocaml>
<Kali> in ocaml
<discocaml>
<Kali> "typed" as in, interact with the type system to ensure all effects are handled
xd1le has quit [Quit: xd1le]
<discocaml>
<octachron> Effects are expected to be typed ... at some point (at least before the first commercial fusion reactor).
<discocaml>
<Kali> ah... i see
<discocaml>
<froyo> octachron: clock's ticking, there have been some strides taken in fusion energy \😂
<discocaml>
<octachron> I am more than willing to bet that we get an effect type system much sooner; but fusion reactor helps to set realistic (ok maybe pessimistic in fact) expectations for a research project timeline. And it doesn't hurt than there are worse reason for losing a bet than fusion reactors reaching the commercialisation phase earlier than expected.
<companion_cube>
💯
<companion_cube>
effect typing is going to be the trend of the decade imho
<discocaml>
<EduardoRFS> yeah my bet is that linearity + effects will be the biggest wins in the following years
<discocaml>
<EduardoRFS> pure languages with proper mutation will be dope
<discocaml>
<Kali> oh wow, roc looks cool
mro has quit [Remote host closed the connection]
rak_ is now known as rak
<companion_cube>
I think runtime linearity is more trendy in a way
<companion_cube>
functional-but-in-place, like roc, lean4, etc.
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
gentauro has quit [Read error: Connection reset by peer]
gentauro has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
rf_ has joined #ocaml
rf has quit [Read error: Connection reset by peer]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
trillion_exabyte has quit [Ping timeout: 255 seconds]
trillion_exabyte has joined #ocaml
Stumpfenstiel has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 250 seconds]
mro has joined #ocaml
bgs has joined #ocaml
mro has quit [Ping timeout: 248 seconds]
bartholin has joined #ocaml
ns12 has quit [Quit: bye]
mro has joined #ocaml
ns12 has joined #ocaml
mro has quit [Remote host closed the connection]
<discocaml>
<RegularSpatula> do you have a short example or link of programming ocaml in a linear way?
<discocaml>
<RegularSpatula> oh i forgot about replies not showing on the bridge...that was a reply to EduardoRFS
mro has joined #ocaml
<discocaml>
<EduardoRFS> nope, mostly it goes away as soon as you always unpack and repack records / variants I do stuff such as `let User { id; name } = eduardo in User { id = id + 1; name }`
<discocaml>
<RegularSpatula> By “it” you mean non-linearity?
<discocaml>
<EduardoRFS> I mean "contraction", so yeah
<discocaml>
<RegularSpatula> Gotcha
<discocaml>
<RegularSpatula> I didn’t know the technical term