Hacker News new | past | comments | ask | show | jobs | submit login

Even once is one time too many.



No programming language, even C or C++ or Java, lives up to that standard.


They are very -very- close to that standard.


Totally. But OP is being absolutist about it. See my comment below.


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's versioning lives up to that standard.

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.

I'm not going to bother with the rest.


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


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


> ANSI Common LISP lives up to that standard.

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.


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


Why is this guy downvoted constantly? Whenever a lively discussion comes up, HN manages to stifle it.


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.

1: https://news.ycombinator.com/item?id=13267399

2: https://news.ycombinator.com/item?id=13278367


You didn't answer my question :)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: