Earlier quoted context omitted.
Ha, I was just thinking about how Rust bindings to Python might look. I haven't actually tried this, but since Rust libraries just compile to .so's and it's possible to declare a Rust function with a C signature, I bet it'd be a simple exercise to write a CPython-compatible extension module.
"I haven't actually tried this" Please remedy this immediately. I'll even provide a highly-imaginative name: "Prusty".
Why I think Rust is the "language of the future" for systems programming
81–90 of 193 posts
Re: Why I think Rust is the "language of the future" for systems programming
#82Earlier quoted context omitted.
Oh, come on. Rust started as an open-source project in 2010 (with the release of the preliminary design and OCaml compiler that Graydon had written as a hobby project). At that time, work started on the self-hosting compiler, leading to its initial 0.1 release eight months ago, and proceeding with releases every few months and steady progress toward the remaining goals on the 1.0 roadmap [1]. Just because Go was deve…
I've attended a few Go meetups here in SF already, and I haven't even seen any Rust meetups on the radar. At these Go meetups, companies are presenting what they're using Go for in production already, with great success. Go is not difficult to program in, Go is functional, Go is performant, Go is developer friendly. That is not to say that Go doesn't have warts, it does (32-bit garbage collecting anyone? or the slow…
Re: Why I think Rust is the "language of the future" for systems programming
#83Earlier quoted context omitted.
"If write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc?" The same way you expose them in C. Rust and C are compatible at the binary level. "How will Rust Tasks play with Python threads?" More or less the same way C setcontext()/swapcontext() workalikes play with Python threads. We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the w…
Thanks a lot for the info! > We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though. I'd be really interested in reading more about this if/when it is available. I'm also interested in whether you'd ever ship the tasks library standalone, such that you can interoperate with Rust tasks from C (obviously you'd have to follow certain rules to maintain the…
I've often thought that a useful exercise would be to come up with a language that adds just a bit more power than C but stays within the boundaries of the C runtime, just for this purpose.
However, if new languages like Rust can deliver this, all the better! One language that I once looked at with this in mind was Clay[1], which seemed to basically be C with more safety and generics. However, it doesn't seem to be as nicely supported as Rust, and perhaps Rust's static analysis and concurrency support will be more powerful.
Re: Why I think Rust is the "language of the future" for systems programming
#84Re: Why I think Rust is the "language of the future" for systems programming
#85Earlier quoted context omitted.
I'm assuming you'd rather see them focus on declarative programming, because it seems to be the big thing among enthusiasts and hobbyists . Google works with software projects with planned lifetime of decades. It's far better to rely on imperative programming concepts which are tested and trusted with experience grown from what, 50's or so. Sure, declarative programming is a nice toy , but that's all. I'm yet to see…
I'm yet to see major companies investing millions, if not billions of capital on a system written in declarative languages. We all "know" functional programming "is the future", but yet nobody trusts their money and time on them. SQL is declarative. Erlang is kinda-sorta functional, and was developed specifically to run expensive high-uptime telecom systems.
I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the language creator) has also hinted for much faster standardization process than last time around(when it took some 13 years to come up with a new standard), and would hope for a 5 year cycle instead, so perhaps C++16 is coming up next. Oh, and the standards committee is already working on it.
The only major setback I see with C++11 in comparison to many other languages aimed for large-scale software development is it's very small standard library which completely lacks support for modern technologies such as hierarchical filesystems, sockets, XML and HTTP and so on. They are coming up later on, though. The core language is very solid and doesn't lack anything special. Yet, it's not any more "bloated" or complex by it's standard(in terms of page/line/word count) than say C# 3.0 or Java 7.
tl;dr: I think many people think C++ is "old" or even dead and we need something more modern, yet now C++ evolves faster than ever and tries to meet that demand.
Re: Why I think Rust is the "language of the future" for systems programming
#86Earlier quoted context omitted.
I understand C++ project can take a long time to compile. Does Java project really take hours to compile?
Rob Pike, on justifying the development of Go: "today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours." http://splashcon.org/2012/program/404
Re: Why I think Rust is the "language of the future" for systems programming
#87Earlier quoted context omitted.
Rust feels more like Perl 6 (always on the horizon) or Ada (the do everything language), while Go already is already specified, being improved, and out in production.
Oh, come on. Rust started as an open-source project in 2010 (with the release of the preliminary design and OCaml compiler that Graydon had written as a hobby project). At that time, work started on the self-hosting compiler, leading to its initial 0.1 release eight months ago, and proceeding with releases every few months and steady progress toward the remaining goals on the 1.0 roadmap [1]. Just because Go was deve…
Re: Why I think Rust is the "language of the future" for systems programming
#88Earlier quoted context omitted.
You attribute too much to these entities called "Google" and "Mozilla". They're made of people. No executive asks for a new programming language. However at some enlightened organizations, they are willing to let hackers explore radical approaches. At some point, in order for them to become "official" projects, the hackers have to align the language with the organization's goals. But the imprimatur of their creators…
"No executive asks for a new programming language." Not that I think you're wrong, but I think the histories of Javascript and Ada stand as exceptions. :)
That said, managers usually have little say in defining what the actual language is going to be like or what its other applications will be, because so much has to be deferred to the language designers. Even though Netscape's execs specifically requested a Java-like language, they got something rather different.
Re: Why I think Rust is the "language of the future" for systems programming
#89Rust is what I had hoped Go would be. Google employs some of the brightest computer science minds in the world and turns out stuff like Go and Dart, which seem to be more aimed at enterprise Java programmers rather than computer scientists or programming enthusiasts.
I'm assuming you'd rather see them focus on declarative programming, because it seems to be the big thing among enthusiasts and hobbyists . Google works with software projects with planned lifetime of decades. It's far better to rely on imperative programming concepts which are tested and trusted with experience grown from what, 50's or so. Sure, declarative programming is a nice toy , but that's all. I'm yet to see…
This is to answer your direct question only because I fail to understand how your paragraphs fit together.
Re: Why I think Rust is the "language of the future" for systems programming
#90Three different types of pointers? Perhaps that is going a bit far? > If you've a sharp eye, you're wondering what that "~" is that I snuck in on the type of the closure for the child task. That's actually a pointer type, of which Rust has three (none of which can be null, by the way): > ~T is a unique pointer to a T. It points to memory allocated in the send heap, which means data inside of unique pointers can be se…
It's not too daunting. `&` is your go-to pointer for most scenarios. `~` pointers are for anything you want to send to a different task. `@` pointers are for things you want to be garbage-collected.