The compiler would tell you exactly what to replace, and that's all it took to upgrade. This was worth fixing a soundness hole. We originally thought that it would become an error in 1.5, but we monitored the ecosystem to see how many packages upgraded, and it wasn't until 1.7 that we were comfortable making the change. This meant that there was no effective break, even though code technically broke.
Those are the circumstances in which this might happen: very important, yet trivial to fix. We've only done it once or twice, and the vast majority of code written in the real world that built on 1.0 in practice builds on 1.14 today.
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("../word.lst");
let's map this to your target demographic again (me):
I first learned of "let" in BASIC. Path::new - so we're doing C++ now? C++ BASIC. And then there's "new", which means I'm instantiating an object. Do you seriously expect system programmers to start programming in an object oriented language, when it's clear to us that it's a horrible way to reason about data? (Hint: go back to the '50's and '60's, you'll find this wonderful paradigm called functional programming, which has a lovely sideeffect of being both stateless and reentrant. And then you'll discover this wonderful language called LISP.)
Err(why) => panic!("failed to open {}: {}", path.display(),
So what is this now, =>, SmallTalk? And exception handling! I. HATE. EXCEPTION. HANDLING. Why? Because if I'm using exception handling, it means that I was too lazy to do proper error checking and correction in the algorithm of my program! That is unacceptable for system programs, and frankly, for any type of a program.
Error::description(&why)),
Then all of a sudden, we're back to C++. C++ is an epic, colossal failure, precisely because of its complexity: it introduced more problems than it solved.
So Rust is a mish-mash of all these different syntaxes, and maps to zero in the C programmer's model and domain. When you (plural) embarked upon this project, didn't you know that if you want to replace something with something else, you have to map to your target audience's prior experience and knowledge?
And I still haven't addressed your claim (which you (plural) completely ignored too), that your language and the compiler, and the algorithms for memory management and safety have no flaws. That's the implication of a safe language, that the programmer's implementation of memory management is flawless! Where does Rust come from? Ah yes, from the Mozilla Firefox team. And do you know how badly Firefox runs on my Solaris 10 system? It crashes all the time, it's slow, and the latest version I have (45.5.1 ESR), the audio started cracking and popping. There is no way I'm going to trust the caliber of programmers who don't care about my platform and about code quality so as to release something like that (and that's not the first time).
We are not friends right now: your product is bad, and I don't trust you. And you (plural) are very aggressively pushing for replacing something simple which works (C) with your insane programming language. Between Rust and ANSI Common LISP, the choice is clear for me: anything that I can't implement in C, shell, or AWK, LISP is going to be my destination. Functional programming. Machine code when I'm done in the REPL. Metaprogramming. Stateless. Perfect. I'd just as soon program in Ada again, rather than Rust.
By the way, I watched your talk on Ruby and Rust[1]. After watching the amount of insanity you had to go through to print one line on stdout, I wanted to cut my veins and throw myself out of the window: I could have printed half of encyclopaedia Britannica in shell or AWK by that time. But that wasn't the worst part. The worst part was that you saw absolutely nothing wrong with all of that insanity, in fact you found it "cool".
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, but if you want to keep posting here, please fix this and make sure it stays fixed.
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.
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 insane, and why the language is incredibly complex, and expressions ugly, even for the simplest of things.
And while we're at it: is there a formal specification for Rust, that would say, allow me to implement my own, standards-compliant compiler?
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 having it exist.
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)?
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.
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 <stdio.h>
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.
The interface to environment objects in Common Lisp the Language 2nd Edition did not make it into the ANSI standard. If you're going to fail Rust for making changes pre-1.0, then you should fail ANSI Common Lisp too.
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.
As someone looking in that hasn't voted one way or the other on this thread, I would say it's because there's been no substantiation of the claims being made, even after it was specifically asked for.
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 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.
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.
