YorickPeterse

While I indeed worked for GitLab until 2021, Inko's development began before I joined GitLab, and GitLab wasn't involved in it at all.

Inko was hosted on GitLab for a while (using their FOSS sponsorship plan), but I moved it back to GitHub as to make contributing easier and to increase visibility. As much as I prefer GitLab, the sad reality is that by hosting a project there you'll make it a lot harder for people to report bugs, submit patches, or even just find out about your project in the first place. I could go on for a long time how GitLab really wasted its chances with taking over GitHub, but that's for another time :)

    > Is the mut marking also for consistency (and/or non-message methods)?  Presumably each actor/object would only process one message at a time so could always have full access to all its data.

This is indeed correct: processes have exclusive access to their data and run a single message at a time. Still having to tag methods as mutable is to prevent you from accidentally mutating data, and to keep it consistent with regular methods.

You're right! Sadly I can't edit the comment any more to correct it :<

Inko's package manager supports non-GitHub repositories just fine. What the original comment likely is referring to is the website only including GitHub based packages. This is simply because the script that populates that list hasn't been extended to support more than GitHub, because there hasn't been a need for it so far.

When there are people using Inko and hosting their packages on another forge such as GitLab, and said forge has an API to get the data needed, I'll happily accept any patches to allow listing of non-GitHub packages on the website. The reason this hasn't been done thus far is simply because there hasn't been a need for it.

The reference counts are used to prevent dropping a value that still has references to it, but it doesn't dictate _when_ that drop takes place. Instead, an owned value is dropped as soon as it goes out of scope, just like Rust.

So no, Inko isn't garbage collected :)

The reference counts don't dictate when memory is released, that happens when an owned value goes out of scope, just as is the case for Rust. The reference counts are merely used as a form of correctness checking. The result is that allocations, destructors, and deallocations are perfectly deterministic.

Deallocating memory itself doesn't crash the program either, rather it's a check performed _before_ doing so (though that's mostly a case of pedantics). This strictly _is_ better than C, because if the program kept running then you'd trigger undefined behaviour and all sorts of nasty things can happen.

If you're familiar with Rust, this idea is somewhat similar to Rust's RefCell type, which lets you defer borrow checking to the runtime, at the cost of potentially triggering a panic if you try to mutably borrow the cell's contents when another borrow already exists.

You can also find some backstory on the idea Inko uses from this 2006 paper (mirrored by Inko as the original source is no longer available): https://inko-lang.org/papers/ownership.pdf

Generally speaking: if you're looking for a non-systems language that gives you similar guarantees as Rust, but with a lower mental cost, and you can stomach the drawbacks of a young language, then Inko might be worth looking into.

As for comparisons to actual Rust programs: I haven't done any side-by-side comparisons, mainly because I worry they may come across as a bit disingenuous, as you'd never pick examples that make your language look worse than whatever language you're comparing to.

Inko defaults to heap allocating objects (except for Int, Float, Nil, and Bool), meaning the data pointers point to is in a stable place. Thus, moving them around is just moving a pointer around, not a memcpy of the underlying data. This in turn means it's fine to keep references around.

To prevent you from _dropping_ a value while references still exist, Inko uses runtime reference counting. Owned values being moved around incurs no reference counting cost, but creating and dropping references does (just a regular increment for most objects, so pretty cheap). When a value is dropped, the reference count is checked, and if it's _not_ zero a runtime panic is produced, terminating the program. Refer to https://docs.inko-lang.org/manual/latest/getting-started/mem... for some additional details.

This setup is perfectly memory safe and sound, though in its current form the debugging experience of such errors (although surprisingly rare, but that might just be me) is a bit painful; something I want to improve over time.

My long-term vision is to start adding more compile-time checks, such that maybe 80% of the cases where a reference outlives its owned value is detected at compile-time. For the remaining 20% or so, the runtime fallback would be used.

In theory this should provide a good balance and only require a fraction of the mental cost associated with Rust. Whether that will work out remains to be seen :)

A class marked as "async" can still have regular methods, which are only available to the inside of the class (i.e. the process itself, not other processes sending messages to it). So you can do something like this:

    class async SomeProcess {
      fn async some_message(...) {
        ...
        some_helper_method
      }

      fn some_helper_method {
        ...
      }
    }

    SomeProcess {}.some_message # This is fine
    SomeProcess {}.some_message # This is a compile-time error

I toyed with the idea of _not_ allowing regular method and thus implicitly making all of them async for an async class, but that might lead to a pattern of async classes being "mirrored" by non-async "helper" classes just to reuse some methods between the different messages of an async class, i.e. you end up with this:

    class async SomeProcess {
      fn some_message(...) {
        SomeProcessHelper {}.some_random_method
      }
    }

    class SomeProcessHelper {
      fn some_random_method {
        ...
      }
    }

I'm planning on doing something similar to what I did for pattern matching [1]: basically building something entirely standalone that fits in 2k LOC or so, and explains the basics (i.e. nominal typing plus basic sub-typing), hopefully such that people can then take that and extend it.

As for _when_ I'll do that, that depends on when I can convince my inner critic to actually commit to the idea :)

[1]: https://github.com/yorickpeterse/pattern-matching-in-rust

The problem about the whole "it's faster (productivity wise) than static typing" has, as far as I know, never actually been proven (certainly not through repeated studies).

Having worked with both dynamically and statically typed languages extensively, I never felt I was _more_ productive in a dynamically (or gradually) typed language compared to one that was just statically typed. For very basic programs you may spend a bit more time typing in a statically typed language due to having to add type annotations, but typing isn't what I spend most of my time on, so it's not a big deal.

In addition, that work you need to (potentially) pay upfront will help you a lot in the long term, so I suspect that for anything but the most basic programs static typing leads to better productivity over time.

You're right about this applying to new languages. I've added a note to the article to (hopefully) make this more clear.

The problem for me was that I had a rough idea of how to implement (essentially it's similar to a recursive-descent parser), but I had a difficult time finding appropriate resources to confirm or deny whether my idea was solid, as well as tips and what not.

Basically, the existing material is a bunch of existing incredibly complicated implementations, the odd blog post that just throws a bunch of code your way without really explaining the why/thought process behind it, and books that aren't worth the money.

The result is that you can of course piece things together (as I did), but it leaves you forever wondering whether you did it in a sensible way, or if you constructed some weird monstrosity.

To put it differently: you can probably build a garden by digging some holes and throwing a few plants around, but without the right resources it can be difficult to determine what the impact of your approach may be, and whether there are better ways of going about it. Oh and I'm aware there are resources on gardening, it's just a metaphor :)

Ah yes, because good engineers can only be found in San Francisco and similarly expensive areas.

That is only a problem if you insist on hiring people from such expensive areas. Given Oxide hires remotely, I doubt this is an actual problem for them.

If you scroll past the code examples, there are a few more details, though for more you'll need to look at the documentation (specifically https://docs.inko-lang.org/manual/main/getting-started/memor...).

> Is `&T` a type?

Inko's syntax for references is `ref T` for immutable references/borrows, and `mut T` for mutable ones. Unlike Rust, you can't implement methods/traits _only_ for references, instead you can only implement them for the underlying "base" type. So `impl ToString for String { ... }` is valid, but `impl ToString for ref String { ... }` isn't.

> Can you store it in a structure, or return it?

Yes.

> Can you have a reference to a reference?

No, `ref ref T` is "collapsed" into just `ref T`, and the language has no notion of pointers and pointer-pointers.

> If you can have a function `f(&T, &T) -> &T`, how do you distinguish whether the reference it returns lives as long as the first or second argument

Inko doesn't have a borrow checker, so it doesn't. Instead it relies on runtime reference counting to prevent dropping of values that still have references to them. Over time I hope to implement more compile-time analysis to reduce this cost as much as possible, but borrow checking/lifetime analysis like Rust isn't something Inko will have.

Or to put it differently, I want the compiler to catch say 80-90% of the obvious "this ref outlives its pointee" errors without complicated borrow checkers. For the remaining 10-20% the runtime check should suffice.

Perhaps you'd be interested in Inko (https://inko-lang.org/). It's obviously not there yet in terms of tooling and what not, but it might scratch an itch for those looking for something a bit like Rust, but easier to use.

Disclaimer: I'm the author of said language :)

Had a similar issue with a previous standing desk: turning the motor on to adjust the height of the desk would turn on the RGBs on my keyboard (which uses a skeleton-like structure, so you can see the wires), though not always.

After some trial and error I determined the motor likely produces enough interference to trigger the RGBs to turn on. I ended up just cutting the RGB cables because I didn't use them anyway, as I didn't have anything to shield the keyboard (or anything else for that matter) from the motor.

Honestly that just sounds like "I want things for free, but I'm not willing to give back anything in return".

Ah interesting. Do you have any guides about fedpkg that you'd recommend?

The issue is that mock does nothing for moving sources in place, it's just rpmbuild and a chroot. From what I could figure out, fedpkg is more about working with existing Fedora packages shipped as part of the official repositories, and less about "Here's how to get this random project you don't own into copr".

I considered using an Arch container for development, but ultimately felt this wouldn't actually make my life easier, as I'd still have to deal with updating issues/manual work. Instead I'm just running a Fedora 37 container, and thus far it's working great.

> and an author who has somehow never had to build a package for anything but Arch (deb would be much worse) complaining about the difficulty of building RPMs to install/overlay on the host system, which is not the intended use case anyway, is silly.

I can assure you I've built packages for more than just Arch Linux, and that building RPMs was by far the most frustrating experience of all :)

I know of eye witnesses that have seen a pig fly, and I have data that shows pigs can fly. Clearly this means pigs can fly.

Thanks!

This is only a problem when there are other loud vehicles around. If all vehicles are more quiet, you'll still be able to hear them, it just won't be as loud as it is today.

That doesn't mean it's not obvious to stop wasting even more energy on cryptocurrency scams. While it's not going to undo the waste that existed before, it might help to prevent it from getting even worse.

No, originally there was no quota enforced to begin with if my memory serves me right. The limits discussed here are likely meant to gradually tighten up the limits, rather than immediately locking out projects that exceed these limits.

> What do I do to make my abs more visible within 13 days?

My honest advice: nothing. Going to the beach should be about enjoying the beach, the weather, etc; not about what some random person may think about your muscle or lack thereof. If that's really what they care about, they're probably not worth worrying about.