Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

Post reply on HN
Print view View original

171–180 of 474 posts

Re: Rust is mostly safety

#171

Post by ekidd »

dom0 wrote: post #134
agentgt wrote: post #94

I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and bal…

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

As I noted in https://news.ycombinator.com/item?id=13277477, there are really only two major Rust libraries that are easier to use on nightly Rust (serde and diesel), and both can already be used on stable using a `build.rs` file (which takes about 10 minutes to set up–see the docs for the projects). You'll be able to get rid of `build.rs` in about 5 weeks when Macros 1.1 lands.

That said, if you want to play with nightly Rust, it's pretty trivial. Rustup https://www.rustup.rs/ makes it easy to install multiple Rust toolchains and switch between them, in a fashion similar to rvm and rbenv.

Re: Rust is mostly safety

#172

Post by pron »

steveklabnik wrote: post #161
pron wrote: post #156

Earlier quoted context omitted.

Doesn't Mozilla have good connections? It's not like you're a small, unknown organization.

Rust and Mozilla are two different things, even though a team at Mozilla (myself included) heavily contributes to Rust. Mozilla is a big place, so that means, in order to take that route, I'd have to figure out how to make connections within Mozilla to know the people who'd know those people. You're right that this might be helpful, but it's not something that happens overnight, that's all I'm saying.

That's fine. It's a slow-moving industry anyway. I think it's better to get the right people slowly than the wrong people quickly, and by the right people I mean those who really need Rust, and to be more specific, experienced systems programmers that have worked on large, complex projects (the more complex the software, the bigger the impact the language can have) and know what's really important and what's less so. If those people help direct the features, it would make it easier to get more of the "right" people. OTOH, if, say, Haskell people (I chose that example randomly, but I think they tend to be language enthusiasts and drawn to every new typed language, whether they absolutely need it or not) are those early adopters who help direct the language, the language may become less appealing to those who really need it.

Re: Rust is mostly safety

#173

Post by steveklabnik »

now wrote: post #164
steveklabnik wrote: post #93

Earlier quoted context omitted.

> C's versioning lives up to that standard. C has introduced breaking changes into newer versions of the standard. I don't know as much about ANSI Common Lisp or AWK. By "formal" spec, that depends; do you mean "a spec", or "a spec proven with formal methods"? The latter is undergoing work at various universities. The former doesn't exist yet, but is a goal of next year, and we've already taken some steps towards hav…

Out of interest, what breaking changes have been introduced to C in C99 and C11 (I’m assuming we’re using C89 as a baseline) beyond changes in corner cases in tokenization due to the introduction of “//” comments (and perhaps the removal of gets)?

The removal of gets is what I was thinking of.

FWIW, I think that's the right thing to do. My point is just that the OP has completely unrealistic expectations of how actual programming languages work. What actually matters is, how much pain do you feel when upgrading to a new version of the language? The removal of gets violates the parent's "even once is one time too many", even though in practice, it's a complete non-issue.

Re: Rust is mostly safety

#174

Post by nickpsecurity »

pron wrote: post #155
nickpsecurity wrote: post #141

Earlier quoted context omitted.

"Current C/C++ developers really do need more safety. They don't need a more pleasant language. " The number of C++ developers griping in HN threads about language-level problems effecting their work tends to disagree. It's not as if they wanted C++ to be designed that way. It was just only one with big companies' support that had zero-cost abstractions for programming in the large & great compatibility with C librar…

> Many would love a better language. Matter of fact, they tell us in Rust threads here. Absolutely, but my emphasis was on the difference between "love" or "want", and "need". Switching a programming language is extremely expensive, doubly so in systems programming. Organizations won't pay the price for something that doesn't make a big impact. Unlike many other new languages, Rust does have the potential to make a b…

"I don't think max performance is an issue at all"

I'll consider believing that when you remove both the performance-enhancing aspects and their marketing from your company's products that appear to target enterprise space of people using GC's and concurrency. Rust's safety w/out performance hit affects those two, specific areas. I think they might be interested.

Not to mention businesses doing analysis they want to happen faster, game developers, real-time groups wanting no runtime (or close to it), HPC that definitely cares about max performance, and small (or cloud) companies like those switching from Python to Go specifically due to lower costs from higher performance. Maxing performance is always a benefit if you can tell them it saves time or money but comes with the tools essentially free. That's actually how a lot of better JVM's (esp AOT) were sold.

"(there are realtime GCs, and GC languages do support arena GC allocation in embedded and realtime settings, like realtime Java)"

They're not default in these GC languages. We both know about them but most people don't. I've been telling Java & C# developers about those things for years with not one ever having heard of it before. Recently explaining to people that think an OS can't be written in Go that both OS's w/ GC languages & real-time, concurrent GC's existed. So, in their minds, there's horrid C/C++ w/ no safety, all these languages with GC's that have GC issues, and now a safe language with no GC. It's a perception thing that gives Rust an advantage over tech you described.

" but on those for whom the language is indispensable, or tremendously beneficial."

I'll cede you that. This would almost solely be aimed at the C, C++, Objective-C, and Fortran crowds. People stuck with caveman tools and unsafety.

"and for systems programming, that network is not well represented on HN and Reddit."

Definitely true.

"end up making up most of the community, they may slowly push the language in directions that may make it less appealing to those who really need it."

This is a real risk they should consider more. The best route would probably be to send people to the sites, conferences, and companies heavily into C and C++ for many use-cases. Get all this feedback they're getting from them at least as much as the others if not more. That might inform the language design in a way that addresses the risk you're bringing up.

Re: Rust is mostly safety

#175

Post by childintime »

I think Rust is not about safety, but about reusability. Do you like to take on a dependency on someone's code when it is in C? The answer is: roll your own code. Rust means the end of that.

Rust means software that can be written once and used "forever". Thus it enables true open source. In comparison C/C++ pay a mere lip-service, by also giving you, along with the code, lots of reasons to worry.

This is the real innovation behind Rust.

Re: Rust is mostly safety

#176

Post by nickpsecurity »

pjmlp wrote: post #126
nickpsecurity wrote: post #119

Earlier quoted context omitted.

I thought it was supposed to be Oberon-2 with some Limbo, C, etc touches. That's part of how it becomes my slam dunk against C in anther discussion. ;)

If you read the Inferno programming guide, you will see how much the languages resemble themselves. Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types. But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks. On the other hand Oberon-07 is even more bare bones than Go.

I only glanced at Limbo. I'll have to take a more detailed look at it. Inferno was definitely interesting. It was even ported to Android to replace Java runtime by people at Sandia.

Re: Rust is mostly safety

#177

Post by pjmlp »

nickpsecurity wrote: post #132
steveklabnik wrote: post #78

Earlier quoted context omitted.

To be clear, Graydon doesn't work on Rust anymore, and hasn't in years. His knowledge of the space is absolutely impressive, though. :)

Only inaccuracy I find is in his claim on safe concurrency in other languages. It existed in Concurrent Pascal (used in Solo OS), Ravenscar Ada (widely deployed), and Eiffel SCOOP (widely deployed). Rust isn't the first doing this. It's just apparently the best at it in system space. Ada camp is making a comeback, though, with ParaSail that looks interesting: http://www.embedded.com/design/other/4375616/ParaSail--Les…

ParaSail development looks stalled since its main designer joined AdaCore.

Just my impression, anyone feel free to correct me.

Re: Rust is mostly safety

#178

Post by pjmlp »

pvg wrote: post #158
pjmlp wrote: post #126

Earlier quoted context omitted.

If you read the Inferno programming guide, you will see how much the languages resemble themselves. Major differences are that Limbo uses a VM based runtime with dynamic loading and Abstract Data Types. But your approach is also good, still Oberon had some issues that were eventually improved in Oberon-2 that Go lacks. On the other hand Oberon-07 is even more bare bones than Go.

Most languages resemble themselves very strongly.

You lost me there, regarding Go vs Limbo.

Re: Rust is mostly safety

#180

Post by oconnor663 »

kincardine wrote: post #159
dom0 wrote: post #134

Earlier quoted context omitted.

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

I'm sorry your comment has gotten the response it has. The looming dark cloud of stable vs. nightly only looks like a dark cloud to those outside the Rust community. The article that made its way up Hacker News awhile ago ( https://news.ycombinator.com/item?id=13251729 ) got pretty much no traction whatsoever in the Rust community.

I think the Rust community didn't take the discussion very far, because it felt like the comparison to Python 2 vs 3 was out of proportion. The single most important difference is that stable Rust code is always compatible with nightly, and comparisons that gloss over that difference feel frustrating. (Other folks have raised more detailed objections too, like the macro features that are about to land in stable.)
Post reply on HN