211–220 of 474 posts
The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…
I was surprised to see Ada in the list of unsafe languages, since it always was sold to me as being designed for safety. A bit of searching leads me to believe that Ada is better about memory even though it mostly uses types for safety, and better enforcement of bounds on array access should solve overflow issues regardless. Am I missing something?
Well there is this famous Ada failure: http://www.math.umn.edu/~arnold/disasters/ariane.html Although that was not a failure of language safety, but an overflow issue. The software was designed successfully for another rocket, and was reused for a rocket that didn't match the original specification.
> countless lives lost I have no doubt that people have had their lives ruined, or even died, as the result of flaws in system programming, but is anyone actually tracking this? Is it "countless?"
TDD: "If you're not doing this, you're not a real engineer." Rust: "If you're not doing this, you're a murderer."
I'm a huge fan of thorough designs, engineering formalities and quantifying application performance, but if we're building some fast food ordering app is expected to increase sales by 10 percent as soon as it's done and there's no risk from quality or availability or performance of the application (other than the 10 percent extra sales, we expect people to walk in / drive thru like normal if it under-performs on those metrics) then it's obvious the business value is in launching a minimal implementation as soon as possible using tools that optimize for productivity, not safety or performance.
Too often I see dogmatic pure functional TDD line of business app with continuous deployment infrastructure that could break for two weeks at a time without impacting anyone, or the copy-pasted-code-from-google-searches business-critical application that loses money for every hour it's offline but has no software development lifecycle or monitoring or alerting or anything.
Nim follows a different approach.
Details: http://nim-lang.org/docs/manual.html#threads
Benchmark (with Rust): https://github.com/costajob/app-servers
In case you missed that there's a big disillusioned C++ crowd out there. Just hear the pain: https://news.ycombinator.com/item?id=13276351 And some of them are watching you with great interest.
And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untr…
(Early in my career, I spent four years doing maintenance programming for a mainframe OS. Every time a machine crashed, taking a few hundred users off line for several minutes, I got a crash dump, which I had to analyze and fix. Most of the errors were pointer problems in assembly code. When Pascal came out, I thought we were past that. Then came C. I had hope for SafeMesa, but nobody outside PARC used it. I had hope for Modula I/II/III, but DEC went under. I had hope for Ada, but it was considered a complex language back then. Rust finally offers a way out of this hole. Don't fuck up this chance.)
The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
> As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that. I don't. It's a measure of the overall success. Design is but a small part of that. Community, outreach, corporate back up… play a huge part in the success of a language. Go is a wonderful example: doesn't even provide parametric polymorphism (generics), and they got away with that! Feels like Googl…
Earlier quoted context omitted.
ANSI Common LISP lives up to that standard. POSIX AWK lives up to that standard. C's versioning lives up to that standard. ksh93 lives up to that standard. All of those are backward compatible, and can churn through older versions of their own syntax with no problem. But that's not the point, and you know it: the point is you guys were hacking like crazy, without any engineering. That's why the syntax of Rust is insa…
Why is this guy downvoted constantly? Whenever a lively discussion comes up, HN manages to stifle it.
HN does not look kindly on people that make definitive claims without evidence, and especially not on those that refuse to provide evidence when then requested. There are less inflammatory ways to make the statements presented here, and ways to do it with evidence. That wasn't done.
I have seen the "breaking changes" aspect discussed multiple times in the past, and Steve has even addresses it in a prior discussion (linked to by him from this discussion)[1] and this thread itself farther up[2]. If you respond to him there with any questions, I'm sure he would be happy to answer or point you to relevant discussions.
I'll probably be writing a slightly longer response post to this later, but for now... EDIT: here it is: http://words.steveklabnik.com/fire-mario-not-fire-flowers I think the core of it is this: > Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. But you just did! That is, I think "fearless concurrency" is a b…
As someone watching from the sidelines... maybe it's the cynic in me, but I think you're giving too much credit to the "but I don't have safety problems" folk. Judging by how defensive they get, it's just a post-hoc rationalization to why they won't invest time learning it. That's fine but, IMHO, not a marketing problem and just good old resistance to change. There's an endless stream of excuses to choose from, no ma…