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

411–420 of 474 posts

Re: Rust is mostly safety

#411

Post by spc476 »

newsat13 wrote: post #320
EugeneOZ wrote: post #270

Earlier quoted context omitted.

When I write in Rust, I have feeling "that's how programming should work". I don't know how to express it in more scientific way. Errors handling, pattern matching, Result type - it's all how it should work. I know, some other languages have similar features, but Rust also has race-conditions protection (very important thing), good package manager out of the box, testing tool (cargo test), very smart compiler and gre…

I get the opposite feeling. When I write in Rust, I have feeling "that's how programming shouldn't work". The syntax is awkward and you are expected to spend weeks to get anything done. Ultimately, it seems to come down to Rust fans who have a sunken cost fallacy - I spent weeks learning this, so they think it is worth it.

When I was learning C back in 1990, it took me a long time to get comfortable with it, and that's after years of programming in Assembly language (8-bit, 16-bit, 32-bit). It took me some time to stop writing assembly in C and start writing C in C, if that make sense.

I haven't switched to Rust yet (I still deal with C/C++ at work on "legacy" code, and I'm having too much fun with Lua for my own stuff) but I don't expect to pick it up "quickly" and I'm sure I'll be trying to write C in Rust for some time. It comes with the territory.

Re: Rust is mostly safety

#412

Post by mmstick »

hedora wrote: post #359
cmyr wrote: post #233

Earlier quoted context omitted.

I couldn't agree more with this. Cargo (and the general desire to think and work hard on ease-of-use) is a huge part of what makes Rust a pleasure. It alone would be enough for me to steer someone with experience in neither to Rust over C++ for lots and lots of use cases.

I haven't looked at rust, and this sentiment is exactly what has kept me away. I watched perl, java, python, ruby, node and c++ (boost) fall into the trap of "we know better than the end-user/developers/sysadmins/os vendor, so let's reinvent dpkg poorly". Why should cargo be any different? It is solving a problem I don't have (debian, ubuntu, openbsd, and freaking illumnos all have acceptable package management), and…

Cargo isn't competing against nor replacing distribution package managers. Cargo is a build tool, not a package manager. You're free to package Rust software the same way you do non-Rust software for specific distributions. They are entirely different unrelated things with no overlap. Cargo solves a lot of problems that we've been facing for a long time. We have the Internet now, so let's use it to speed up development.

Re: Rust is mostly safety

#413

Post by kibwen »

zerofan wrote: post #400
kibwen wrote: post #393

Earlier quoted context omitted.

> a multitude of string types There are two string types in Rust, `String` (growable and heap-allocated) and `&str` (a reference to string data). Anything else is just a shim for FFI.

> There are two string types in Rust, `String` [...] Anything else is just a shim for FFI. I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.

I think it's especially hasty to criticize Rust's string types in the context of C++, given the standardization of string_view in C++ as an analogue of Rust's &str :P

Re: Rust is mostly safety

#414

Post by kibwen »

hedora wrote: post #402
kibwen wrote: post #391

Earlier quoted context omitted.

> talking about rust dll hell No, what that thread is talking about is that somebody wrote a library to exercise unstable features in the nightly branch of the Rust compiler, and that inspired somebody else to write a sky-is-falling blogpost claiming that nightly Rust was out of control and presented a dozen incorrect facts in support of that claim, so now we have to bother refuting the idea that nightly Rust is some…

From the thread, I got the impression that it is not trivial to backport packages from the nightly tree to the stable tree--people are talking about when packages will land in stable, but I'd expect that to all be automated by test infra, and too trivial for developers to work around to warrant a forum thread. Anyway, it sounds like I stepped on a FUD landmine. Sorry. It sounds like you work in this space. From my pe…

> Anyway, it sounds like I stepped on a FUD landmine.

That's the problem with FUD, it gets everywhere and takes forever to clean up. :)

> I got the impression that it is not trivial to backport packages from the nightly tree to the stable tree

Let's be clear: stable is a strict subset of nightly. And I mean strict. All stable code runs on nightly, and if it didn't, that would mean that we broke backwards compatibility somehow. And even if you're on the nightly compiler, you have to be very explicit if you want to use unstable features (they're all opt-in). Furthermore, there's no ironclad reason that any given library must be on nightly, in that boring old every-language-is-Turing-complete way; people use unstable features because they either make their code faster or because they make their APIs nicer to use. You can "backport" them by removing those optimizations or changing your API, and though that seems harsh, note that people tend to clamor for stable solutions to their problems, so if you don't want to do it then somebody else will fork your library and do it and steal your users. There are strong incentives to being on stable: since stable code works on both nightly and stable releases, stable libraries have strictly larger markets and therefore mindshare/userbase; and since stable code doesn't break, library maintainers have much less work to do. At the same time, the Rust developers actively monitor the community to find the places where relatively large numbers of people are biting the bullet and accepting a nightly lib for speed or ergonomics, and the Rust developers then actively prioritize those unstable features (hence why deriving will be stable in the February release, which will get Serde and Diesel exclusively on stable, which together represent the clear plurality of reasons-to-be-on-nightly in the wild).

> What's missing?

I've already typed enough, but yes, cross-platform support is a colossal reason for developers favoring language-specific package managers. Another is rapid iteration: it's way, way easier to push a new version of a lib to Rubygems.org than it is to upstream it into Debian. Another is recency: if you want to use the most recent version of a given package rather than whatever Debian's got in stock, then you have to throw away a lot of the niceties of the system package manager anyway. But these are all things users don't want; they don't want to be bleeding-edge, they don't want code that hasn't seen any vetting, and they really don't care if the code they're running isn't portable to other operating systems.

Re: Rust is mostly safety

#415

Post by zerofan »

kibwen wrote: post #413
zerofan wrote: post #400

Earlier quoted context omitted.

> There are two string types in Rust, `String` [...] Anything else is just a shim for FFI. I guess I don't have to worry about the non-Scotsman strings then... You've heard the criticisms about Rust's strings before, and I'm unlikely to tell you anything you don't know.

I think it's especially hasty to criticize Rust's string types in the context of C++, given the standardization of string_view in C++ as an analogue of Rust's &str :P

To me, Rust's &str seems a lot more like const char* (with a size tacked on for bounds checking). But you're the expert, so if I did agree they were the same, then C++ adopting it in the STL is practically proof it's a mistake in Rust.

You never addressed my other "too clever" items in Rust. Does that mean, other than strings, we agree?

Re: Rust is mostly safety

#416

Post by Annatar »

dang wrote: post #409
Annatar wrote: post #404

Earlier quoted context omitted.

struct Foo { take a look at tha example. Just look at it! Are you redirecting from stdin and then redirecting to stdout? Or is this supposed to be C++ templates? 'a, X: a' is shell escaping, or what? The syntax is insane , and even if Rust lived up to all of your (plural) claims, how could I ever bring myself to program in something as hideous as that ? Some more syntax insanity which is Rust: let path = Path::new(".…

Quite a few comments you've posted recently have crossed into incivility. You can't do this on HN. If you keep doing it, we will ban your account. Please take extra care to be civil when disagreeing on HN. Snark, acerbic overstatement, and personal rudeness are all unwelcome here. We've had to warn you about this more than once before. You've also posted some good comments, so I'm inclined to give you another chance,…

Considering the amount of censorship ("snark", "acerbic overstatement", "personal rudeness", and repeated threats "we will ban your account"), I am not at all convinced I want to keep posting here: "Hacker News" seems to have degraded into a club where people who stroke each others' egos get praised and rewarded, and where any criticism is labeled and severly reprimanded, even when it is warranted. I also do not appreciate being dictated in which style I am to express myself. Lastly, the cultural bias criteria for what consititutes "personal rudeness" is, from my point of view, insensitive in the extreme.

Re: Rust is mostly safety

#417

Post by pavelludiq »

paulddraper wrote: post #288
rkrzr wrote: post #45

Earlier quoted context omitted.

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…

> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It depends what you call a "type error". Is calling `car` on a `nil` instead of a `cons` a type error?

In common lisp 'nil is of type 'null which is a subtype of 'list, which is a union of the types 'null and 'cons so it wouldn't be an error. Other lisps might chose to do it differently.

Re: Rust is mostly safety

#419

Post by Too »

paulddraper wrote: post #252

If you're a C++ programmer, Rust is mostly about memory safety. If you're a Java programmer, Rust is mostly about tighter resource usage. If you're a Python programmer, Rust is mostly about type safety and speed.

If you are a c++ programmer, rust is also a lot about developer ergonomics. Syntax is nicer, build system is built in, less UB to think about, package management comes built in, and finally getting rid of those damn header files is such a relief.

Re: Rust is mostly safety

#420

Post by sametmax »

geodel wrote: post #340
sametmax wrote: post #284

Earlier quoted context omitted.

Anything that is robust, dynamic, with a big ecosystem. Python, Ruby, whatever have you. You don't need raw speed since the OS API does most of the work, and the ease of programming would make it more productive. In the end, they added Python anyway for stuff like "compose", so I'm missing the point of using Go for this. The Go code is not even network bound, the ability to get multicore easily is not a bit advantage…

Go has much lower memory usage, high throughput, std ssl/tls/http libraries, high performance GC and produce fully static binaries. I do not think Python/Ruby can provide required performance for containers, cluster scheduling, orchestration etc. Even Java with much higher perf compared to Python/Ruby is not suitable because of high memory usage.

> lower memory usage, high throughput [...] high performance GC

Irrelevant, as most ressources will be consummed from underlying OS API.

> std ssl/tls/http libraries

So does Python and Ruby. But even if it didn't, you provide a package anyway.

> produce fully static binaries

You can do that with Python and nuikta. But there is need for it, since docker is provided as an msi/deb/whatever that take care of distribution.

> high memory usage.

On your xGb RAM server, the memory usage of your container is the least of your problem. Your DB will dwarf it, your app will dwarf it. Anything you put in your containers will take 100 times more memory.

Post reply on HN