7 ms·

Myrddin: new programming language for coding close to the metal

74 points by sdegutis 13y ago

sdegutis 13y ago
> It also attempts to strong type checking, generics, type inference, and other features not present in C. I'm excited already! I always love new alternatives to C.
- dmunoz 13y ago
  I love programming languages. Big or small, toy or serious. Myrddin looks interesting, and I could certainly see myself implementing projects like this as I dive deeper into language design and implementation. 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.
  - mercurial 13y ago
    > If you scroll down further on the linked page, under the section 'Major Features', it start to sound exactly like Rust. Exactly. 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.
    - dmunoz 13y ago
      Yeah, you got me on that one. I shouldn't have used such a strong word. I just wanted to get across that Rust ticked all those boxes (except for "inferred across the whole program" apparently. I just understood that to mean anywhere, but it must have a more technical meaning that I am ignorant of). Good call on Rust's concurrency being a big part of their story.
      - mercurial 13y ago
        > I just understood that to mean anywhere, but it must have a more technical meaning that I am ignorant of) 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).
  - ladzoppelin 13y ago
    Do people that write languages also have amazing programming capability? In other words wouldn't writing a new language be harder than writing any piece of software?
    - sdegutis 13y ago
      I'm not sure there's much benefit to looking for that kind of correlation (or even causation). But yes, this guy seems to be way smarter than me and that excites me :)
    - stcredzero 13y ago
      Not really. Such people merely understand a handful of concepts that come from Computer Science and have enough hubris to attempt such a project. Of course, the better attempts tend to come from better programmers. 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.
  - ori_b 13y ago
    I'm pretty sure I started out working on this before Rust was widely announced, and certainly before it took it's present shape. It was kind of interesting seeing Rust slowly evolve to where I had was aiming off and/or planned to be as it simplified it's type system, dropped typestate, moved GC into libraries, etc.
evincarofautumn 13y ago
Looks closely related to OCaml and similar in feel to Rust. I’m really excited that so many hobbyist language designers are exploring the space of low-level languages focusing on correctness and performance. (But of course I would.)
greenyoda 13y ago
"Are you tired of your compiler Just Working?" 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. :)
- weland 13y ago
  That's the first thing that came into my head. Yes, thank you, I WANT a compiler that Just Works. The last thing I want to debug is stuff my compiler throws up when it thinks it's smart. By the way, GCC, in case you're listening? Fuck you!
  - exDM69 13y ago
    > That's the first thing that came into my head. Yes, thank you, I WANT a compiler that Just Works. The last thing I want to debug is stuff my compiler throws up when it thinks it's smart. 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.
    - weland 13y ago
      Have you ever had to debug badly-generated code? It was a friendly fuck you, btw.
      - 13y ago
midas007 13y ago
It looks awful, almost as bad as Nimrod.
- evincarofautumn 13y ago
  Almost. But who cares? It’s a fun hobby project and you aren’t obligated to give it a second thought. And really, most language designs made in earnest are terrible. The important thing is that people get interested in this kind of language, so that we can move on from languages like C++ whose complexity is approaching unjustifiable for new projects.
- skrebbel 13y ago
  As someone who really likes Nimrod, I'd actually be interested to know why you would say that. But for now, I'll just assume you're a troll.
  - mlvljr 13y ago
    No, I am the troll in this thread! Let's listen to him...
  - midas007 13y ago
    So how do you justify your name calling then? 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.
- exDM69 13y ago
  Wtf is wrong with you? Someone shares a project that they have done for fun and enjoyment and you publicly call it "awful" without any explanation. Would you do that to someone in person when they show you something they've done? 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.
moomin 13y ago
It's an interesting space, and not one many have addressed till recently. I think this is a testament to the success of LLVM. For those of you wanting help with pronunciation, "dd" is pronounced like the "th" in "the".
- wubbfindel 13y ago
  And should sound somewhat like Merlin, since it's the welsh for it. :)
- exDM69 13y ago
  > I think this is a testament to the success of LLVM. 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.
  - ori_b 13y ago
    Yep. I've got some sort of mental problem, and think that writing the backend is half the fun. The frontend is the other half, and library support is the third half. Compiler writing: Now with 150% more fun, and 97% less utility than any other programming project.
TempleOSV2 13y ago
If templeos is not God's official temple, it is nothing. If templeos is God's official temple, it is everything.
NKCSS 13y ago
Found a typo: "A pacakge system"
- exDM69 13y ago
  While we're at it... if the OP is listening: there's a parallel make build problem, the Makefiles don't resolve dependencies correctly when I run "make -j 3".
  - sdegutis 13y ago
    I'm the OP (original poster) but not the author. Which makes me wonder: what's the HN convention for asking the article author something in a comment?
  - ori_b 13y ago
    Fixed.
    - exDM69 13y ago
      Great, thanks. I got the compiler built with single threaded make, but it never hurts to have parallel make working properly.
      - ori_b 13y ago
        It was an actual bug even for single threaded builds -- the test/demo program for libstd hadn't declared a dependency on the library. 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.
TempleOSV2 13y ago
With C++, there is a "this" variable. With HolyC, if you use "..." in the arg list you get a "I64 argc" and a "I64 argv[]".
afhof 13y ago
If you were to say "programming languages today are deficient in X, Myrddin fixes that!", what would X be? From the looks of it, it appears to be nothing. The syntax looks palatable and I like the lack of header files. That said, why would I be better off investing the time to learn your new language? (amongst the myriad other languages)
- mercurial 13y ago
  Assuming that the creator meets his goal to reach C-level performance, C has exactly no item present on the list of Myrddin's major features. If you are programming in a higher-level language, you get performance (again, assuming it's actually fast), and "lightweight" static typing, if you don't have that already. If you're programming in Rust, switching to Myrddin is more debatable (I don't know about D or other languages competing in the same space).
  - ori_b 13y ago
    If you're programming in Rust, and you care about things working, you probably want to stay with Rust at this point. 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.
    - mercurial 13y ago
      I think most people got the "experimental, not mature" bit. Kudos for shipping an entire language, especially with the slew of features it has.
lafar6502 13y ago
I like his halloween costume better than the language
saljam 13y ago
I'm personally quite excited about this space. If the Internet of Things is going to happen, we need better languages than C/C++.
- Qworg 13y ago
  I'm interested in why you believe this to be the case.
  - Joister 13y ago
    Possibly because C has too few features for your average programmers liking, and C++ is a nightmarish hellscape of sprawling features which you have to learn and then intentionally ignore if you want others to understand your code. But I like Java, so feel free to ignore me.
    - Qworg 13y ago
      I've written a lot of Java, so no problem there. 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.
  - danellis 13y ago
    C++ isn't good for embedded. C isn't as productive as an embedded language could be.
    - Qworg 13y ago
      I agree about C++ on embedded. Why is C not productive? Is it that more modern languages handle more background work for you?
      - sdegutis 13y ago
        For me it's mostly just because I have to do a lot of type-switching or writing pseudo-inheritance when I'm still in the prototyping stage of a program in order to have some kind of polymorphism. It's often not very pleasant.
sdegutis 13y ago
Author: 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.
al2o3cr 13y ago
"The identifiers used for constant values are put in Initialcase. Functions and types are in singleword style, although underscores are occasionally necessary to specify additional information within functions, due to the lack of overloading." Excusemeijustthrewupinmymouthalittle.
- ori_b 13y ago
  Generics handle most of the places where you'd care about overloading. You don't need a variant of, eg, parseint for every integer size: generic parseint = {some_str -> magic_algorithm(str) } (Actual parseint code: http://git.eigenstate.org/ori/mc.git/tree/libstd/intparse.myr http://git.eigenstate.org/ori/mc.git/tree/libstd/intparse.my...) And, yes, you can make things generic only in the return type, and have that inferred.
coldcode 13y ago
I love that people keep experimenting with new programming languages. I hate that there are so many people experimenting these days I can't examine them all.
colanderman 13y ago
While pleasant-looking, I'm not seeing any "close to the metal" features. C (with its extensions and standard library) has a stronghold in the embedded world because it supports: * 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.
- ori_b 13y ago
  Patches accepted -- The language is young, and I have certainly not added all the features that I want. For example, generics should be able to provide enough runtime information that I could do something like: pack = std.packbits(some_struct) and get efficiently packed values. 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.
  - colanderman 13y ago
ori_b 13y ago
Bowing to popular demand, I also have a github mirror: https://github.com/oridb/mc/ https://github.com/oridb/mc/
robocaptain 13y ago
All I can think of when I read Myrddin is an old set of PennMUSH code: Myrddin's BBS, Myrddin's MUSHcron. So awesome.

74 points by sdegutis 13y ago

> It also attempts to strong type checking, generics, type inference, and other features not present in C. I'm excited already! I always love new alternatives to C.

dmunoz 13y ago
I love programming languages. Big or small, toy or serious. Myrddin looks interesting, and I could certainly see myself implementing projects like this as I dive deeper into language design and implementation. 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.
- mercurial 13y ago
  > If you scroll down further on the linked page, under the section 'Major Features', it start to sound exactly like Rust. Exactly. 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.
  - dmunoz 13y ago
    Yeah, you got me on that one. I shouldn't have used such a strong word. I just wanted to get across that Rust ticked all those boxes (except for "inferred across the whole program" apparently. I just understood that to mean anywhere, but it must have a more technical meaning that I am ignorant of). Good call on Rust's concurrency being a big part of their story.
    - mercurial 13y ago
      > I just understood that to mean anywhere, but it must have a more technical meaning that I am ignorant of) 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).
- ladzoppelin 13y ago
  Do people that write languages also have amazing programming capability? In other words wouldn't writing a new language be harder than writing any piece of software?
  - sdegutis 13y ago
    I'm not sure there's much benefit to looking for that kind of correlation (or even causation). But yes, this guy seems to be way smarter than me and that excites me :)
  - stcredzero 13y ago
    Not really. Such people merely understand a handful of concepts that come from Computer Science and have enough hubris to attempt such a project. Of course, the better attempts tend to come from better programmers. 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.
- ori_b 13y ago
  I'm pretty sure I started out working on this before Rust was widely announced, and certainly before it took it's present shape. It was kind of interesting seeing Rust slowly evolve to where I had was aiming off and/or planned to be as it simplified it's type system, dropped typestate, moved GC into libraries, etc.

evincarofautumn 13y ago

Looks closely related to OCaml and similar in feel to Rust. I’m really excited that so many hobbyist language designers are exploring the space of low-level languages focusing on correctness and performance. (But of course I would.)

greenyoda 13y ago

"Are you tired of your compiler Just Working?" 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. :)

weland 13y ago
That's the first thing that came into my head. Yes, thank you, I WANT a compiler that Just Works. The last thing I want to debug is stuff my compiler throws up when it thinks it's smart. By the way, GCC, in case you're listening? Fuck you!
- exDM69 13y ago
  > That's the first thing that came into my head. Yes, thank you, I WANT a compiler that Just Works. The last thing I want to debug is stuff my compiler throws up when it thinks it's smart. 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.
  - weland 13y ago
    Have you ever had to debug badly-generated code? It was a friendly fuck you, btw.
    - 13y ago

midas007 13y ago

It looks awful, almost as bad as Nimrod.

evincarofautumn 13y ago
Almost. But who cares? It’s a fun hobby project and you aren’t obligated to give it a second thought. And really, most language designs made in earnest are terrible. The important thing is that people get interested in this kind of language, so that we can move on from languages like C++ whose complexity is approaching unjustifiable for new projects.
skrebbel 13y ago
As someone who really likes Nimrod, I'd actually be interested to know why you would say that. But for now, I'll just assume you're a troll.
- mlvljr 13y ago
  No, I am the troll in this thread! Let's listen to him...
- midas007 13y ago
  So how do you justify your name calling then? 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.
exDM69 13y ago
Wtf is wrong with you? Someone shares a project that they have done for fun and enjoyment and you publicly call it "awful" without any explanation. Would you do that to someone in person when they show you something they've done? 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.

moomin 13y ago

It's an interesting space, and not one many have addressed till recently. I think this is a testament to the success of LLVM. For those of you wanting help with pronunciation, "dd" is pronounced like the "th" in "the".

wubbfindel 13y ago
And should sound somewhat like Merlin, since it's the welsh for it. :)
exDM69 13y ago
> I think this is a testament to the success of LLVM. 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.
- ori_b 13y ago
  Yep. I've got some sort of mental problem, and think that writing the backend is half the fun. The frontend is the other half, and library support is the third half. Compiler writing: Now with 150% more fun, and 97% less utility than any other programming project.

TempleOSV2 13y ago

If templeos is not God's official temple, it is nothing. If templeos is God's official temple, it is everything.

NKCSS 13y ago

Found a typo: "A pacakge system"

exDM69 13y ago
While we're at it... if the OP is listening: there's a parallel make build problem, the Makefiles don't resolve dependencies correctly when I run "make -j 3".
- sdegutis 13y ago
  I'm the OP (original poster) but not the author. Which makes me wonder: what's the HN convention for asking the article author something in a comment?
- ori_b 13y ago
  Fixed.
  - exDM69 13y ago
    Great, thanks. I got the compiler built with single threaded make, but it never hurts to have parallel make working properly.
    - ori_b 13y ago
      It was an actual bug even for single threaded builds -- the test/demo program for libstd hadn't declared a dependency on the library. 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.

TempleOSV2 13y ago

With C++, there is a "this" variable. With HolyC, if you use "..." in the arg list you get a "I64 argc" and a "I64 argv[]".

afhof 13y ago

If you were to say "programming languages today are deficient in X, Myrddin fixes that!", what would X be? From the looks of it, it appears to be nothing. The syntax looks palatable and I like the lack of header files. That said, why would I be better off investing the time to learn your new language? (amongst the myriad other languages)

mercurial 13y ago
Assuming that the creator meets his goal to reach C-level performance, C has exactly no item present on the list of Myrddin's major features. If you are programming in a higher-level language, you get performance (again, assuming it's actually fast), and "lightweight" static typing, if you don't have that already. If you're programming in Rust, switching to Myrddin is more debatable (I don't know about D or other languages competing in the same space).
- ori_b 13y ago
  If you're programming in Rust, and you care about things working, you probably want to stay with Rust at this point. 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.
  - mercurial 13y ago
    I think most people got the "experimental, not mature" bit. Kudos for shipping an entire language, especially with the slew of features it has.

lafar6502 13y ago

I like his halloween costume better than the language

saljam 13y ago

I'm personally quite excited about this space. If the Internet of Things is going to happen, we need better languages than C/C++.

Qworg 13y ago
I'm interested in why you believe this to be the case.
- Joister 13y ago
  Possibly because C has too few features for your average programmers liking, and C++ is a nightmarish hellscape of sprawling features which you have to learn and then intentionally ignore if you want others to understand your code. But I like Java, so feel free to ignore me.
  - Qworg 13y ago
    I've written a lot of Java, so no problem there. 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.
- danellis 13y ago
  C++ isn't good for embedded. C isn't as productive as an embedded language could be.
  - Qworg 13y ago
    I agree about C++ on embedded. Why is C not productive? Is it that more modern languages handle more background work for you?
    - sdegutis 13y ago
      For me it's mostly just because I have to do a lot of type-switching or writing pseudo-inheritance when I'm still in the prototyping stage of a program in order to have some kind of polymorphism. It's often not very pleasant.

sdegutis 13y ago

Author: 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.

al2o3cr 13y ago

"The identifiers used for constant values are put in Initialcase. Functions and types are in singleword style, although underscores are occasionally necessary to specify additional information within functions, due to the lack of overloading." Excusemeijustthrewupinmymouthalittle.

ori_b 13y ago
Generics handle most of the places where you'd care about overloading. You don't need a variant of, eg, parseint for every integer size: generic parseint = {some_str -> magic_algorithm(str) } (Actual parseint code: http://git.eigenstate.org/ori/mc.git/tree/libstd/intparse.myr http://git.eigenstate.org/ori/mc.git/tree/libstd/intparse.my...) And, yes, you can make things generic only in the return type, and have that inferred.

coldcode 13y ago

I love that people keep experimenting with new programming languages. I hate that there are so many people experimenting these days I can't examine them all.

colanderman 13y ago

While pleasant-looking, I'm not seeing any "close to the metal" features. C (with its extensions and standard library) has a stronghold in the embedded world because it supports: * 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.

ori_b 13y ago
Patches accepted -- The language is young, and I have certainly not added all the features that I want. For example, generics should be able to provide enough runtime information that I could do something like: pack = std.packbits(some_struct) and get efficiently packed values. 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.
- colanderman 13y ago

ori_b 13y ago

Bowing to popular demand, I also have a github mirror: https://github.com/oridb/mc/ https://github.com/oridb/mc/

robocaptain 13y ago

All I can think of when I read Myrddin is an old set of PennMUSH code: Myrddin's BBS, Myrddin's MUSHcron. So awesome.