zesterer

Yes, exactly. The point is to make a toy that proves the concept and gives you insight into the overall design, not to build something with polish!

Accidentally clicking on anything resulting in accidental local deletions and modifications to the article is extremely irksome. Skill issue, I guess?

> Why is a launcher required?

Because Veloren's update cadence for most servers is substantially more frequent than most package repositories are willing to handle (trust us, we've tried!). You can install the game without the launcher, but don't expect it to be compatible with most servers.

> Is the launcher spying on my system, sending information back to HQ?

Categorically, no. The only information we record is an incrementing counter for each architecture downloaded. You can see this data here: https://grafana.veloren.net/d/boL6rzSGk/airshipper?orgId=1

> Can't you tell me the game needs updating when I play the game and then update the game in-game?

That's exactly what the launcher is doing.

> Are you going to throw me advertisement banners when you're not making or being greedy?

Categorically, no. Veloren is open-source (GPL 3), and developed by a close-knit and dedicated community of volunteers. It's a hobby project and will always be free-as-in-liberty as well as free-as-in-beer.

> What if the update fails?

I'm not sure why it would (bar an iffy connection), but the launcher works in offline mode just fine too.

> but launchers come bloated.

Ours doesn't.

> then requiring an additional 10GB download for the actual game

I think we're up at a few hundred MB right now. Most of that is music. It's worth it :)

Every new programming language is just Rust but worse and it hurts me

I don't know, something tells me that lawmaking-by-git is somehow less accessible to the 'regular citizen'.

I've never understood the hate for variable shadowing. Maybe it's because I mostly use Rust, but I've always found it a useful boon for readability. You often want to extract/parse/wrap/package some value within the middle of a function in a manner that changes its type/form but not its semantic purpose. Shadowing the old value's variable name is brilliant: it communicates that there's a step-change in the responsibilities of the function, demarcating layers from one-another and preventing accidental use of the old value.

Weird problems with physics were everywhere before Einstein. Maxwell comes painfully close to discovering GR in some of his musings on black body radiation.

Noticing that there was a problem was not the breakthrough: trying something bizarre and counter-cultural - like assuming light speed is invariant over the observer - just to see if anything interesting drops out was the breakthrough.

The whole point of this post is that the things AI isn't good at and has never been good at will be the limit to otherwise-exponential growth.

I think that's a retcon. Rust people did not "decide that leaking is safe" all of a sudden, that's cart-before-horse. Rust's memory model was still in its early stages back then and there was a belief (in hindsight, a mistaken belief) that destructors could be used as a means to guarantee memory safety. This turned out to be poorly reasoned and so, to preserve a consistent model of safety for other code, it was decided that having safety rely on the invocation of destructors was unsound. It's not possible to do this without also having leaks be safe, so that's the world as it is.

If "is leaking memory safe?" is an issue of contention for you, I'd suggest that it's a good idea to do some reading on what memory safety is (I mean that in all sincerity, not as a dunk). Memory safety, at least by the specific and highly useful definition used by compiler developers, is intimately entangled with undefined behaviour, but memory leaking sits entirely outside this sphere. This is as true in C and C++ as it is in Rust.

Decentralisation is a socio-political solution, not a technical solution. It directly addresses the problem of media ownership and proliferation.

> Interesting blog post

No, no it's not. There is nothing redeeming to be found here, it's nonsense. It's historially ignorant trad-pilled vibes about the past combined with bizarre techbro mumbo jumbo about the future. Neither have any meaningful grounding in reality, nor anything interesting to say about the world.

There are likely several > earth-mass objects in our solar system that are as-yet uncatalogued, and almost certainly many hundreds of dwarf planet-mass objects too. Granted, they are further out, but their influence is almost undetectable even over millions of years. It's pretty unlikely that the presence of an earth-mass black hole for just a few years (since it would likely be moving many times solar escape trajectory) would have much in the way of a measurable impact.

I'm struggling to see how you can be so calm about what you just said. To me, the idea of a system that works 99% of the time and doesn't work 1% of the time is utterly terrifying, far more so than a system that works only 50% of the time. 1% is small enough for a human operator to become complacent, but still many orders of magnitude greater than an acceptable risk factor. It seems like exactly the sweet spot that's going to maximise loss of life.

The problem with this is that pollster doesn't, by itself, provide a signalling mechanism by which bottom-level futures (such as OS-provided IO primitives) can signal the executor. It isn't a "light-weight replacement" for tokio, tokio does a lot of stuff that pollster simply can't because tokio is a reactor + a runtime, whereas pollster is just a runtime. [This page](https://rust-lang.github.io/async-book/08_ecosystem/00_chapt...) gives some nice details about the difference, and hopefully some sense of the sheer difficult that comes with trying to integrate a default reactor into `std` without it falling well short when it comes to extensibility.

Ah, that explains why 5,000 years ago the average life expectancy was just over 6 months.

It's no accident that Rust's bootstrap compiler was written in OCaml. Rust borrows a lot of ideas from it. Arguably, OCaml and ML are closer ancestors of the language than C.

I like Rust, I use it as much as I can. But, it actually doesn't bring many new features to the table. What it's done is successfully learn from the past, scooping up the good ideas and ditching the bad ones. Its real selling point is how it wraps all of those old ideas up into a modern, well-maintained, stable package that's ready for use in the real world.

That's... simply not true. Pointer arithmetic is not, in general, safe. Example: https://doc.rust-lang.org/std/primitive.pointer.html#method....

It's still going strong! We just released 0.15. It's still in pre-alpha, but the map is much less sparse nowadays and there's a lot more to do!

Founder & core dev here.

Our target audience is just as much potential contributors as it is actual players. Mentioning Rust is very deliberate: it pulls in a lot of motivated developers, both those trying to learn the language and those with expert knowledge looking for a creative, relaxed way to put their skills into practice.

Chumsky still has trouble with left recursion, like many PEG parsers, but it's fairly easy to rewrite such grammars without left recursion as demonstrated in the tutorial: https://github.com/zesterer/chumsky/blob/master/tutorial.md

I think my other answer here should provide an answer: https://news.ycombinator.com/item?id=31989227

Thanks!

> does numerical destructing require that one of the terms be a constant?

Yes, the general pattern is `n + K`. I'm looking to expanding this to other operations in the future too.

> Did you mean arg -> f ?

Yes. I changed the syntax recently, but forgot to change the README. Thanks for pointing this out!

Ah, I see what you mean. Yes, effects are always a set in terms of the final monomorphised type. This is an interesting case though, so I'll look into it further and see whether I can come up with sensible, unsurprising semantics. Thanks for pointing this out!

Tao's effects are nominally typed, so there's no way to accidentally mix them up in the way I assume you're describing. For example:

    # Define a new effect that yields to the caller
    effect yield A = A => ()

    # A generator that emits numbers
    def one_two_three : yield Nat ~ () = {
        yield(1)!;
        yield(2)!;
        yield(3)!;
    }

    # Print the numbers to the console
    def main : io ~ () = {
        one_two_three
            handle yield Nat with n => print(n->show)!
    }

> Does your flavor of algebraic effects allow distinct effects of the same type

Could you give an example of what you mean by this? Multiple effects can be combined together (although I'm still working on handlers for multiple effects), for example:

    effect console = input + print

    fn greet_user : console ~ () = {
        print("Please enter your name:")!;
        let name = input!;
        print("Hello, " ++ name)!;
    }

> Do you have plans for making pattern matching extensible?

I have no plans as of yet. Extensible pattern-matching seems to me to be quite hard to unify with exhaustivity. Tao supports most of the patterns that Rust/Haskell supports.

Yep, this is the case: the type-checker allows arbitrary computation to occur at compilation time. You can see some of that here, where I've implemented peano arithmetic/addition/multiplication/branching using the type system: https://github.com/zesterer/tao/blob/master/examples/type-as... . I've not yet had the time or mental fortitude to implement something more non-trivial like N-queens or a Brainfuck interpreter, but perhaps eventually!

The code is a bit of a gimmick, not really the sort of thing you'd have in a real program. It's just there to demonstrate that the compiler doesn't need explicitly telling which typeclasses associated types correspond to. That said:

    fn show_negative A : A -> Str where
        A < Neg,
        A.Output < Neg,
        A.Output.Output < Neg,
        A.Output.Output.Output < Neg,
        A.Output.Output.Output.Output < Show,
    =
        a => (----a)->show

This is a function, called `show_negative`, that is generic over a type, `A`. The function takes an instance of `A` and returns a `Str` (string).

In terms of implementation, the function is quite simple: it just negates the input value a bunch of time and then `show`s it as a string using the `Show` typeclass (equivalent to Haskell's `show`: https://hackage.haskell.org/package/base-4.16.1.0/docs/Prelu...).

Arithmetic operations such as negation are defined using typeclasses. Here's the definition of `Neg`:

    class Neg =
        => Output
        => neg : Self -> Self.Output

This means that types that can be negated must provide two things: an output type produced when they're negated, and a function that actually performs the negation. For example, `Nat` (natural number) looks like:

    member Nat of Neg =
        => Output = Int
        => neg = fn x => (implementation omitted because it's a built-in intrinsic)

i.e: when you negate a `Nat`, you get an `Int`.

The `where` clauses on the `show_negative` just constrains the output type of negating the `A` in such a way that its output type is also constrained, in a chain, with the final type in the chain being `show`-able.

Tao has typeclasses (like Haskell) that allow for compositional parameteric polymorphism. It also has data types (records, sum types, etc.) and functions, but deliberately does not bundle the two together.

There is no module system yet (only a temporary C-like #include system): that's on my list of things to work on!

There wasn't really any single resource I read. Frustratingly, I find it quite difficult to read research papers (I'm told it's a skill acquired with practice, but it's something I've never gotten into). Most of the implementation is the product of several rewrites and false-starts, along with the occasional hint I've read about here or there on the web.