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

OCaml: a Rust developer's first impressions

pthorpe92.github.io

Post reply on HN
Print view View original

151–157 of 157 posts

Re: OCaml: a Rust developer's first impressions

#151

Post by fweimer »

nextaccountic wrote: post #149
fweimer wrote: post #99

Earlier quoted context omitted.

Rust currently cannot reliably panic on allocation failures because the error object is inside a Box, which itself requires allocation. This means that if memory is tight, panicking itself might fail. For reference, this is the type that is returned from catch_unwind: https://doc.rust-lang.org/std/thread/type.Result.html But I completely agree that Rust has exceptions. They are even used in the toolchain implementati…

> Rust currently cannot reliably panic on allocation failures because the error object is inside a Box, which itself requires allocation. This means that if memory is tight, panicking itself might fail. This seems like something that should be allocated at program startup, just like other things like the program's environment (I think it's copied to Rust's own data structures at startup to avoid using the non-threads…

The Box type, as used in the return type, transfers ownership to the calling function, so a check in the deallocator path would be needed to recognize this special object and avoid deallocating it. GCC has an emergency pool for its exception allocations, which is also quite ugly. And of course that pool can be too small.

It should be possible to add a third arm to that Result type, returning some &'static reference, but I'm not sure how to do it in a backwards-compatibile way.

Re: OCaml: a Rust developer's first impressions

#152

Post by dan-robertson »

sakras wrote: post #105
dan-robertson wrote: post #18

Earlier quoted context omitted.

I think the ‘is or is not a true ML’ argument is a bit unwinnable so I won’t comment on it. Regarding ‘functional’, Rust makes it harder to write in a traditional functional style because (a) it doesn’t offer tail-call elimination and (b) the resource-ownership tracking makes most normal functions feel side-effecty. I think it’s pretty hard to have a natural-feeling functional style without cheap allocation and some…

> it doesn’t offer tail-call elimination Why not? I’ve heard people say this about C too and I never understood it: LLVM and GCC both have optimization passes that perform tail-call elimination.

I don’t know the actual reason. It may have been a desire to keep flexibility in the language design by not imposing TCE rules. I think one reason is that you can’t have a tail call if you need to free things afterwards, so changing the signature from taking an object to borrowing it could make calls to the function no-longer eliminatable. Rules for which calls are tail-calls can already be confusing to people in simpler languages.

I think they also make debugging harder, aren’t used much in higher-level code, and aren’t necessary if you have good looping constructs.

Re: OCaml: a Rust developer's first impressions

#153

Post by misja111 »

tromp wrote: post #95
misja111 wrote: post #69

Earlier quoted context omitted.

OCaml is not a very good fit for competitive programming, you're better off with a language like Python there. Writing code in a functional language like OCaml requires a mind switch. This can take quite a while. It took me years to really 'get it' after having programmed for 30 years in imperative languages. Now I prefer writing code in FP for a lot of things, but not for everything. E.g. for coding some algorithms…

While Haskell's Array type indeed immutable, there is an incremental update function (//) :: (Ix a) => Array a b -> [(a,b)] -> Array a b that gives you a new updated array. As long as you no longer refer to the old instance, this is as efficient as a mutable array. But Haskell also offers the mutable STArray and STUArray, for boxed and unboxed types [1]. These preserve their purity by being monadic. [1] https://hacka…

> As long as you no longer refer to the old instance, this is as efficient as a mutable array.

On paper this is true, in reality though it probably is not. Immutable Haskell arrays are implemented with pointers, mutable arrays are implemented as contiguous memory allocations, so they have great cache locality.

Re: OCaml: a Rust developer's first impressions

#154

Post by grumpyprole »

IshKebab wrote: post #125
ReleaseCandidat wrote: post #96

Earlier quoted context omitted.

> Using an editor that shows type inlays (e.g. VSCode) helps a lot but not fully because a lot of types are inferred as generics. That is because they are generic most of the time. This is also fun when using `#trace`in the REPL and all you see is ` ` instead of the "real" value

Right but being overly generic makes them hard to understand. Generics are kind of like "compile time dynamic types" and they have many of the downsides of runtime dynamic types: * intent of the author not clear * auto-complete etc. doesn't work as well * type errors not caught as early (for generics this means you get super confusing type errors) Obviously some functions are intended to be generic (e.g. operations o…

Actually generic types can make reasoning about code much easier. This is the opposite of runtime dynamic types. Generic types tell you what the code doesn't (and cannot) do. Any generic type basically cannot be inspected or unpacked, see the paper "Theorems for free" for examples.

Re: OCaml: a Rust developer's first impressions

#155

Post by tomca32 »

u320 wrote: post #118
tomca32 wrote: post #55

Earlier quoted context omitted.

Creator of the Rust language Graydon Hoare is working on Swift, so it’s probably the other way around

He left Rust long before ? was introduced.

oh fair enough. Didn't know the timing of that, so I thought it was connected.

Re: OCaml: a Rust developer's first impressions

#156

Post by nextaccountic »

fweimer wrote: post #151
nextaccountic wrote: post #149

Earlier quoted context omitted.

> Rust currently cannot reliably panic on allocation failures because the error object is inside a Box, which itself requires allocation. This means that if memory is tight, panicking itself might fail. This seems like something that should be allocated at program startup, just like other things like the program's environment (I think it's copied to Rust's own data structures at startup to avoid using the non-threads…

The Box type, as used in the return type, transfers ownership to the calling function, so a check in the deallocator path would be needed to recognize this special object and avoid deallocating it. GCC has an emergency pool for its exception allocations, which is also quite ugly. And of course that pool can be too small. It should be possible to add a third arm to that Result type, returning some &'static reference,…

I mean, allocate something like

static ALLOCATION_ERROR: Box = (something);

and then use this variable whenever there is an allocation error. you might need unsafe { } but that's okay, the stdlib is full of unsafe

Re: OCaml: a Rust developer's first impressions

#157

Post by fweimer »

nextaccountic wrote: post #156
fweimer wrote: post #151

Earlier quoted context omitted.

The Box type, as used in the return type, transfers ownership to the calling function, so a check in the deallocator path would be needed to recognize this special object and avoid deallocating it. GCC has an emergency pool for its exception allocations, which is also quite ugly. And of course that pool can be too small. It should be possible to add a third arm to that Result type, returning some &'static reference,…

I mean, allocate something like static ALLOCATION_ERROR: Box = (something); and then use this variable whenever there is an allocation error. you might need unsafe { } but that's okay, the stdlib is full of unsafe

If you use it for producing the Box in the return value, you have to move out of it, and then it's gone. If you don't move it, you have a use-after-free bug after the first such panic has been caught and the box has been dropped as a result.
Post reply on HN