* specified structure layout (e.g. bitfields)

* memory layout awareness (e.g. alignment & packing)

* memory ordering awareness (e.g. memory fencing)

* integration with processor intrinsics (e.g. SIMD)

Don't show me a "Hello, world!" example; show me a highly optimized lock-free single-writer single-reader queue. Show me code to decode/encode network protocols. Show me how to access MMIO.

As an embedded developer, I find C simultaneously not high-level enough and not low-level enough. What I would want to see in a language replacing C is at least:

* decoupling of data types from storage size from modular arithmetic (still allowing all to be specified)

* decoupling of logical structure layout from physical structure layout (allowing both to be specified)

* decoupling of on-the-wire layout from in-memory layout

* more expressive memory ordering/visibility constraints

* hygienic generics (Myrddin gets points for this, C++ does not)

* a proper module system (like OCaml's)

* more expressive means of hinting optimizations (such as when to make stack frames, spill registers, unroll loops, etc.)

That is, a new language needs to expand in both directions – higher- and lower-level – to replace C for "close to the metal" work. Just higher-level, like Myrddin and kin (OCaml, Rust, etc.), won't cut it.

      pack = std.packbits(some_struct)

Memory ordering, visibility, etc -- I'd love to have that added. I haven't figured out what exactly I want that to look like. Give me ideas, and I may very well implement them.

SIMD is just a matter of finding time, I think. I haven't put much work into making exposing intrinsics yet because, let's face it, the generated code is slow right now, so optimization should probably start there. General usability (eg, DWARF output, profiling, more sanity checks) is also a priority.

And I'd like to be self hosting before I do too much feature growth.

    char buf[2048]; /* if you hit this limit, shoot yourself */

It works well enough for now, but it's a stopgap until I manage to get runtime types and pluggable formatters that can be used in places other than writing directly to an FD. This code is good enough for debugging and simple output to the user's command line, but it's extremely crude and limited. It also interacts poorly with type inference, since the compiler figures out many types for you, and it's hard to know what format specifier to put. Combine that with zero type checking on format args, and you get lots of corrupted output.

A limited buffer size is the least of that code's problems.

In short, it's certainly not final, and I'm certainly not satisfied with it as it stands. As for fixing it: Long term, I should be able to do

     std.put("% % %", "string", 123, 'c')

(Syntax I have in mind: %{options}, where {options} is optional, and gets passed to the format plugin as a set of flags)

(If it's still not clear: I, and I suspect others, don't appreciate being insulted and threatened. Even in code comments. Even if it's meant "in jest".)

In any case, removed.

In terms of the comment itself, I really wish people would avoid violent or otherwise inappropriate language in their projects. A good rule of thumb is to not say it if you wouldn't say it to the President's children while in public.

Even beside violent comments, avoid disrespectful comments in general. If you wouldn't say it in person to someone who's working on the project with you, don't say it in a comment.

(I'm sure there are coders who are fine with saying disrespectful things in person to collaborators. I choose not to work with those people.)

Actually, no. Having lived through the C compilers of the 1980s on 16-bit PCs with their four different memory models (and optional 8087 floating point processor support), I'm very happy to have a C compiler that Just Works. :)

This is a one person project so far, and there are tons of bugs that haven't been flushed out yet. It's not too hard to crash the compiler yet, and I'm sure there are ways to get it to miscompile. (I recently fixed a couple, where it was trying to put overly large integers into immediates in some cases). Obviously, nobody likes debugging the compiler or tracking down miscompilation, and as things mature it will stop being an issue.

I've written ~10k lines of code in this language at this point, so at least some stuff is flushed out.

"More seriously, Myrddin has the goal of replacing C in it's niche of OS and embedded development, but making it harder to shoot yourself in the foot. It's a language that matches the author's taste in design, and if other people want to use it, so much the better."

EDIT: Yep, this is definitely the case. The guy just has a really good sense of humor and doesn't take himself too seriously. Just read his "Beyond..." section!

Then you should stay away research and toy programming languages and stick to tried and tested languages and compilers. And perhaps refrain from commenting on discussions related to them if you don't have anything to bring to the table.

And I'm pretty sure it was a joke, kinda like Linus' "real men write their own device drivers" back in 1992 or so.

> By the way, GCC, in case you're listening? Fuck you!

There's a well known software company in Redmond, WA and a famous hardware company in Santa Clara, CA that can provide you with high quality tested compilers in exchange for a little bit of money and agreeing to their licensing conditions. No one is holding a GNU to your head.

GCC is an awesome project that has liberated computing in various fields. 20+ years ago you had to pay a lot of money for C compilers that were worse than GCC in every way.

That attitude isn't going to get you very far. GCC is a team effort and if you don't want to take part in it, then don't.

Aw hell. Back in 1992, during my Software Engineering class project, we discovered a bug in GCC where it produced wrong answers if we swapped the position of two unrelated functions. We found multiple bugs in GCC, in fact.

My point is that a compiler that Just Works is sometimes preferable to one that Does More imperfectly.

  $ echo 'Fuck you!' > fuck_you.c; gcc fuck_you.c
  fuck_you.c:1:1: error: unknown type name ‘Fuck’
  fuck_you.c:1:9: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘!’ token

    $ echo 'Fuck you!' | gcc -xc

    clang: error: no input files

For those of you wanting help with pronunciation, "dd" is pronounced like the "th" in "the".

Interestingly, this project doesn't seem to use LLVM, but has a back end of its own.

But I agree, LLVM has made it really easy to write simple compilers that emit fast native code via LLVM.

I'd love to get people actually playing with Myrddin, but remember the joke I made on the page about broken compilers, miniscule standard libraries, and debugging in assembly? That wasn't a joke.

Play, but unless you're sure of what you're doing, don't depend on it actually working. Not yet, at least, although it's getting there.

As far as performance goes -- I've put zero effort into optimizing, and depending on the style and features you use, you tend to get between 2x (for purely numerical code) and 8x (for heavily union-using code with value semantics) overhead compared to C right now. Some basic optimizations should bring that down really quickly.

I'm excited already! I always love new alternatives to C.

That being said, and making no judgements about Myrddin itself...

> It also attempts to strong type checking, generics, type inference, and other features not present in C.

This sounds like C++. C++ as a whole is insanely complex, but it's also an awesome low level language that provides zero-cost abstraction mechanisms. It's really not all that hard to stay inside a sane subset of C++.

If you scroll down further on the linked page, under the section 'Major Features', it start to sound exactly like Rust. Exactly.

Again, I'm not trying to make any judgement about Myrddin by bringing up C++ or Rust. It's joined my bookmarks along with all the other interesting programming language implementations I have come across is the past year. Can't wait to dive into some of them in more detail when I have the spare time.

I wouldn't say that. It appears to have a subset of Rust's features, but there is no word on concurrency, and that's definitely where Rust is trying to have an excellent user story. Also, Rust doesn't have global type inference.

AFAIK, Rust can infer types within a function, but not the signature of the function itself. On the other hand, Haskell uses Hindley-Milner type inference to infer the types for the whole program (in practice, you'll want to add type signatures anyway, but that's not strictly necessary).

Then there's the old joke. A Computer Scientist is someone who can write a computer language. A Gentleman Computer Scientist is one who refrains.

Excusemeijustthrewupinmymouthalittle.

    generic parseint = {some_str
        -> magic_algorithm(str)
    }

And, yes, you can make things generic only in the return type, and have that inferred.

But I like Java, so feel free to ignore me.

C is sparse. I like that. Less "clever ways to screw up that others have to debug later".

I can't disagree about C++. I only use a chunk of it myself.

Have you considered hosting it on github instead of your own server? It may lower costs, and more importantly (to me at least) it's a more familiar platform so it's easier for me to browse around, and more likely to get forks and pull requests and issues filed.

I should really pull the test program out of there, and make it actually demo things nicely, rather than being an initial "let's see if the code I'm writing actually works" pseudo-test.

So awesome.

The least you could have done is explain what you don't like about it and how you would have made it differently to make it better.

This kind of behavior is something that pisses the hell out of me, and to be frank it also keeps me from sharing some of my for-fun projects. I don't want to spend a lot of time documenting them and writing a blog post to hear some dumbass call it "awful" without explanation.

You're wrong. Liking isn't a rational argument for anything. Nimrod is an awful language and worse runtime. Copying the unnecessarily verbose Pascal and Ada is going backwards in time. N has bazillions of overlapping features that are going to be very troublesome to verify the correctness of. Worse still, creating a language with so many non-orthogonal patterns makes understandability of a codebase harder.