dalailambda

If you want minimal you could always use something like glfast https://github.com/procedural/glFast

How do you find the cgo overhead? Specifically with something like OpenGL, it seems like it would be a big pain point for rendering.

In my experience Glide is the closest to a modern package manager for Go.

For an example of a language written in Go(besides Go), there's always https://github.com/ark-lang/ark

In line with your JSON bullet point, I think this project should adopt a smaller/binary data transfer format. Having something that's human readable isn't of that much value in this case, where maximising speed seems to be the goal.

It could make sense if they want developers to start creating Linux focused apps, and then over time deprecate the win32 parts.

While it's important to not overload C with features, not adding features to it because C++ already has it isn't very practical.

While some might claim this goes against the spirit of C, I think minor support for generics(enough to implement a type safe dynamic array e.g. vector) would be really useful. And if this did monomorphisation, then performance would still be great.

From a glance what makes this appealing to me is the fact that there's less magic than with Meteor, which means I can use my own build process, and I can use any compile to js language.

While I understand the argument the author is making, I think it's important to consider that while a mild focus on performance could only benefit your code a little, applied across your entire stack, the performance benefits start to add up, and become worthwhile.

On the other hand, how many languages use libraries that are written in C? Especially in the higher level scripting language ecosystems(JS, Python, Lua) a lot of libraries interface with C/C++ libraries. If instead they used Rust, would that not result in a gain for those languages(even if there was a small C wrapper around it)?

I feel like this is a bad argument to be making. If a language's "level of suck" were based on its ability to write operating systems, then the massive boost in programmer productivity we see today from languages which sought to depart from that domain wouldn't exist. Tangential to that, I consider Rust a "fun" language compared to C++, and it is definitely capable of doing anything C++ can do[1].

By the way, Midori[2] was written in C#. Granted it had its own AOT compiler and started to diverge into a different language, but nevertheless, it was C#. I'd suggest looking through Joe Duffy's blog posts[3] as he explains it better than I could.

[1] https://github.com/redox-os/redox [2] https://en.wikipedia.org/wiki/Midori_(operating_system) [3] http://joeduffyblog.com/2015/12/19/safe-native-code/

In a way it's verbose, but less so on a syntax level. There's no need to deal with interfaces, classes, or exceptions. The boilerplate code you write tends to serve a practical purpose, as opposed to a syntactical one. Sure you have to deal with a lot of error handling and memory management yourself, but the language doesn't get in your way or create much friction.

The thing I like C for is the simplicity. Writing C after working in a very verbose language for a while is refreshing. That said, my few wishes for a C replacement would be generics, methods, and namespacing. The last two are to avoid funky naming schemes everywhere. Maintaining the proper low level control and simplicity would be a top priority though.

Overall this project looks interesting. I'm interested to see where it goes in the future and what design trade offs end up being implemented.

I can see this being useful in combination with Piston[1] to achieve scripting for game engines, in the same way Lua is normally used. Rust as a core for a game engine seems like a really great idea, considering the speed and safety benefits it provides.

[1] https://github.com/PistonDevelopers/piston