Jay Taylor's notes

back to listing index

Which language has the brightest future in replacement of C between D, Go and Rust? And Why? • /r/rust

[web search]
Original source (www.reddit.com)
Tags: programming-languages www.reddit.com
Clipped on: 2016-02-28

this post was submitted on 09 Nov 2015
82 points (88% upvoted)
shortlink:
subscribe14,507 Rustaceans

~48 users here now

Set your user flairShow my flair on this subreddit. It looks like:Show my flair on this subreddit

The Rust Programming Language

A place for all things related to the Rust programming language, an open-source systems programming language that emphasizes zero-overhead memory safety, fearless concurrency, and blazing speed.

Rules

+ Respect our Code of Conduct.

  • We strive to treat others with respect, patience, kindness, and empathy.

+ Constructive comments only.

  • Criticism is encouraged, but ensure that your criticism is constructive and actionable. Throwaway comments are just noise.

+ No memes.

  • Leave the image macros at home. This applies to comments, as well as top level posts.

+ No zealotry.

  • When discussing other programming languages, maintain civility and respectfulness.

+ Chill out!

  • A programming language is a pretty silly thing to get upset over.

+ Quadruple Parallel Universes?

Resources

+ Learn

+ Install

+ Discuss

+ Contribute

created by azth

82
Only for content that does not contribute to the discussion.

Which language has the brightest future in replacement of C between D, Go and Rust? And Why? (quora.com)

all 134 comments
sorted by:
best

[–]loamfarer 39 points 3 months ago 

This was an enjoyable read and I always enjoy Andrei's candor. I think I gleaned more knowledge on D here than the others, but that was to be expected.

I really see Go as being out of this race. It seems to encroach more on Ruby, Python and Java than the system languages. But even then it's not my cup of tea. Do people no longer talk about Nim? I feel it's prospects are much greater in this realm. It seems to be coming along nicely and their resources seem to be well put together. Nim certainly has some advantages of compiling to C.

The prospects of D giving you powerful zero cost abstractions, and powerful generics whilst at the time offering first class C ffi and capable as serving as a scripting languages where memory management is shoved out of sight! That is a tantalizing pitch. I feel I have a much less clear insight into the community and learning resources than rust, which has been a huge help in getting me in the door. This might just be me not looking hard enough. At any case I'd like to give it a try.

As for Rust, I've chosen to pick it up really because I've enjoyed C more than any other language. But dread debugging aliasing, use after free, and other race conditions. I really do like to think about memory management, and I really do want to be babysat by the compiler. My favorite thing about Rust though is its type system. For whatever reason I dread the C++ and Java style OO. Templates, interfaces, inheritance. Then composing all that. Ugh. Rust to me actually feels more like giving C an ML-like type system than anything. The nice thing about Rust right now, is that it's getting some serious industry upswing, with success. I know a lot of people want generics and higher kinded types. Hopefully those hit at some point. Even with perhaps the lengthy development cycles of rust. The final results of both safety and concurrency are justifying the upfront budget. The thing I always find myself wondering about the future of rust in being used in real-time infrastructure systems, or massive scientific institutions like Nasa and Cern and other areas of precision research. Both for fault free controllers, or for accurate simulations.

[–]steveklabnik1rust 14 points 3 months ago 

I know a lot of people want generics

We do have generics, did you mean integer-level generics, maybe?

[–]iopqfizzbuzz 17 points 3 months ago 

We want generic generics so you can code generics while you code generics.

[–]Sinistersnarerust 16 points 3 months ago 

So Higher Kinded Polymorphism?

[–]iopqfizzbuzz 13 points 3 months ago 

Yes, I'm still waiting for Rust to be able to express Monad in a satisfactory way. Then maybe we can even have do notation so people like me can stop whining about how Rust is so verbose in its error handling.

[–]Ruud-v-Arust 4 points 3 months ago 

Perhaps one of the reasons that Rust is so verbose (I don’t share that opinion though) is that Rust forces you to do error handling at all.

[–]saposcat 2 points 3 months ago 

Absolutely not. The jury is still out on whether monads are the right abstraction. See: Algebraic Effects and Handlers, and compare those to monad transformers. I think adding another trait to the compiler's list of traits it knows about is a bad idea.

Also, I think with respect to monads, there might be a potential for novel ways of compiling monadic computation because in Haskell, monads are usually encoded as value transformations, whereas in Rust we have a region tracking system that might be extendable to things other than lifetimes. In C it is common to chain computations but check error flags before continuing. In Haskell you pass optional types. What if you could write the Haskell version but it compiled to the C version?

[–]iopqfizzbuzz 1 point 3 months ago 

Monad should be added as normal higher kinded trait, not specially encoded into the compiler.

[–]saposcat 1 point 3 months ago 

But do syntax would have to be encoded into the compiler.

[–]iopqfizzbuzz 1 point 3 months ago 

Or maybe it would just be a do! macro, I haven't really tried to design it

[–]SteveMcQwark 1 point 3 months ago 

Higher-ranked polymorphism is about more than just monads. A concrete example of something I'd like to see that it would enable is generic owning references. What that means is to be able to encapsulate the ownership a value inside an object which provides access to an arbitrary borrow into it. So an owning reference could own a vector and provide access to an arbitrary slice of it, or to a reference to an arbitrary element of it. You could then move the owning reference around just like a vector and know that the slice it provides access to remains valid.

The challenge with doing this is that you don't want to be limited to a particular type of reference. The owning reference library is artificially limited because it requires you to use shared references (i.e. &T) for the reference part of the owning reference, which rules out interesting patterns like using mutex or RefCell guards, for example, or even &mut references.

[–]staticassert 0 points 3 months ago 

There's a crate for that.

Mobile so I can't find it for you right now.

[–]loamfarer 6 points 3 months ago 

Yeah. I was typing colloquially.

[–]mekanikal_keyboard 19 points 3 months ago 

Go is definitely "out of the race" to replace C....but it is definitely in the race to replace Java and easily has 10x the number of active coders and job prospects as the rest of the tools Andreri discusses.

[–]Manishearthrust · servo · clippy 8 points 3 months ago 

Also Python, really. One of Go's main selling points, the simplicity and ease of use (low start up time, etc) is shared with Python and Go arguably does that better. Python has a lot of other features which keep it going (which Go doesn't have), so Go probably won't replace Python, but it may get some of the mindshare.

In fact, when I look at Go, I think less "Java" and more "Python"/"Ruby"

[–]loamfarer 0 points 3 months ago* 

I will say, PyPy is looking really neat. I think it in conjunction with a general shift towards Python 3 (finally!) will keep python in the running for quite some time to come. Additionally we have Julia, which maintains interoperability with both Python and C/C++ world. Of course that means D/Rust come along for the ride too.

I don't see Go taking away all of Python's domain. More than anything I see it moving on Ruby and backend web Java domains. Of course Java is leaking to Scala as well. Application Java is already losing to open C# via mono. So I think Go has a lot of opportunity to pick up some of the market that Java loses.

[–]Manishearthrust · servo · clippy 4 points 3 months ago 

Additionally we have Julia, which maintains interoperability with both Python and C/C++ world.

what what WHAT WHAT WHAT

Why haven't I heard about this?

I'm a Mathematica/Python/Rust person for scicomp, but now I've got to try Julia.

I don't see Go taking away all of Python's domain

Not all, but most.

I consider Ruby and Python to be in similar spaces, really :)

[–]steveklabnik1rust 5 points 3 months ago 

Julia is really great, you should check it out for sure. Graydon wrote a blog post about it http://graydon2.dreamwidth.org/189377.html

[–]pjmlp 9 points 3 months ago 

First is has to offer generics, a proper debugger (not one that rewrites text), REPL, battle proven SQL DB drivers, monitoring tools like VisualVM and Mission Control, IoT like support, ...

[–]silent-hippo 10 points 3 months ago 

The only way Go has any chance to replace Java is if Oracle pulls some stupid greedy move that chases off Java devs. Right now Java is a more powerful language (more features), as fast or faster than Go, has better tooling, and has 10x the already trained devs who will be annoyed by a lack of generics.

[–]lapingvino 9 points 3 months ago 

That's one of the few things you can trust Oracle on though, they did that already about OpenOffice/LibreOffice.

[–]silent-hippo 6 points 3 months ago 

I certainly don't put it outside the realm of possibility that Oracle destroys Java :). I was a Java fanboy until that deal went down and then I decided it probably wasn't worthwhile to swear my loyalty to a language because who knows what's going to happen to it.

[–]llogiqclippy · rust 4 points 3 months ago 

We all know how this turned out. OpenOffice is now an Apache project and LibreOffice 5.0 is just great. If that's the future to befall Java, as a Java developer I welcome any greedy move by Oracle. Cannot wait to get my hands on LibreJava 10.0 :-D

[–]lapingvino 3 points 3 months ago 

The problem is though that they stick to their trademark on this one, so it won't be called Java. As Google uses Java for Android, either way we would be hearing from Google in this case, either with better Go support for Android or better support for OpenJDK etc...

[–]fgilcherrust-community 9 points 3 months ago 

Do people no longer talk about Nim? I feel it's prospects are much greater in this realm. It seems to be coming along nicely and their resources seem to be well put together. Nim certainly has some advantages of compiling to C.

I can tell you that: Nim is bad at getting the word out. Technology doesn't win by being better, it wins by being explained to be better. And you need a lot of people that do not get bored of doing that a thousand times, at a really simple level.

[–]MrJohz[🍰] 1 point 3 months ago 

Look at it another way: Rust is backed by Mozilla, and D for a long time had an association with Facebook. Nim doesn't have any big names behind it, and in many ways is still Araq's personal project.

I like Nim, but it needs a backer or big name behind it if it's going to have any chance at succeeding, at least now the market is so saturated.

[–]Manishearthrust · servo · clippy 7 points 3 months ago 

I think another part of this is that the Rust community managed to attract respected people from other, non-C++ fields. Steve from Ruby, Armin/Georg from Python (pocoo), and lots of other known community members. This leads to Rust being mentioned at their conferences, or even being the subject of whole talks. And, of course, blog posts and tweets. Creates a wider community, and a wider net gets cast. I don't think the effect of having these people around has been appreciated enough :)

Go has some of this, but not as much. D and Nim don't seem to have this at all (could be just me not knowing about it, though).

[–]meteorMatador 1 point 3 months ago 

To my knowledge, that's exactly the role Andrei Alexandrescu (ie. the author of OP's link) plays in the D community, having been persuaded to renounce C++.

[–]fgilcherrust-community 10 points 3 months ago 

I consciously did not choose that way, because it is dismissive to those people that actually grow the language community. This is rarely done by corporations. It helps as a start, but this is it. I know at least as many cases where company affiliation is actually a hindrance to community growing.

Many of the community projects this year happened without Mozilla support and Mozilla is also not set up for managing Rust in the way it manages Firefox. Grassroots movements are much more agile and quick. I want to run OpenCodeTown? I just do. Mozilla will take at least half a year of ramp-up until they decided whether they will a) push Rust, b) on that event.

You don't need big names. Ruby, Python and Perl made it without. God, was Ruby in a shitty state when people picked it up. You can grow your own big names.

Failure to attract people that want to do that work and are glad to do that is a defect in the language ecosystem that cannot be fixed by cash pools.

[–]lurgi 1 point 3 months ago 

There are a few important languages that gained traction without a big name behind them - I'm thinking of PHP, Perl, and Python. I wonder if it's significant that these are generally (?) viewed as scripting or glue languages rather than application languages?

[–]desiringmachines 21 points 3 months ago 

This was a great post for revealing my biases to me, because I read through the D and Go sections thinking it was really insightful, informative, and on point, and then I got to the criticisms of Rust and recoiled.

[–]Manishearthrust · servo · clippy 35 points 3 months ago 

While I respect Andrei's opinion a lot, he's evoked the image of a "large borrow checker muscle" in Rust multiple times. I think that's not really an accurate description.

I find that the borrow checker, while one of the most advertised parts of Rust, is not the one place Rust spends all its design budget. Certainly the one place Rust does something almost completely new (instead of mixing up random language features from other languages), but D and Go don't have any of that so that's not really on the table anyway. And, in fact, parts of the safety architecture (affine types) is as useful for unrelated things as it is for memory safety. Affine types let you think about data in a very intuitive way. Something I miss tons in C++. But memory safety aside, Rust has plenty of awesome features (exhaustive-matched enums! awesome closures! cool iterators! zero-cost abstractions! tools to build your own! monadic errors! post-parser macros! traits!) which are key features in the language over others (though these have all been borrowed from other languages).

[–]staticassert 19 points 3 months ago 

Agree entirely. The borrow checker is something that keeps my code clean, and I love it, but it's invisible to me at this point. What really keeps the language so interesting for me, and what makes me enjoy writing it so much, goes far beyond the borrow checker (though the existence of the borrow checker is sometimes what allows for the cool features).

[–]flying-sheep 7 points 3 months ago 

The ownership model also helps with concurrency right?

[–]Manishearthrust · servo · clippy 4 points 3 months ago 

I sort of stuffed that into "borrow checker" to give Andrei the benefit of doubt that he was talking about "safety" (not just borrowck). But yeah, if you consider that separate, sure.

[–]burntsushirust 28 points 3 months ago 

The realities of 1.0 ended that honeymoon and marked (by my measurements and estimates) a stark decrease in general interest

Anyone else feel that way? If anything, seems like the opposite to me! Of course, I may be a touch biased...

[–]annodominirust 42 points 3 months ago 

Well, I think that the 1.0 hype bubble was a real thing.

For those of us that have been following rust both before and after the 1.0 hype bubble, there's definitely been a marked uptick in interest, in size and quality of the Rust ecosystem, and so on, compared to, say, a year ago.

But the hype bubble was a real thing, so for people on the outside, who may have heard most about Rust during that time, it might appear that interest has dropped off sharply since then.

So, I think that in the long term, Rust is doing great at getting out the word, attracting new contributors, and building up an ecosystem. And the post-1.0 stability (libc issues aside) has been a big boon to that. But in the short-term, if you look at peak hype to now, it looks like everyone stopped being interested in Rust after 1.0 was released.

[–]jfagerrust 8 points 3 months ago 

Part of the excitement of Rust pre-1.0 came from the willingness to relentlessly iterate on design decisions to find what worked. There were a lot of frustrations that came along w/ that, and it was a huge barrier to general adoption, but there was an energy to the project unlike any other that I've followed.

That specific energy has dissipated a bit, and I think the energy that comes from a large community actually building lots of cool things hasn't quite arrived yet. Don't get me wrong, there are definitely very cool projects being written in Rust. But its not yet the cambrian explosion you see over in go-land.

The work being put into Rust and the ecosystem right now is the work that bridges the gap - faster compiler, better tools, foundational libraries, headliner projects (servo, redox), documentation - but it's not as exciting to the casual observer as what came before and what's going to come later.

[–]steveklabnik1rust 11 points 3 months ago 

I think there's a lot of people who just also aren't talking, they're shipping. It seems like every other day I hear about another company using Rust in some small capacity, but they're just not publicizing it yet.

For example, I know of a really important consultancy company that uses Rust to deploy their main website, they just haven't talked about it at all yet.

[–]jfagerrust 2 points 3 months ago* 

Sure, that's really what I was trying to say. The next booster rocket fires off once these companies start publicizing/hiring or we see releases of open source projects that a bunch of people start using.

Same thing happened w/ Go - an initial rush of excitement that Google was doing a language, a period of time where the chattering classes wondered if anything was going to come of it while a bunch of real work got done in the background, then suddenly everyone seemed to be using it and we got Docker, Influx, Kubernetes, Prometheus, Cockroach, etcd, consul, etc, etc.

[–]burntsushirust 3 points 3 months ago 

I just haven't observed a "stark decrease in general interest." That's all i was disagreeing with.

[–]sanxiynrust · servo 4 points 3 months ago 

I think post-1.0 "decrease in increase of general interest" compared to pre-1.0 is real. On the other hand, I agree that it is best described as "slowdown", not "decrease".

[–]jfagerrust 1 point 3 months ago 

I'm thinking of 'general interest' as meaning HN or proggit discussion, and that does seem to have dropped off quite a bit from 1.0 peaks. But I completely agree there's more actual adoption, more code being written, more libraries coming on line or companies starting to use it, etc. The latter is more important, and the former will go back up once that work becomes more prominent.

[–]Manishearthrust · servo · clippy 9 points 3 months ago 

It might just be because I'm a part of the community team and got to hear Real World Rust stories from people a few months after that, but it felt like the opposite. There was definite 1.0 hype in that month, but not some drawn out honeymoon.

[–]hotdaaaamn 5 points 3 months ago 

You and I are on IRC a lot of the time and one thing I've noticed here is every day we're seeing a brand new complete projects or rfc's for crates with more and more complex functionality right away. I think we're on the edge of a major boost in numbers as some of the basic tooling comes together. Developers love tools, I feel like things have increased in pace as far as productivity goes. When comparing systems level languages I'd say with extreme bias that we've got the most hype and the most potential to be future proofed. The communities questions have moved from what is lifetimes to implementation concepts in ~6months, we've got a solid tool and the support for newcomers is growing exponentially.

[–]ethelward 9 points 3 months ago 

The opposite for me, 1.0 was the moment I began to really use Rust on serious projects.

[–]robertmeta 2 points 3 months ago 

Anyone else feel that way? If anything, seems like the opposite to me! Of course, I may be a touch biased...

All of this is my personal experience, yada, yada.

From a community perspective, I felt a small drop-off in energy / excitement, but not too much. Basically, people who hoped Rust would be a magic bullet at 1.0 tried it and said "guess not" and moved on, but this was more than offset by new libraries and tools being built on 1.x.

From a professional perspective, there was a tremendous drop in interest (to basically zero). Haven't had a single discussion with a client about Rust since the 1.0 release -- I had LOTS of discussions about it prior (prepping for 1.0). I think 1.0 didn't deliver on (unrealistic) expectations for lots of shops and has fallen off their radar entirely. Now I mostly get questions about if people should be investing in Elixir and/or Swift as the "next thing". Go has already reached a point of boring acceptance in a lot of shops, like JS, Java and Python.

[–]TheHillwoodMonkey 5 points 3 months ago 

The opposite for me too, because my issues were lack of tooling, libraries and stability. From that perspective, the period following 1.0 has been the most exciting time.

[–]fgilcherrust-community 0 points 3 months ago 

(also being part of the Rust core team)

Well, there was a 1.0 hype certainly, but I don't think it has turned Rust into anything less of a "community darling". We managed one thing well: selling 1.0 as a "playtime is over, you can now seriously use this" event. A lot of people took it as a point to pick up Rust and to really consider it.

I really like the text, but one thing I'm missing from him is a clear grasp of social dynamics. While I like his nod towards "PR", and some waving at "solid marketing", he's missing a crucial point: of all those communities, we do have a formal and effective structure for that!

[–]Manishearthrust · servo · clippy 3 points 3 months ago 

(s/core/community, core team is different) :)

[–]hotdaaaamn 15 points 3 months ago* 

10x better safety than other systems programming languages. Of course that had to be here, we just discussed the cost of that.

I think for future proofing systems when codebases get to be 19million odd lines long more than makes up the cost for this, and is why I think Rust is/soon will be the main player when it comes to replacing low level C code. What a great read.

10x better than any other system language at generic and generative programming. D's static introspection, compile-time evaluation, and mixin-driven code generation combine to a powerful cocktail that is very difficult to mix right in other languages

Cool, I want to hear more about that.

[–]Manishearthrust · servo · clippy 10 points 3 months ago 

I've heard a lot of awesome stuff about D's metaprogramming. I haven't yet looked deeply into it, but the precursory looks I've given it in the past have been promising. You should read about it.

[–]jeremiahs_bullfrog 11 points 3 months ago 

I built a JSON parser that used static reflection to generate a parsing function that efficiently constructed a class object and populated it with values from the JSON. All this took a few hours and I ended up with a very fast JSON parser.

D's templates coupled with CTFE and static reflection are revolutionary. I came from Go with runtime reflection and found that I really didn't miss anything, and the end result was much faster.

I would really like to see Rust go more this direction (I know it has some support ala the serialization library), but it has a ways to go before it rivals D's expressiveness and powerful simplicity (someone even made a ray tracer with CTFE!).

[–]Manishearthrust · servo · clippy 5 points 3 months ago 

FWIW Rust can do everything D can do at compile time in a plugin, just that plugins aren't ergonomic.

(That's how the serialization libs work, for example)

[–]jeremiahs_bullfrog 7 points 3 months ago 

My point was that I just stepped into D and built something fast, and it was fun. I'm still wrapping my head around compiler plugins in Rust, but it's just not the same experience.

Go doesn't have this at all, so you have to do runtime reflection.

[–]Manishearthrust · servo · clippy 10 points 3 months ago 

I know, and I agree, D's system is awesome and useful :)

Just leaving a side note.

[–]bjzabarust · cgmath · gl-rs 4 points 3 months ago 

Rust can do everything D can do at compile time in a plugin

You don't have access to types though, which makes things less ergonomic - no need to constantly pass around the types. And D's metaprogramming feels like working in the same language - syntax extensions fell like working in a poorer sub-language.

I love D's metaprogramming, and feel like lots of Rust folks could learn something from its ergonomics. It's not something that would get me to switch back though, but it is certainly something that Rust lags behind on.

[–]Sean1708 0 points 3 months ago 

Doesn't D have typed macros, or am I just making that up?

[–]bjzabarust · cgmath · gl-rs 3 points 3 months ago 

D's templates do similar code generation, but you have access to the types as well.

[–]krappie 17 points 3 months ago 

When it comes to replacing C, garbage collection seems to be the major dividing factor. Sometimes garbage collection just isn't appropriate for the low level high performance problems you want to solve. Go and D are out. Rust seems to be the only new language that has the ability to replace C.

[–]MrMarthog 19 points 3 months ago 

D 's problem is the library. The core language was developed in a way that combines the speed and determinism of RAII with the ergonomic usage of a garbage collector. It was designed to do everything that is possible with C++.

Unfortunately the standard library was developed unter the asumption that there is always a garbage collector, making it a de facto gc'ed language. If D had a library similar to C++'s or rust's, it would be an adequate replacement.

[–]matthieum 6 points 3 months ago 

If I remember correctly, Andrei explicitly left Facebook to focus on getting the GC out of D's Standard Library. I think it's a space worth watching.

[–]fullouterjoin 2 points 3 months ago 

I am on the lookout (and welcoming) getting a GC into Rust.

[–]pjmlp 4 points 3 months ago 

When it comes to replacing C, garbage collection seems to be the major dividing factor.

Mesa/Cedar at Xerox PARC, Modula-3 at Olivetti/DEC, Oberon at ETHZ, Singularity at MSR are experiments that proved it can be done, but without a major push from mainstream OS vendors it will never happen.

This is why I see quite valuable that Apple with Swift/Objective-C, Microsoft with their C++ work/.NET and Google with Android (even though I dislike how they deal with the NDK) push both RC and GC into the developers.

Also why I see as positive vendors like IS2T, pushing for hybrid Java/C solutions with MicroEJ. Eventually less C code gets written and moved into the safer layers.

[–][deleted] 3 points 3 months ago 

I agree. As someone who enjoys microcontrollers I often programme for systems with kilobytes of RAM and no OS. In C, I can write a programme that's completely statically allocated, meaning everything lives on the stack, which I think is really a requirement for some systems. I know Rust can do this too, but I don't think Go or D can.

Also, GC pauses for state-of-the-art systems are still measured in miliseconds AFAIK. Doesn't really work if I need to fill an output buffer several times during that period...

[–]atilaneves 9 points 3 months ago 

You can do that in D. The only problem is avoiding the language features / standard library functions that can allocate on the GC heap. But for that, slap a @nogc on your main function and you're guaranteed not to. While you may end up writing in a subset of D, that subset has a lot more features than C does.

[–]pjmlp 2 points 3 months ago 

Have you ever used the systems from Atego?

They have some white papers about their real time JVMs being used to control missile tracking systems.

But real-time Java allows for memory regions and better GC control than the desktop version.

[–]FlyingPiranhas 0 points 3 months ago 

I haven't heard of the RTSJ being used for any actual applications before. Are they able to get sub-millisecond upper bounds on execution time, or do their systems have longer (or less strict) deadlines?

How do they handle errors if an allocation fails?

[–]pjmlp 0 points 3 months ago 

I guess you need those kind of deadlines if you are tracking something like missiles and navy battle systems.

http://www.nfvessentials.com/news/2010/03/30/4700207.htm

http://defenseelectronicsmag.com/news/aonix-supports-french-radar-systems

[–]FlyingPiranhas 0 points 3 months ago 

Thanks for the links. They don't provide much technical details -- I wonder if they only use Java for the interface, or if they actually do something with tight timing constraints in Java.

Also, I wonder if any of the safety-critical code is in Java. It seems like a JVM is too large and complex to use in a safety-critical context.

[–]pjmlp 1 point 3 months ago 

They are using the PTC (former Atego) Utra.

http://de.ptc.com/developer-tools/perc

Real time JVM aren't what you download from Oracle, they require a few KB, offer AOT compilation and fine tuned GC with controls how it should behave, setting latency deadlines and so on.

[–]FlyingPiranhas 1 point 3 months ago 

Sweet, thanks for linking me to that.

I found the following quote on the page you linked to:

Impressive deterministic real-time behavior with typical response latency of <1ms on x86 1.6GHz+

I don't think that 1ms is a particularly tight timing constraint, and "typical response latency" doesn't sound useful for hard realtime systems. I presume they aren't using this for their tight deadlines, only for higher-level control.

In that case, I'm not really surprised. Keep Java away from the safety-critical code and code with tight deadlines, and the GC and error handling issues become less significant.

[–]pjmlp 1 point 3 months ago 

I don't have real life experience with such systems, but as someone that tasted systems programming with Oberon and delved into the worlds of Mesa/Cedar and Modula-3/Spin, I became convinced that such GC use is possible.

So I get to learn about those systems on my researches as language/systems programming geek.

Just like no one believed in JavaScript before V8 or PHP before HHVM, there just needs to exist a brave company that decides to push the state of art.

[–][deleted] 2 points 3 months ago 

We definitely agree that GC is workable for some kinds of programming, for sure, including things where you'll find lots of people who say it isn't.

But still, there are things where "<1ms typical" isn't good enough and an $n00 x86 drawing several watt isn't an option. Language (and to some extent tooling) design in that space hasn't changed much in 20 years. Rust and others might have a future here, but I don't think Java does in any meaningful timeframe.

[–]matthieum 0 points 3 months ago 

I seem to remember that the (forgotten here) Nim has a very tight GC control built-in. Specifically, you can take over control of the GC to decide when to run the collections and for how long at each iteration.

I cannot promise they get below the 1ms mark, as it might not be needed to write games (its primary goal, originally), but who knows.

[–]FlyingPiranhas 1 point 3 months ago 

Nim doesn't have hard realtime GC. Its collector could easily blow past your deadline for the following reasons:

  • The cycle collector ignores the deadlines. This can be disabled, but then it is no longer a full garbage collector (and could be replaced with reference counting).
  • Even if the GC algorithm itself is fine, most OSes do not have deterministic malloc() and free() implementations. You would need a realtime allocator (such as TLSF) for that to work.

Of course, games don't have hard realtime requirements (and are much more lax on their deadlines than many embedded systems), so Nim's compromises are fine for game development.

[–]silent-hippo 4 points 3 months ago 

I've come to the same conclusion myself. It seems like the only one with a chance to replace C is Rust and even then its a long shot. One of the other reasons I think it will be hard to replace C is that C is supposedly an easy compiler to build. Many embedded devices may not have enough incentive to get Rust to compile to them.

Rust has improved my C code though, for instance I tend to internally think about how I'm "borrowing" a variable when I pass pointers around and then treat it like its borrowed. Has helped make my code much more solid.

[–]millenix 1 point 3 months ago 

It probably helps that Rust compiles through LLVM, so most of the porting effort should simply be defining the backend target mapping that would probably have been done for one of Clang/LLVM or GCC anyway.

[–]matthieum 0 points 3 months ago 

Also, in embedded programming, you have all the static analysis tools already exist to, notably, check the maximum depth of the stack... all this tooling has to be adapted/re-built for a new language, which is a clear cost.

[–]xsolarwindx 0 points 3 months ago 

What do you mean "Rust to compile to them?" All you need is an LLVM backend...

[–]isHavvy 1 point 3 months ago 

And an LLVM backend can be more complex than implementing a naive C compiler.

[–]jessypl 0 points 3 months ago 

However, you can cross-compile, so it's not really an issue, right?

[–]isHavvy 0 points 3 months ago 

You can only cross compile if there's an LLVM backend for your system.

[–]genbattle 13 points 3 months ago* 

Came expecting a troll post, walked away feeling slightly more knowledgeable and enlightened.

I do agree with him that Some of the lustre has waned for rust post-1.0. For me at least, the language will be significantly different/easier to use once some of the major long-tail features that have been on the boil/backburner since before 1.0 come to fruition, but it seems like by the time that happens our tooling and features around other languages will have moved on sufficiently to prevent Rust being a compelling option for a new project.

I also agree with him that it remains to be seen whether Rust will still be better than other languages once it accumulates enough stuff to come to feature parity with those languages. There will always be domains in which C or C++ will continue to be more appropriate tools than Rust, and that will mean that even if Rust does become dominant, it will take some time before those languages wane (if at all).

I know all the usual about statistics and lies applies, but I always find it interesting to look at the subscriber stats for this subreddit and other related languages. These numbers are heavily biased towards the age of developers that use each language, how active those developers are on reddit, etc.

Looking at the relative trends in subscriber growth, cpp appears to be following a superlinear growth trend, with golang slowly falling further behind cpp indicating cpp is still growing faster than golang, despite the recent popularity of golang. The rust line follows the same sort of superlinear trend as golang and cpp, but has distinct jumps, the most significant of which is around the 1.0 launch. Since then growth has actually slowed quite a bit.

Draw what conclusions you will from this analysis, but I do think it supports Andrei's conclusion about interest in Rust post-1.0.

EDIT: The stats here are also interesting. I removed C++ from the analysis as it made the graphs useless. It seems like Rust is about 3 years behind on the adoption curve wrt Go, which makes sense given the time between the 1.0 versions for each language. Again, BYO grain of salt.

[–]Manishearthrust · servo · clippy 17 points 3 months ago 

The past few weeks have led me to believe that /r/golang is not representative of the Go community (somewhat confirmed by what some Go friends of mine have said), whereas /r/rust contains a large number of prominent Rustaceans and is considered pretty eqivalent with the official forums (with many people not even knowing that the subreddit is "unofficial") in terms of types of posts, types of discourse, types of people, and general demeanor.

[–]lapingvino 0 points 3 months ago 

Actually, the very most of Go happens outside of the community, e.g. the big uptake in China it experiences.

[–]steveklabnik1rust 2 points 3 months ago 

once some of the major long-tail features that have been on the boil/backburner since before 1.0 come to fruition

Which ones matter to you? Always interested in what to work on first.

[–]genbattle 13 points 3 months ago 

The one that's caused me the most pain on my current project is #1038. I ran into another one the other day that someone brought up as a workaround for #1038 but it hasn't even been commented on since 2014 (I can't remember the RFC number off the top of my head).

In general I get frustrated with how often in Rust I have to settle for some sort of hack in order to do something in Rust that I know is straightforward to do in C++. The Rust code that I end up with doesn't feel any cleaner or easier to understand than C++ code. It might just be my poor understanding of Rust as a language, but at the moment I just don't feel at all comfortable recommending Rust over C++14.

[–]bkv 5 points 3 months ago 

Can you eli5 "type level integers?"

[–]desiringmachines 17 points 3 months ago 

You can abstract over [u32; 16], and [f32; 16] as [T; 16]. But you can't abstract over [T; 16] and [T; 8] as [T; n].

[–]llogiqclippy · rust 1 point 3 months ago 

Unless you use GenericArray<T, N>, which admittedly is not as nice to write as [T; n].

[–]desiringmachines 3 points 3 months ago 

This is using a lot of hacks to make it work; it would be better to provide actual language support for type level integers.

[–]llogiqclippy · rust 1 point 3 months ago 

Of course. Still, it's a nice hack, and if you don't want to wait and can live with the inferior usability...

[–]MrMarthog 5 points 3 months ago 

For example you can encode the dimensions of a matrix in the type system. This allows to store memory inplace instead of inside an extra allocation and you can also statically detect matrix multiplications that have non matching dimensions.

[–]leonardo_m 7 points 3 months ago 

This code is not useful in most real-world use cases, but shows your example usage of type level integers, D language:

import std.stdio, std.string, std.numeric, std.algorithm, std.traits;

alias TMMul_helper(M1, M2) = Unqual!(ForeachType!(ForeachType!M1))
                             [M2.init[0].length][M1.length];

void matrixMul(T, T2, size_t k, size_t m, size_t n)
              (in ref T[m][k] A, in ref T[n][m] B,
               /*out*/ ref T2[n][k] result) pure nothrow /*@safe*/ @nogc
if (is(T2 == Unqual!T)) {
    static if (hasIndirections!T)
        T2[m] aux;
    else
        T2[m] aux = void;

    foreach (immutable j; 0 .. n) {
        foreach (immutable i, const ref bi; B)
            aux[i] = bi[j];
        foreach (immutable i, const ref ai; A)
            result[i][j] = dotProduct(ai, aux); // dotProduct is currently unsafe.
    }
}

void main() {
    immutable int[2][3] a = [[1, 2], [3, 4], [3, 6]];
    immutable int[3][2] b = [[-3, -8, 3,], [-2, 1, 4]];

    enum form = "[%([%(%d, %)],\n %)]]";
    writefln("A = \n" ~ form ~ "\n", a);
    writefln("B = \n" ~ form ~ "\n", b);
    TMMul_helper!(typeof(a), typeof(b)) result = void;
    matrixMul(a, b, result);
    writefln("A * B = \n" ~ form, result);
}

[–]steveklabnik1rust 2 points 3 months ago 

Thanks. I'm guessing it was non-lexical lifetimes, which, while the issue hasn't been commented on, is undergoing tons of work: we've been in the middle of an internal compiler overhaul that will make both of those things easier to implement.

I will say that usually, talking to C++ people, these kinds of issues do crop up when trying to write C++ in Rust, rather than doing things the Rust way. Rust really wants you to do things the Rust way. Which doesn't mean that things are always perfect, of course, as with those two features you pointed out. But it's nice to know that your two (well, I'm only guessing at the other, since you can't remember) big issues are basically at the top of the list.

[–]genbattle 1 point 3 months ago 

Yes, I'm hopeful that with time both rustc and my understanding of the language will improve enough to change this.

[–]kibwen[M] 15 points 3 months ago 

Usual reminder to all to keep language discussions civil. :)

[–]looneysquash 4 points 3 months ago 

Why does D compile so quickly? (Note that I haven't played with D, and am going by the article.)

He acts like it's inherit to D somehow? Why would it be impossible for Rust to someday compile as quickly?

[–]theICEBear_dk 9 points 3 months ago 

It was part of the syntax design process that they thought about how the code would lex and parse. Walther Bright who started on D is a very experienced compiler writer, so he wrote D1 to be easy/fast to parse.

[–]looneysquash 1 point 3 months ago 

I'm willing to believe it's because Walter Bright is awesome and did a good job on the D compiler in general, but I'm suspicious of your specific lex/parse explanation. I thought the time to generate an AST was relatively trivial compared to walking it and generating code?

I should probably find some numbers and see for myself.

[–]theICEBear_dk 3 points 3 months ago 

Well my explanation is simplistic, but remember that in comparison with C++ at least as far as I know D does not require multiple passes and deep reasoning about the code. Now CTFE (compile time function execution) will naturally slow your code, but as far as I know in D (my experience is a year or so old as I have been playing with other languages) the standard D library phobos takes very very little time to compile from scratch. But I think the best way is to check yourself and maybe try a comparison compile with various pieces of code. I think rust may always be slightly slower here because of the borrow checker adding time (and compile time not being a major target for the language development).

[–]matthieum 4 points 3 months ago 

Walter Bright.

D's creator, he was also the first to write a C++ compiler which did NOT transpile to C, and thus at the time was the fastest C++ compiler (it's now Digital Mars C++ compiler). He's a compiler guru, and so designed D to be fast to compile as a guy with intimidate knowledge of how compilers work internally.

[–]pcwaltonrust · servo 6 points 3 months ago 

Kind of nitpicky, but I didn't really like the focus on "marketing" in this answer. All of the programming languages mentioned are communities, and "marketing" sounds like something that a company or at least a top-down organization does. I personally don't feel the need to "market" Rust.

[–]SupersonicSpitfire 4 points 3 months ago* 

Nim is also a candidate.

[–]matthieum 1 point 3 months ago 

Yes, it's sad it wasn't included in the question :(

[–]ohlson 3 points 3 months ago 

In order to replace C, the replacement language must be usable in the same situations as C. Only one of the three languages (Rust) really comes close. As far as I know, both Go and D requires a heavy runtime to even work. I wouldn't wanna port that to a microcontroller. If I would be insane enough to do that, I wouldn't choose an imperative language anyway.

[–]leonardo_m 2 points 3 months ago 

It's not too much hard to use D without the run-time.

[–]ohlson 3 points 3 months ago 

I have to admit that I was a bit too trigger happy here. I know too little about D to actually make that claim. The initial point is still valid, though: any language that is intended to replace C must be easy to use in a bare metal (freestanding) environment. That's one of the reasons why not even C++ has replaced C yet.

[–]Manishearthrust · servo · clippy 5 points 3 months ago 

The stdlib stops working then :)

[–]frog_pow 4 points 3 months ago* 

Rust is great, and I hope to use it in production someday. Basically a clean reimplementation of C++ without all the horribleness + some language features I miss when using C++(traits/enum).

But I would not use Rust right now, currently C++ has too many of Andrei's 10x advantages:

-Production quality IDE(VS), performance/memory profilers

-quality refactoring tool(Visual Assist)

-Incremental compilation(Rust will be far more appealing to me once it has this).

-SIMD intrinsics widely supported(AVX etc)

-And of course.. C++14 interfaces with all the existing C++, Rust does not:(

D doesn't really interest me. Go is barf.

[–]jeremiahs_bullfrog 2 points 3 months ago 

Interesting. I want to make games, so of that list, I only really care about C++ integration (don't want to build my own engine and Piston isn't there yet), incremental compilation and SIMD, in that order.

I'm still playing with it in the mean time and I'm having a lot of fun. When push comes to shove though, I use whatever language that has the lowest barrier to entry, and for games that's C++.

[–]cppcur 1 point 3 months ago 

If there is a python++, I will use it.

[–]blakecaldwell 1 point 3 months ago 

Whenever I read a criticism of Go, I feel like some time should be spent mentioning Go's tooling. I wouldn't be surprised if tools of this caliber exist for other languages, but Go's come basically built-in. PPROF has saved me tons of time, for example.

[–]fullouterjoin 0 points 3 months ago 

Looks like a great Rust project.

Use of this site constitutes acceptance of our User Agreement and Privacy Policy (updated). © 2016 reddit inc. All rights reserved.

REDDIT and the ALIEN Logo are registered trademarks of reddit inc.

π