Rust is about letting the compiler slap you for your mistakes in the privacy of your own Xterm, instead of letting Jenkins do it 10 minutes later, in front of all your co-workers.
Rust is mostly safety
191–200 of 474 posts
Re: Rust is mostly safety
#192Earlier quoted context omitted.
No programming language, even C or C++ or Java, lives up to that standard.
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.
Re: Rust is mostly safety
#193Earlier quoted context omitted.
Serde does not require nightly, though it is nicer to use on nightly. That's the "will be stable as of the next stable release for Rust" I alluded to above. Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case o…
Over the last year of intermittently dossing around with Rust I encountered the need to use nightly regularly, with various crates refusing to compile (and usually I stopped my experimentation there as my barrier to entry was anything harder than pacman -S rust cargo). Yet I did not know until just now that Serde is moving off a dependency on nightly and it is encouraging that this is a trend with similar libraries;…
Serve creator here. The core library 'serde' never actually required nightly. It was just the helper library 'serde_derive' which can automatically implement the serde traits that needed nightly. dtolnay has been doing a wonderful job getting us off nightly. We can't wait to finally get rid of using it.
Re: Rust is mostly safety
#194The 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 Google backup matters more than the core language here. Either that, or someone please explain why omitting generics today is not a big mistake. Feels like dynamic scope all over again.
Re: Rust is mostly safety
#195Earlier quoted context omitted.
It's also worth noting that you're a bit less likely to see rust users because the kind of software that wants rust instead of golang tends to be the kind that gets written by a large company with deep pockets and a preference for closed source repositories.
If only Go was useful in building closed source products. Google must not have gotten the memo about Rust yet.
Contrary to popular legend, Google is not particularly strong on Go use, and it's not "THE official language".
It wasn't officially commissioned or officially adopted by Google to solve Google's coding problems as some believe.
It was merely initiated by a small team in Google, as their proposal for solving Google-scale coding problems. And has never been mandatory for new Google projects etc.
Go is ONE of the allowed languages, from what I know, but tons of stuff is written in Java, C++ and Python with no intentions of switching.
All those years, only a few, and basically trivial with respect to Google's needs, use examples for Go have come out of Google-land (a proxy/balancer for MySQL used in YouTube, Google Downloads caching, etc).
Re: Rust is mostly safety
#196Earlier quoted context omitted.
>> Currently Rust is about Go's age but nowhere close in usage. However, Go has been suitable for production projects for several years longer than Rust. Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go. Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use…
Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the G…
> re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.
Can you explain why?
For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something?
For example (in Java), an ArrayList could be turned into a StringArrayList by a basic internal pre-processor.
Re: Rust is mostly safety
#197Earlier quoted context omitted.
No, because if you explicitly converted to another type, that's what you wanted.
Sometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.
Sounds like an implicit conversion.
Re: Rust is mostly safety
#198Earlier quoted context omitted.
>> Currently Rust is about Go's age but nowhere close in usage. However, Go has been suitable for production projects for several years longer than Rust. Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go. Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use…
Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the G…
In my experience working with new and experienced Go developers that simplicity is pretty superficial.
Take a look at SliceTricks[0]. These are all pretty simple operations in other languages that the Go authors think users should be forced to write manually so they understand the costs. Reading these in code reviews is definitely not a breath of fresh air.
I also see Go users develop bad habits that will burn them in other languages, like returning a reference to a "stack" allocated variable. In the same vein, if you care about performance you have to internalize the escape analysis rules, which most new users won't know about.
There are tons of footguns[1] in Golang as well. I constantly see people get burned by issues at runtime. I truly believe that the Golang benefits are short-sighted. You get some upfront development gains that you end up pain for with less reliable software. I personally would rather pain that cost upfront where possible with the compiler telling me when something is wrong.
[0] https://github.com/golang/go/wiki/SliceTricks [1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
Re: Rust is mostly safety
#199Earlier 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.
That article had so many inaccuracies and/or was hyperbolic. Most of the points there are plain wrong.
http://xion.io/post/programming/rust-nightly-vs-stable.html#...
Re: Rust is mostly safety
#200Earlier quoted context omitted.
It's not "countless" it's "uncountable" because we couldn't agree on what a software caused death was. In my CS program we had an ethics class that included stories of bad X-ray machine software that overdosed people. Bad, bad bad. I don't think many people died as a direct result, but 10 years later there was probably a spiked cancer incidence. Did software kill people? Well yeah....kinda. In airplane systems, there…
Errors in the software of the radiation therapy machine Therac-25 directly lead to the death or serious injury of six patients. Three patients died within weeks or months. http://radonc.wdfiles.com/local--files/radiation-accident-th... Errors in the software of a MIM-104 Patriot resulted in failure to locate and intercept an incoming missile and the death of 28 soldiers. http://www.gao.gov/products/IMTEC-92-26 Errors…
There was no error in the Toyota throttle control system. It was a pedal error with floor mats, and a separate pedal design error for other models.[1], combined with operator error. If you are interested, I highly recommend Malcolm Gladwell's podcast Revisionist History, which did an episode on this[2]. Long story short, your brakes can easily stop your engine at full open throttle, and in not much more space than braking without any throttle. Unfortunately, a foible of human behavior seems to lead us to get flustered and often not do the right thing in situations like these.
1: https://en.wikipedia.org/wiki/Sudden_unintended_acceleration...