Hacker News new | past | comments | ask | show | jobs | submit login

Thanks for the good counterpoints. Some thoughts:

- When you say "materially different," how different are we talking? I'll admit that if you want to implement Haskell (or anything with HKT) that it's a long shot, but if you want to implement Javascript, it shouldn't be that hard, yes?

- Can you give an example of when you need type info to link?

- RE: debug info and error messages, do you disagree with what's written in the post? I agree this is an issue, but it doesn't seem unsolvable.

Generally, I guess I don't see how most languages have semantics terribly different from Rust. You don't need unsafe pointers for shared mutability with a single thread because you can use a RefCell (see: my language linked in the post). In my experience, most type systems for general-purpose languages have roughly the same feature set as Rust.

I buy that implementing a language completely different from Rust in semantics/types makes Rust not a good target, but for most languages we use nowadays, isn't that not the case?

You need type info, if the language has its own type system which has more information than Rust.

Imagine you have machine code generated by compiling a C program and now want to figure out what struct some function takes as an argument.

As you go down towards machine code you lose information that you cannot easily recover.

Solving all of these issues is also only practical, if the Rust developers themselves cooperate. It seems to me the very purpose of creating a new language, is in freeing yourself of the limits existing ones have. Building a new language on technology that are restrictive doesn't really make sense from that perspective.

Some answers:

- The type system I'm thinking of includes effect inference from Koka (http://www.rise4fun.com/koka/tutorial), is simpler in other places, and has full type inference even of function signatures.

- An example of type info to link is effects. I could do things like serializing my type structures into Rust method names and then decoding them, but that's pretty hacky.

- Error reporting isn't just mapping, it's the messages too. I don't want my language getting error messages like "modification of an immutable borrow" or "cannot pass an Rc<RefCell<MyLangInt>> to a function that takes an Rc<RefCell<Vec<MyLangInt>>" when it doesn't look like that or have those constructs.

- RefCell has runtime overhead where every other compiled language doesn't.

- I think the type systems of most statically typed languages are substantially different from Rust that it would be an impedance mismatch.

I think this is only remotely better for dynamically typed languages, since that also solves a lot of the issues with errors since those are mostly created by your runtime functions.

How will you implement exceptions?

catch_unwind, probably? Its not supposed to be used for exceptions and if you try to use it for them there are some barriers in the way. But these are not fundamental barriers and can be solved through codegen, which is how the language is planning to work anyway.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact