4 ms·

> Performance is not a priority. I like your outlines so far. It is very interesting -- even if it probably will fail eventually. I am only concerned with thi

> Performance is not a priority. I like your outlines so far. It is very interesting -- even if it probably will fail eventually. I am only concerned with this quoted guideline. Performance should always be a priority. Your other guidelines -- keeping the translation simple and transparent -- already put a constraint on the aesthetic. You can't allure users by hiding complexity beneath something. So if you also don't promise users performance, what good is your language to a user (unless he is a poet)? I feel that you are adding this guideline only because you are thinking about taking the dynamic approach to memory safety rather than the Rust approach. That is fine as long as either approach is only an add-on rather than the permanent infrastructure of your language. If they are, then I am afraid your language will just reduce back to one of the language that is hardly worth to checkout. My suggestion is always to put performance as your priority. Always start with solutions that performs, then work on enhancing your language to express the same solution easier.

akkartik 7y ago
You seem to be assuming everybody in the world always wants the same things, which is demonstrably false. There were excited communities of people using Lisp in 1962 and Java in 1997. Both were significantly slower than mainstream platforms of the time. There are many platforms today that provide performance, and people who need performance will use them. I can't compete with them. Mu is for people who don't need performance quite so badly, and who are willing to trade performance for other benefits. Also, the word "priority" means relative importance. Too many priorities are equivalent to no priorities. Performance not being a priority just means other aspects are more important, not that performance will be glacial. Indeed, a lot of performance stems from doing less, and I fully expect fewer layers of abstraction to keep Mu quite competitive for many tasks. But that will happen naturally without me needing to push on it.

akkartik 7y ago

You seem to be assuming everybody in the world always wants the same things, which is demonstrably false. There were excited communities of people using Lisp in 1962 and Java in 1997. Both were significantly slower than mainstream platforms of the time. There are many platforms today that provide performance, and people who need performance will use them. I can't compete with them. Mu is for people who don't need performance quite so badly, and who are willing to trade performance for other benefits. Also, the word "priority" means relative importance. Too many priorities are equivalent to no priorities. Performance not being a priority just means other aspects are more important, not that performance will be glacial. Indeed, a lot of performance stems from doing less, and I fully expect fewer layers of abstraction to keep Mu quite competitive for many tasks. But that will happen naturally without me needing to push on it.