I don't know that I would call it conceptually similar to Go. At least, not if we're looking at the Big Pictures concepts, where Go has concurrency as one of its major departures from C. I don't see any mention of concurrency primitives in Cello (maybe they're there and I didn't notice, but I would think the author would have put that on the front page, if it were a thing Cello tried to solve).
Go does provide collections and iterators and such, so Cello is similar on that front. But, every modern language provide those things, and Cello collections don't seem any more Go-like than they seem Python or ObjC like.
Well written C is consistently faster than well-written Go. There are some dynamic runtime elements to Cello that could potentially hurt performance but I doubt it's a major factor.
I think Rust is probably the better modern language to compare Cello to, and I suspect they'll have similar performance. ObjC would also be a reasonable thing to compare.
But, for most things, they're all Fast Enough. Performance is probably not a useful metric. The reason I could see for using this would be modernizing an existing C codebase (though I'd be cautious about relying on something like this until it has a healthy uptake among developers), or when working in environments where only C compilers and libraries are available. If I were starting a new systems project, I would start with Rust or Go (or maybe ObjC if I ever had to work on Mac/iOS).
Mostly though, I think it's just a cool experiment, and educational.
I would assume one of the cello creators / advocates is down voting my posts so I'm bowing out of this thread. I asked a real question that clearly upset people for some reason.
I downvoted your "+1" and "TY" comments because they add nothing to the discussion -- just upvote instead of leaving such comments, this isn't Reddit (yet). Complaining about downvotes is also a good way to get more downvotes. Your original comment was probably downvoted since it's not very constructive either, it's just a random thought that entered your head (it's not a terrible thought, performance is something to be considered if you're seriously going to look over the pragmatics of using a random language), and it didn't really deserve to be a comment. A better comment that would have received upvotes would have been to run your own benchmarks and report the result instead of pointlessly wondering in public. (Or as the question can come across, demanding someone to do the benchmarking for you as presumably you searched for one before making such a demand.)
Which, I think, misses the point. Unless your Go program is currently not fast enough, why would you consider a port? And, if it isn't fast enough, are you sure you are using the appropriate algorithms and tools for the job? It may be that Go isn't the right language, but I would think long and hard before a re-write from any language to any language, unless it's a toy project (in size, not importance), in which case, you could rewrite it and find out in a day or two and it might be a fun experiment worth writing about.
And, lots of benchmarks between C and Go have already been done. Likewise, Rust and Go, and Rust and C.
I agree with your comments 100%. Not sure why my comment got down voted but I would just like to see some benchmarks... Rust would be another interesting benchmark.
