Live data from Hacker News

Why I think Rust is the "language of the future" for systems programming

winningraceconditions.blogspot.com

81–90 of 193 posts

Re: Why I think Rust is the "language of the future" for systems programming

#81
post #62
post #57

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".

Apparently it won't work yet! Tragic. In the meantime, I can deliberate on whether or not to call it FOXDIE.

Re: Why I think Rust is the "language of the future" for systems programming

#82
post #80

Earlier 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…

[deleted]

Re: Why I think Rust is the "language of the future" for systems programming

#83

Earlier 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 just wanted to say, I totally understand where you're coming from here. I often end up writing libraries in C explicitly because that's the easiest way to hit as many targets as possible and not impose any unexpected runtimes on other languages, even if I know it would be easier to write in another language. So, I would say that not enough language designers think this way, and it's really refreshing to see you describing this point of view.

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.

[1] http://claylabs.com/clay/

Re: Why I think Rust is the "language of the future" for systems programming

#84
Another language that adopts a different syntax for the sake of adopting a different syntax. If you are going to ask me to adopt a different syntax, you'd better have a good reason for it, because I can do everything I need to do with the languages I already have.

Re: Why I think Rust is the "language of the future" for systems programming

#85
post #49

Earlier 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.

...both of which are domain specific languages, or developed as such.

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

#86
post #76
post #70

Earlier 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

99% sure that remark is in regard to C++. If it's about java, then it's just not true...

Re: Why I think Rust is the "language of the future" for systems programming

#87
post #21

Earlier 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…

When Go was announced it had a spec, a significantly larger standard library than Rust, two compilers (and a parser in the standard library), and much, much better documentation. While the language had changed until the Go 1 release from a few months ago, it had changed less in two years than Rust changed in a few months. Go also introduced a tool that would automatically rewrite your old code to adapt to the new language changes.

Re: Why I think Rust is the "language of the future" for systems programming

#88
post #55
post #47

Earlier 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. :)

Hm, you're right. There's also the scripting languages in Office, which were definitely management-driven. They share something with JavaScript - a strategy to differentiate an already dominant platform from competitors.

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

#89
post #49

Rust 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…

Meerkat telescope project has lifespan of at least 20 years and it's control-and-monitoring software is being written in Python.

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

#90
post #37
post #30

Three 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.

Fantastic summary of the pointers. It's less daunting now.
Post reply on HN