Hacker News new | ask | show | jobs
by onlyrealcuzzo 16 days ago
Cool - it sounds pretty similar. It's interesting that it looks so different. I'll have to investigate more.

WRT to inference, yes. I infer everything in EASY mode.

And the compiler give the user autofix via choice when a type is ambiguous (I don't default to huge union types - I assume no one wants to do that and make them choose a type - may potentially allow AutoUnion to allow that).

I couldn't tell if you're using affine ownership, but I assume so if you don't have a GC. If they try to create an alias - they get a use after move error, and the compiler tells them they need to either COPY (auto-fix) or create a RefCount (usually auto-fix) - they pick.

2 comments

No, blorp doesn't use affine types (one or zero uses). In blorp, ownership is not explicitly controlled by users at all, so it's opaque. Under the hood, it's perceus for compile-time ownership and borrowing and automatic reference counting with copy-on-write optimizations for the runtime. This is made reasonably easy for the compiler to reason about in blorp because semantically it doesn't _really_ have in-place mutation -- `var` really means "re-bindable" to a new value; and then under the hood we'll mutate in place where we can.
Interesting.

How do you prevent data races in concurrent code?

Or do you not allow shared mutable memory?

Yeah, no shared mutable memory; coordination is done via channels.
Awesome.

If you want some feedback, I'd recommend putting some concurrent benchmarks on your home page (and if you have some already - I'd clearly separate them).

When I originally scanned it, I just assumed this was another predominately sequential language with no good concurrency story.

If you're actually competitive with Rust/Tokio/Crossbeam and Go on the most common concurrent patterns, then you've got a really compelling project!

I suspect if you don't cherry-pick benchmarks, you're going to run into some performance problems with not allowing shared mutable memory - though maybe you can avoid most of that if you have some type of built-in actor pattern.

But if you're actually competitive across the board with Go & Rust/Tokio/Crossbeam - I'd love to take a deeper look, because that is NOT easy to accomplish.

I didn't see any of that from a cursory look at the language, though.

Still incomplete there. But yeah performance should be decent. Not aiming for parity either rust or go entirely but in the same ball park is the expectation.
How is compiling to zig? I considered doing it but chose C instead because of how much zig is still changing. I've considered using it's C compiler for targeting multiple platforms locally.
I would HIGHLY recommend transpiling to Zig.

Comptime is very powerful and awesome to use for a transpilation target.

Also, Io and how Zig handles allocation and gives you full control of the allocator make it super easy to do things you probably want to do in your language.