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

391–400 of 474 posts

Re: Rust is mostly safety

#391

Post by kibwen »

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…

> 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 somehow a threat to the language.

As for the package manager criticism, the overlooked point is that OS package managers serve a different audience than language package managers. The former are optimized for end-users, and the latter are optimized for developers. The idea that they can be unified successfully is yet unproven, and making a programming language is already a hard enough task that attempting to solve that problem is just a distraction.

Re: Rust is mostly safety

#392

Post by hedora »

z1mm32m4n wrote: post #365
hedora wrote: post #359

Earlier quoted context omitted.

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…

TL;DR: I think language-centric package managers do a better job at versioning packages per-project. Here's an anecdote to explain what I mean. ----- Let's say I want to build a piece of software that depends on some software library written in C at version 1.0.1. It's distributed through my system package manager, so I sudo apt-get install libfoo. ~~ some time later ~~ Now let's say I want to build a different piece…

I'm arguing that you should just have one package manager, so in my world the only way for this to happen is if both the packages you're installing are tarballs that no one has bothered to port to your system. If the language-specific package manager did not exist, then there would be a better chance the package would exist for your OS already.

Anyway, Debian/Ubuntu has multiple fallbacks for this situation:

a. ppa's

b. parallel versions for libraries that break API compatibility (libfoo-1.0...deb, libfoo-1.2...deb that can coexist).

c. install non-current libfoo to ~/lib, and point one package at it (not really debian-specific)

d. debootstrap (install a chroot as a last resort -- this is better than "versioning packages per-project" from an upgrade / security update point of view, but worse from a usability perspective -- you need to manage chroots / dockers / etc).

I suspect the per-project versioning system is doing b or d under the hood. b is clearly preferable, but hard to get right, so you get stuff like python virtual environments, which do d, and are a reliability nightmare (I have 10 machines. The network is down. All but one of my scripts run on all but one of the machines...)

A long time ago, I decided that I don't have time for either of the following two things:

- libraries that frequently break API compatibility

- application developers that choose to use libraries with unstable APIs that also choose not to keep their stuff up to date.

This has saved me immeasurable time, as long as I stick to languages with strong system package manager support.

Usually, when I hit issues like the one you describe, it is in my own software, so I just break the dependency on libfoo the third time it happens.

When I absolutely have to deal with one package that conflicts with current (== shipped by os vendor), I usually do the ~/lib thing. autotools support something like ./configure --with-foo=~/lib. So does cmake, and every hand-written makefile I've seen.

[edit: whitespace]

Re: Rust is mostly safety

#393

Post by kibwen »

zerofan wrote: post #348
yawaramin wrote: post #344

Earlier quoted context omitted.

I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever' I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, a…

> 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.

Re: Rust is mostly safety

#394

Post by nurettin »

steveklabnik wrote: post #139
nurettin wrote: post #123

Earlier quoted context omitted.

Wait, Rust has macros that expand to code and mess up debugging, confuse tooling and everything else just like C++? Isn't that exactly what the language should have avoided?

They do expand to code. They shouldn't mess up debugging or confuse tooling. They're much more similar to Lisp-style macros than the C preprocessor.

Oh, ok, the word macro is heavily overloaded and it seems I misinterpreted the Rust use of macros. But oh boy it costs lots of rep to ask a question.

Re: Rust is mostly safety

#395

Post by kibwen »

zerofan wrote: post #314
kibwen wrote: post #298

Earlier quoted context omitted.

> I think the safety aspect of Rust appeals to a lot of beginning programmers. Is that a bad thing? All programmers start as beginners, and if C is too painful to begin with then they'll learn via an easier language, and then comfortably spend their whole careers using those easier languages. If we want to expand the field of systems programmers organically, then we need to make tools that don't punish beginning prog…

> > I think the safety aspect of Rust appeals to a lot of beginning programmers. > Is that a bad thing? The appeal to beginners is fine, maybe even a good thing, but the condescending comments from beginners is a lot like listening to a teenager who thinks they know everything. > What makes you feel like anyone's looking down their noses at you? There're are no shortage of obnoxious comments from beginning Rust users…

> There're are no shortage of obnoxious comments from beginning Rust users here and on Reddit. If you can't see them, it might be because you're aligned with that point of view.

Can you give me an example of a comment in this thread that you find to be from a pretentious beginner? Alternatively, if you're calling the author of this article a beginner, I can assure you that he isn't.

Re: Rust is mostly safety

#396

Post by hedora »

white-flame wrote: post #364
hedora wrote: post #359

Earlier quoted context omitted.

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…

apt & ports don't follow you into other OSes. Language-specific package managers do, without requiring entanglement with the OS or admin permissions. All you need is sockets and a filesystem. I think the language-specific ones will win for developer-oriented library management for platform-agnostic language environments.

Apt and/or ports follow you to every OS kernel I can think of (Linux, MacOS, Windows, *BSD, the Solarises), though the packaging doesn't always (for instance, the OpenBSD guys have a high bar, but that's a feature).

My theory is that each language community thinks it will save them time to have one package manager to rule them all instead of just packaging everything up for 4-5 different targets.

The bad thing about this is that it transfers the burden of dealing with yet another package manager to the (hopefully) 10's or 100's of thousands of developers that consume the libraries, so now we've wasted developer centuries reading docs and learning the new package manager.

Next, the whole platform agnostic thing falls apart the second someone tries to write a GUI or interface with low-level OS APIs (like async I/O), and the package manager ends up growing a bunch of OS-specific warts/bugs so you end up losing on both ends.

Finally, most package manager developers don't seem to realize they need to handle dependencies and anti-dependencies (which leads you to NP-Complete land fast), or that they're building mission-critical infrastructure that needs to have bullet proof security. This gets back to that "reinvent dpkg poorly" comment I made above.

In my own work I do my best to minimize dependencies. When that doesn't work out, I just pick a target LTS release of an OS, and either use that on bare metal or in a VM.

Also, I wait for languages to be baked enough to have reasonable OS-level package manager support. (I'm typing this on a devuan box, so maybe I'm an outlier.)

Re: Rust is mostly safety

#397

Post by Annatar »

izym wrote: post #115
Annatar wrote: post #85

Earlier quoted context omitted.

I did so answer your question, you just don't like my answer. If you expect me to go look at every single thing that they changed, I'm not doing that. This isn't a pissing contest.

I asked you to provide a single example as proof and you have not done so. There is no pissing contest in asking you to provide a tiny bit of proof for your statements.

My claims are based on Steve Klabnik's own article on the subject, "four years with Rust":

http://words.steveklabnik.com/four-years-with-rust

I guess you somehow missed it, which is surprising considering just how extremely aggressive Rust people are at pushing the language. And frankly, I'm getting sick and tired of having to repeat and quote every single thing over and over and over again. The Anglosaxon system of god-like deference to sources, which themselves might be utterly wrong, is fundamentally flawed.

Re: Rust is mostly safety

#398

Post by Annatar »

the_why_of_y wrote: post #316
Annatar wrote: post #89

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…

> ANSI Common LISP lives up to that standard. There is only one version of the ANSI Common Lisp standard, so it is trivially compatible with itself. > C's versioning lives up to that standard. Then how do you explain this astonishing work of art? https://kristerw.blogspot.com/2016/07/code-behaving-differen...

Easy: you tell the compiler which version of C you're compiling, and it churns right through it without a peep. Versioned formats, cornerstone of every good engineering implementation.

Re: Rust is mostly safety

#399

Post by Annatar »

steveklabnik wrote: post #173
now wrote: post #164

Earlier quoted context omitted.

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…

The removal of gets is what I was thinking of.

gets(3C) is a standard C library function; it has nothing whatsoever to do with C the language. Proof:

  Standard C Library Functions                             gets(3C)

  NAME
       gets, fgets - get a string from a stream

  SYNOPSIS
       #include 

       char *gets(char *s);

       char *fgets(char *s, int n, FILE *stream);
Rust is targeted at people who write system code in C (me). But how the hell are you going to appeal to my demographic group, when you don't distinguish between libc and C the programming language?

What actually matters is, how much pain do you feel when upgrading to a new version of the language?

And this is where you (plural) err: take the illumos source code, for example. Take the GNU/Linux source code! No, take the OpenBSD or FreeBSD source code. How many lines of C code does any of those code bases have? You expect us to rip it all out and replace it with a different language. What is our cost of replacement?

That's the burning issue! And even that's ignoring the fact that the syntax of Rust and the concepts like borrowing are insane, and map to nothing in the experience of your target demographic, the system programmers.

Re: Rust is mostly safety

#400

Post by zerofan »

kibwen wrote: post #393
zerofan wrote: post #348

Earlier quoted context omitted.

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever' I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, a…

> 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.

Post reply on HN