> So, if we attempt to create a Frankenstein language that combine concepts of bash and C, which set of programmers do we inconvenience with the noisier syntax?

> So, if we attempt to create a Frankenstein language that combine concepts of bash and C, which set of programmers do we inconvenience with the noisier syntax? I won't speak for others, but I can make that choice for myself, and I'm willing to give the C-like language the upper hand. If bash like things were high enough priority, I might change the name "system" to "run" so it was just a bit more concise, perhaps taking multi-line strings to tidy it all up. I'm not saying one language to rule them all, I'm just saying I could have one language for nearly everything I've done or want to do. What I was talking about was more like what features does the language have. For instance, I like algebraic data types (sum/product types). I like generics/templates. I want an "any" (variant) type. I want complex numbers and matrices. I like operator overloading so I can implement new arithmetic types. I want simple and immutable strings. I want structs and unions. I want SIMD types. I could also list things I don't want. Anyways, I could go on, but all of those fit in a single efficient and expressive language. Some current languages come close, but get important details wrong. > I also don't see how one language can offer both garbage-collected memory and manual allocated memory using convenient concise syntax _and_ and zero-cost runtime performance-penalty for manual memory. Those two goals contradict each other. There are a lot of details that matter, and I can already anticipate some of your objections, but I would be very happy with automatic reference counting on a type system which precludes reference cycles. I would not use atomic increments or decrements (which is one of the more costly aspects of reference counting), and I would not let threads share data directly. This provides deterministic memory management and performance not too short of what you get in C, C++, or Rust. So not "zero-cost", but damned close. It's also simple enough to think about the implementation so you can easily keep the non-zero-cost parts out of the inner loops. Of course someone else would disagree and say they can't accept this (minor) compromise. Ousterhout had a famous quote about needing both a high and low level language. For him, that was Tcl and C. I think I could have everything I need/want for high and low level tasks in a single elegant language. You're not alone in disagreeing :-)