Emu: Language for Programming GPUs in Rust
github.com
github.com
1. What exact syntactic differences does this have from rust, and why?
Some differences I see are in function definitions: lack of `fn` keyword, `->` for function return type, and colons for parameter types.
2. How does this make use of the borrow-checker, if at all?
3. Who is the target audience? Is it meant for general mathematical acceleration or graphics?
It seems to be meant for scientific purposes, seeing as it provides a system of units and constants.
This is just a procedural macro that parses "Rust-like" syntax into an AST, and then 1:1 fold that AST into OpenCL. This AST is not type checked, and if you were to, for example, replace the usage of an `u32` in there with a `type U32 = u32;` then parsing will probably fail, because the proc macro doesn't know what `U32` means.
The OpenCL code that gets dumped into a byte string, is compiled at run-time by your graphics driver. The proc macro can probably, at best, try to verify that it is correct at compile-time, by passing the dump to some OpenCL verification tool, but it does not appear to be doing that right now.
I didn't say that upwork is skewing it intentionally, I'm saying that the samples aren't representative of the larger population.
I follow a few job agents because I do part time work as an examiner for applied CS students, and I occasionally advice on what languages they should teach to make sure their students are job ready, and nothing has really changed for a decade. Python demand is really the only area that has seen a real increase, but not for developers as you need some sort of degree in either statistics or math to get the ML/BI jobs.
It’s always a little sad to see students who spend a lot of time buying into the hype and building their final projects in something like Rust or Go and before that node/express. Because they’ll have a much harder time finding a job than the ones who didn’t do that. Not because learning Rust is bad, but because it’s safer (and cheaper) to chose their competition and it’s not like there is really a lack of freshly educated developers anymore.
The in Rust in the title therefore catches my eye because it could solve some of my problems, depending on how it is implemented.
Sure, Rust is not going to replace Java anytime soon (probably not at all). But for a language that has seen its first stable release only four years ago [1], Rust is a wildly successful systems programming language.
[1] Before Rust 1.0, Rust was not really usable in production due to very frequent changes to the language.
I'd say given Rust's age it's popular, and since it is the first contender for a lot of spaces where no other languages have made a serious bid in a while (embedded and real-time systems with higher safety guarantees haven't seen much love since ADA).
It will probably not supplant easy super popular languages like python. But I believe it might find it's niche. A lot of other languages don't have such a USP.
Yea, I definitely don't think it'll ever be as hugely mainstream as "easy" languages - take Go for instance, but it has huge potential and I'm a big fan of the language (I've switched entirely to it).
It may be possible that another language can come up with a more elegant solution for the memory safety features of Rust, but until that happens I think Rust will gain a lot of ground. It just won't be the language people turn to unless they have a use case explicitly for Rust (or rather, something that disqualifies Go/Python/etc to them).
"CppCon 2017: Olivier Giroux Designing (New) C++ Hardware"