Live data from Hacker News

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

winningraceconditions.blogspot.com

161–170 of 193 posts

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

#161
post #8

Earlier quoted context omitted.

The two languages aren't really in the same space in the first place. Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all. Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost an…

Go actually provides what I believe to be zero cost abstractions that map straight to the c memory model, making it very easy to use for systems programming. If you want a fixed size array of bytes, for for it. Zero overhead. If you want a slightly smarter list you can use a go slice, which is also pretty low overhead. I've personally verified that if I create a struct in go it takes up the exact same amount of memor…

> If you want a fixed size array of bytes, for for it. Zero overhead.

There's the overhead to check the bounds on operations in that array, which you don't have in C.

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

#162

I'm a die-hard C guy. My motto for years has been "you can pry pointers and address spaces from my cold, dead hands." Of the new languages I've seen lately, Rust is my favorite. I love how it gives me better ways to express things I actually want to say without imposing GC on me. But even so, I can't see myself actually using it for much, because writing in a language other than C means buying in to that language's r…

I'm a C die-hard as well. Tell you what I'm doing lately, that makes me less and less interested in the new-school elite, and just generally enjoying a language 'enigma' moment: putting Lua in everything. That is, I mean to say, Rust is neat and all but we can do it all in Lua, pretty well, too. Table types are fabulous, kids! And being able to take any collection of C libraries, and glue them together into 'ones own…

Is this intentionally snide? You appear to be implying that nobody should try to solve problems, because we already know how to work around them.

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

#163

Earlier quoted context omitted.

The whole idea of modern systems languages like Rust or D is actually to avoid the need of using Python, Ruby etc. The language covers all your needs in a nice coherent package from top to bottom.

> The language covers all your needs This is exactly the "one language" myopia that I was arguing against. Anyone who tries to sell me on a language or programming system that asks for complete buy-in and offers no interoperability story is immediately suspect in my book. (FWIW, I don't think the Rust guys actually sell this line, so I'm arguing against you, not them). No one will ever invent "the last language you'l…

Grandparent has a point, and it's not quite as outlandish as you make it out to be.

Consider that a lot of Python developers write most of their code in Python, then rewrite critical parts in C to speed it up. Python is not a speed demon, and that becomes particularly problematic with tight loops or heavy math—but writing entire applications in C is error-prone and tedious.

Rust won't outright replace both of those, but it does offer a nice middle ground: it's safe, it has some higher-level constructs, it does away with some boilerplate, it builds fairly easily, and it still compiles essentially to machine code. Writing quick shell-like scripts or entire applications in a systems language is now a viable option for lazy jerks like me, even if it's not always the best one.

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

#165

Earlier quoted context omitted.

Hedge fund trading code may not have "2030 and beyond" lifetime, but it's certainly something major companies are investing a good bit of money into. Also tends to be in OCaml...

Or rather: some hedge fund (of thousands all over the world) uses OCalml (Jane Street, IIRC). That does not equate to "hedge fund trading code tends to be in Ocaml".

It's not just Jane Street at this point. Jane Street has been using OCaml for a while, and others heve been picking it up too...

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

#166
post #92
post #40

Earlier quoted context omitted.

For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful toolbox full of different ways to solve different problems, much like Rust. Generators, context managers, metaclasses, decorators, and descriptors are all very different mechanisms, but they all work together well. Hell, I keep discovering that Rust has already…

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way. A Python replacement, this ain't. More like C++ on quaaludes.

Rust statically prevents leaks and double-frees, warns about implicit copies of large structures, and has GC built in if I want to use it. It's certainly more familiar to a Python dev than C++. The whole trait system is even like a built-in and vastly simpler zope.interface.

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

#167
post #40

Earlier quoted context omitted.

For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful toolbox full of different ways to solve different problems, much like Rust. Generators, context managers, metaclasses, decorators, and descriptors are all very different mechanisms, but they all work together well. Hell, I keep discovering that Rust has already…

Would be interesting to read a comparison with D. And no, "obscure" is not a meaningful description when comparing it to a language still at v0.3.

That's fair. I'm conjecturing somewhere into the future: D never really took off, but I'm hoping Rust will.

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

#168
post #85

Earlier quoted context omitted.

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…

From the outside, C++ appears to be such a mess that I actually cannot tell whether C++11 made it better or worse.

I don't think systems programming is going anywhere—I mainly stick to Python, but would like something lower-level available that I actually enjoy writing. The thought of having nothing better than C++ for the next however many years is terrifying.

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

#169
post #163

Earlier quoted context omitted.

> The language covers all your needs This is exactly the "one language" myopia that I was arguing against. Anyone who tries to sell me on a language or programming system that asks for complete buy-in and offers no interoperability story is immediately suspect in my book. (FWIW, I don't think the Rust guys actually sell this line, so I'm arguing against you, not them). No one will ever invent "the last language you'l…

Grandparent has a point, and it's not quite as outlandish as you make it out to be. Consider that a lot of Python developers write most of their code in Python, then rewrite critical parts in C to speed it up. Python is not a speed demon, and that becomes particularly problematic with tight loops or heavy math—but writing entire applications in C is error-prone and tedious. Rust won't outright replace both of those,…

> Writing quick shell-like scripts or entire applications in a systems language is now a viable option for lazy jerks like me, even if it's not always the best one.

I agree completely. I love Rust for this reason too. That's not what the grandparent said, or what I'm arguing against.

Grandparent was dismissing my concern about language interoperability because new languages should cover "all your needs." This attitude is closed-minded and dangerous.

A language that covers lots of needs is great. A language that is so useful that you find yourself needing fewer total languages for your project is great.

But the moment you use that as a reason to stop caring about interoperability between languages, to argue that it doesn't matter whether your language can interface with others, that's the moment when I stop paying attention to what you are designing.

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

#170
post #120

Earlier quoted context omitted.

You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize. Having said all that, yes, I believe major commercial projects are started…

Functional languages are declarative. The point is that there are two kinds of languages; languages which people bitch about and languages which nobody uses. Sure, I can mention tons of commercial projects which are started in those languages, and which use them at least partly(for example Python for scripting interface). However, I really doubt none of the languages provide a solid ground to build upon(even if we we…

This is a hard problem, because it involves mindshare and resources; even a perfect language would take years to gain a serious foothold. But it'll never be solved if nobody tries.

I'm glad someone's trying.

Post reply on HN