Myrddin: a systems language that is powerful and fun

"Are you tired of your compiler Just Working? Are you tired of having your standard library having the basic functionality you need? Do you long for the days when men were men, and debuggers operated on the assembly level? If so, Myrddin is for you."

That was awesome. Either you're delivering a refreshing amount of honesty or like to under-promise then over-deliver like me. ;)

Have you used the D programming language at all? http://dlang.org/

If so, does myrddin have any benefits (current or planned)?

I think the Main features could be shifted above status.

But I would like to point out the first example shows type inference, arrays/slices that know their own size, and tuples, all of which are very interesting in a language that is otherwise the same as C. Perhaps it can be made more obvious though.

Couldn't agree more. Even worse are GitHub READMEs that usually go on and on about how to download, compile, install and run the compiler (how about making it so simple you could do it in 2 lines?!) and how to contribute code, without actually explaining what makes the language different.

It makes closures relatively clean, since the syntax is usable directly as an initializer for constants.

    var f = {arg
        body
    }

    const main = {
         g({arg; body})
    }

No. It is memory dangerous. Please use appropriate personal protective equipment when using this, or you may find you have lost all memory of your family.

More seriously: no, it makes no guarantees, but it tends to a much safer style by default: Bounds are checked, raw pointer arithmetic is ugly, clunky, and rarely used (although useful within, eg, the memory allocator), implicit conversions are gone, and null pointers aren't present in either the language or the library. You can define your own, even in a generic manner, but nothing uses this ability. Uninitialized variables are generally a compile time error (barring some bugs in the data flow analsyis), and so on. You can poke holes in the type system, but these holes are explicit.

As a result, most code written is going to be far safer than, say, C.

From paragraph 3, emphasis mine:

> Myrddin is not a language designed to explore the forefront of type theory or compiler technology. It is not a language that is focused on guaranteeing perfect safety. It is satisfied to be a practical, small, fairly well defined, and easy to understand language for code that needs to be close to the hardware.

Memory safety is also absent from the 'Major features' list.

it has bounds checking, everything uses slices, and you rarely need to use pointers so it is far safer than C, but not perfectly safe.

Dentist: Is it memory-safe?

Hoffman: Is what memory-safe?

Dentist: Is it memory-safe?

Hoffman: I don't know what you mean. I can't tell you something's memory-safe or not, unless I know specifically what you're talking about.

Dentist: Is it memory-safe?

Hoffman: Tell me what the "it" refers to.

Dentist: Is it memory-safe?

Hoffman: Yes, it's memory-safe, it's very memory-safe, it's so memory-safe you wouldn't believe it.

Dentist: Is it memory-safe?

Hoffman: No. It's not memory-safe, it's... very dangerous, be careful.

http://www.artvehicle.com/content/asides/AV-37-1228768613.jp...

We detached this subthread from https://news.ycombinator.com/item?id=10954802 and marked it off-topic.

Go would show channels. Rust would show the prevention of a memory ownership bug. Elm would show reactivity. Haskell would show that a monad is just a monoid in the category of endofunctors. what's the problem?

If you haven't got something interesting and at least unusual to show off very early in your docs, it's something to think about in your language design.

Now, you may have to build up a bit, and I'd certainly say you shouldn't bend your entire language around the "one cool demo", but I do think your early docs should make a hard burn towards whatever it is that sets your language apart. It's just basic sales.

(Elsewhere in this thread ori_b says this was not an intentional release, so I mean this as general advice, not targeted at this case. I don't know how to prevent too-early linking on social media sites short of not releasing anything public, which has its own problems!)

It's not about computational power; this should have been obvious and not needing of clarification.

Unless of course you're trying to argue that the difference between python and javascript, for instance, is what each is capable of computing?

Hi jsprogrammer.

You read my comment way too literally. I did not mean that a new language should have a feature that can literally not be done anywhere else. I meant: what are the uncommon features? What sets this language apart from the (dominant) other langs?

As someone else pointed out, in golang this would be goroutines or channels or golang's approach to composition vs inheritance. You can certainly implement those in another language, but they're not first-class features in most other langs. Put together, those elements give golang it's characteristic flavor.

For this new lang, I'm interested in learning (as early in the docs as possible) what sets it apart from C, C++, golang, python, ruby, JS, haskell, erlang, D, etc. The hello world example teaches the reader something, but it's not the thing a person first landing on that page probably cares about.

And going back to my original statement, there's lots of things that are still missing from programming langs and associated ecosystems. Just look at JS, and how even today people are still furiously trying to extend it and work around it just to build simple reactive websites.

> You won't find such a new language. Most languages in use are already known to be Turing-complete.

I beg to differ: http://tkatchev.bitbucket.org/tab/

(Sorry for the shameless self-promotion, but you're wrong that nothing new can be invented.)

A charitable interpretation of the sentence you quoted is your ending sentence.