Tragic Death of Bubbles in the Ghetto - <AUTHOR> http://www.whattofix.com/blog/archives/2011/04/the-tragic-deat.php <comment><USER2> Yo, what's the story with your "Information you might find handy (other sites I have worked on)" section at the bottom of your right column? You really worked on all that stuff? Honest question, because it looks like paid seo spam links to me.

<comment><AUTHOR> Yes. All those sites were hand-coded and written by me or my wife.

I'm both a programmer and a former freelance writer and have been playing around with writing various pieces of content --- starting off with micro- sites and working towards a more mixed app/site design template.

I don't do paid links or any of that stuff. I just like creating stuff that people might find useful.

<comment><USER2> Gotcha. No offense. I guess seeing several variations of anchor text pointing to the same urls set my spidey-sense off. Just my unsolicited opinion: it comes across as a little spammish, vs. a simple list of your your other stuff with one link per source. But if the seo gods are smiling on you, who am I to object. ;)

<comment><AUTHOR> I get a lot of shit for those sites -- some fellow HN'ers even told me not to admit to authoring them.

But screw 'em, I spent a lot of time on each one, and as crappy as some of them are, they're _my_ crap, thank you very much. :)

Hackers have a very finely-tuned bullshit detector. I find I can set it off by accident very easily (which is another good argument about just being as honest as I can about these things) I try to explain everything I'm doing and why in blog entries, so no surprises.

You should have seen the post where I tried to explain that scientific research showed that pictures of non-threatening buxom women could double or more click-through response rates across all demographics. I thought they were going to shoot me for that one.

</comment></comment></comment></comment><comment><USER3> Anatomy of a Headline

</comment><comment><USER4> I had to laugh, thanks.</comment>


Time safety is more important than memory safety - <AUTHOR> https://halestrom.net/darksleep/blog/036_timesafety/ <comment> safety-third I actually have had the pleasure of porting a program from a defunct 16-bit language called Actor to C++. It wasn't a huge deal even at around 800 kLOC. All mainstream languages in the future are going to have some combination of structured, functional, and object-oriented programming. Converting is mostly going to be about syntax and libraries.

As someone who has worked with C and C++ for living for over 20 years, I wouldn't think twice about picking either Go or Rust if I were to start again. Go gives you the fast edit/compile/test loop of an interpreted language with the runtime speed of a compiled language. Rust is the language that the C++ Committee would make if they could start over.

That being said, Go will never take over the C, C++, and Rust niche. Going to and from Go-land and C-land is too expensive. Google has no interest in stepping behind libraries that aren't internet servers. Go will live a long life as a great environment to port your Python, Ruby, and other bloated server languages. It just will never be the next language to write a web browser.

Rust is amazing though. I see this as the programming language of the future until the U.S. Government slams down the hammer and forces everyone to use DOD-approved Ada.

<comment><USER2> Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with.

C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you _must_ learn and deal with the memory model, and it's not an easy thing.

<comment><USER3> I think the conclusion is that C++ is too dangerous in the hands of non- experts.

<comment><USER2> As far as it goes, I agree, and I rarely recommend C++ as the right language for a project.

Nonetheless, on real-world projects, a team of average programmers can make reasonable headway in C++. They'll probably write a lot of dubious and buggy code and _eventually_ slam into the complexity wall. In Rust, they'd slam into a wall almost immediately and very noticeably. Managers won't put up with that.

<comment><USER4> I've never really dug into C++, but I've written a little bit of C, and I feel it's generally easier to write a given program in Rust than it is in C.

I can see why Rust has its reputation for difficulty - the burrow checker is a new idea, and the unfamiliar is inherently dificult. However, I think once you've spend a modicum of time, it's a fairly straightforward language, simply because the compiler almost always tells you exactly what you're doing wrong.

I don't feel like it's a particularly ergonomic language, and it's certainly hard to read (very symbol dense), but I think it's easier to learn to appease the burrow checker than it is to debug your average C program, especially if you're the sort of person (I certainly am) that produces dubious and buggy code more days than not.

<comment><USER2> That may be, but debugging "looks like work" in the eyes of mgmt.

The borrow checker, on the other hand, looks more like "I can't find any applicants in Little Rock who can do this stuff.".

<comment><USER4> On the other hand, I think the most important thing in making developers replaceable is the degree to which the codebase explicitly contains all the information relevant to it.

Lifetimes are an additional, important piece of information that would have previously been something a programmer would have to have an intuition for, or that would need to be put in documentation.

Now, that work is delegated to the compiler, and so, your individual developer is somewhat more fungible.

I don't know if rust is specifically the future in this regard, but I think if I was a machivellian manager, I'd be interested in replacing instances of human intuition and group knowledge with tooling, as much as possible. The burrow checker is one such tool - even if automatic garbage collection is probably a more straightforward one.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> If "will this be usable in ten years?" is a concern, then you shouldn't be worried about your language choice. You should be worried about the services your program depends on.

Does your mobile app do anything useful if Google shuts down their authentication servers? What happens to your users if the App Store/Play Store decides to purge applications that don't actively support recent APIs? What happens when the Maven repositories your build depends on get shut down?

I would much rather figure out how to build a Rust program in ten years than try to recreate a web service that simply no longer exists.

While we're at it: All the "obscure" languages discussed here are FOSS. Finding an implementation will be relatively easy, and having access to the source means that things like binary compatibility issues can be worked around.

This is nothing like trying to resurrect a program written in an obscure proprietary dialect of Pascal that was only made available on a run of 200 floppy disks.

<comment><USER6> Programs I write are generally designed not to depend on any particular internet services (if they need some, they are configurable), and this is part of the reason to do.

And, yes in the case of these FOSS it is probably easily enough to find an implementation and to work around the binary compatibility issues. In the case of a program written in an obscure proprietary dialect of Pascal that you do not have an implementation of, well, sometimes you might reimplement a subset which is enough to run these programs (I have done similar things in the past), although of course it is probably going to take longer and be more difficult than FOSS is going to be.

</comment></comment><comment><USER7> Counterpoint: NES games were handwritten in assembler for a long-dead architecture. You couldn't pick a worse development environment for "time safety". The source code for most of the games is lost, too. Yet they remain some of the most portable programs in existence, because of emulation.

The PC architecture is extremely well-documented in practice (as are alternatives like WebAssembly), and there are going to be emulators for them around for the foreseeable future. Emulators for the PC architecture are no more likely to die in the future than C compilers are. You will be able to run any program written for the PC, in any language, for a very long time.

<comment><USER8> > The PC architecture is extremely well-documented in practice (as are > alternatives like WebAssembly), and there are going to be emulators for them > around for the foreseeable future.

Intel has patents on the x86 ISA. Though the basics of the instruction set (386, 486, Pentium) are outside the scope of a patent, it's impossible to write a complete emulator for a chip made within the past 20 years without infringing on Intel's IP.

<comment><USER9> Nintendo claims the same about emulation of their consoles. It hasn't appeared to be much of a deterrent.

<comment><USER10> Anyone can claim anything that helps their cause. All you have to do is not implement the emulator using the official developer documentation for the system.

For example on the original Gameboy the thing you have to avoid is using the copyrighted BIOS ROM. But you can avoid that by just initializing the CPU registers and instead starting at the cartridge start address.

<comment><USER11> FWIW, independent reimplementation protects you against copyright infringement but not patent infringement.

<comment><USER12> True, but patent infringement are limited to few places in the world, while copyright infringement are enforceable pretty much everywhere.

</comment></comment></comment></comment></comment></comment><comment><USER13> > _I don 't think it's responsible to ask ordinary programmers to start their > projects in new languages._

Rust is 14 years old[0], its compiler has been self-hosting for 9 years, and its 1.0 release was nearly 5 years ago. Sure, that's not as old as C or C++, but I wouldn't call it "new" either.

[0] [https://en.wikipedia.org/wiki/Rust_(programming_language)#Hi...](https://en.wikipedia.org/wiki/Rust_\(programming_language\)#History)

<comment><USER14> I'd call it maybe still a bit too new for applications where enterprise-level funds or harm to human life is in scope if the software fails. But it's getting there.

<comment><USER15> "too new". Would you say the same about he new Boeing plane, then - too?

<comment><USER16> The 737 max? Yeah probably.

<comment><USER15> However if 737 continued flying we would get more deaths rather than more fixes, wouldn't we?

Age has got nothing to do with stability.

</comment></comment></comment></comment></comment><comment><USER17> Rust isn't going anywhere in foreseeable future. Even _if_ it died today, it could stay around for a decade or two (Python 2 did. C99 is both a dead language and still considered new).

When it becomes so obsolete you won't be able to use it, it's likely that whatever you wrote in it also won't have any value beyond being a historical artifact.

And if you want to preserve programs and compilers for museums or far future, how about building computer for WASM+WASI and archiving that?

These technologies are still new, but their spec is much smaller and simpler than C and native OS APIs. You'll be able to recreate a WASM interpreter even centuries later, and from there revive the compiler and rebuild the programs.

<comment><USER18> > C99 is both a dead language and still considered new

Lest anyone doubt this, I recently worked on a (proprietary) library that the company kept C89-clean because some (similarly proprietary) embedded targets are basically frozen in the mid-90s.

<comment><USER19> That is pretty common in the embedded world. ANSI C is still equivalent to C89 here, which isn't really true anymore.

</comment></comment></comment><comment><USER20> This argument only makes sense if you believe the longevity of your project is more important that the personal safety of its users. For a lot of projects that might be the case. For most commercial and major open source projects, it is not.

</comment><comment><USER21> There's always Common Lisp. Still portable 35 years on.

I recall once, not quite 20 years ago, porting a large CL program from a 32-bit implementation to one of the then-new 64-bit Lisps. Someone who didn't know CL thought that would be a hellish job, but it turned out to be quite straightforward.

<comment><USER22> With the new research being done in macro-level type systems there's a lot of great reasons to check out lisp again (as a person who loves strongly typed languages)!

Type Systems as Macros - [https://www.ccs.neu.edu/home/stchang/pubs/ckg- popl2017.pdf](https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf)

Dependent Type Systems as Macros - [https://www.ccs.neu.edu/home/stchang/pubs/cbtb- popl2020.pdf](https://www.ccs.neu.edu/home/stchang/pubs/cbtb-popl2020.pdf)

It's so cool - especially the bits where they reconstruct each part of the type system and show how each feature they add contributes to the power/capability of it. :D

<comment><USER21> I used macro expansion for type checking in Zeta-C [0], the first C compiler for Lisp Machines, in 1983. Didn't write a paper about it, though.

Dependent types are certainly interesting -- I'll give this a read. Thanks!

[0] [http://bitsavers.trailing- edge.com/bits/TI/Explorer/zeta-c/](http://bitsavers.trailing- edge.com/bits/TI/Explorer/zeta-c/)

<comment><USER22> Awesome! I'm really enjoying reading your source code. Cool stuff; would definitely be interested in hearing your opinion of the papers.

</comment></comment></comment></comment><comment><USER23> > _In contrast my old C projects from 5-8 years ago still compile and run_

Sigh. Again this circular logic. And again, this is a fact simply because many people chose to muscle through a lot of problems that C has. It's NOT because C is amazing or anything. Many people chose to muscle through COBOL's problems as well. Is COBOL amazing? Is COBOL giving you time safety?

This is like saying that the Amish have the superior philosophy because there are still Amish communities. They have... a philosophy. They hold it dear. They insist on living by it. That's it. There's nothing more to it. No deeper revelation.

I am not going to engage in the "C vs. Go/Rust" debate apart from saying that _clearly_ many people dislike C and C++ and are looking for alternatives. Which by itself should immediately hint the author that his case is not as universally accepted as he seems to want to make it.

<comment><USER24> "My old C projects from 5-8 years ago still compile and run ... in my trusty Ubuntu 12 VirtualBox inside Windows 10!"

:)

</comment></comment><comment><USER25> It's actually the assumptions around longevity that need to be examined.

Software is not like etching perfect museum-pieces.

It is the union of the world that defines software's context, and since that will always change, we'll have to continue to write and re-write software to ensure the match is appropriate

<comment><USER26> It depends on what you're working on. I'm in the simulation area at an engineering company, and we've got plenty of Fortran code that dates back to the '70s that's still just fine. A little maintenance to work on removing deprecated syntax, a little work to replace common blocks with a more decoupled design, and we're probably good for decades more use. And if we can't get to that maintenance work right now, the strong backwards- compatibility of Fortran will have our back until the next opportunity. :)

<comment> safety-third Same here. We are stuck in Watcom F77 right now due to using some old extensions. We are in the middle of eliminating control characters from format statements so we can finally upgrade to new compiler.

</comment></comment></comment><comment><USER27> I thought this was going to be about concurrency, but it's instead about the risk that programming languages will become obsolete quickly.

<comment><USER28> I thought this was going to be about bounding the time complexity of your algorithms; I don't know if any language does that yet. I suppose this title has a lot of interpretations.

<comment><USER29> My understanding is that automatically determining time complexity is impossible in the general case due to the halting problem.

And getting a compiler to truly understand the time complexities of your data structures would involve either extremely difficult theorem proving or just forcing it.

I do think it would still be interesting if a language had support for determining time complexity. It seems like it's often possible even if it isn't in the general case.

<comment><USER30> Another issue is that algorithmic complexity only really 'composes' in a trivial and uninteresting way: Ok, you have a for loop over N items, multiply the complexity of the loop body by N.

Well, no not quite... it may be the case that one particular iteration of the loop makes all the subsequent steps completely trivial, so O(1)... and even further it may be that such a step is guaranteed to be reached in log(M) time, etc. etc. You see this type of thing a log in graph algorithms where they look like they might be O(n^3) or whatever, but leaving markers on nodes can avoid a lot of repeated work (by skipping marked node), so they end up as O(n + k) or whatever.

Upper bounds for worst case complexity are relatively easy... just assume the worst, but the interesting thing is proving _TIGHT_ bounds for worst case complexity.

</comment></comment></comment></comment><comment><USER31> Spoken in the voice of David Attenborough: and here we have the lifelong C programmer fighting for status among his tribe. He proclaims to have an authority on time, and his tribe agrees, as they wilfully ignore the fiery meteor that descend upon their position. Time, it seems, has almost run out.

</comment><comment><USER32> I think this is yet another post that falls into the trap of mistaking HN/Reddit -- fashion publications, really -- for something else. They're GQ or Vogue, not the New York Times. [https://news.ycombinator.com/item?id=22106559](https://news.ycombinator.com/item?id=22106559)

The vast majority of developers do and always will choose well-established languages. If Go or Rust or Zig or Kotlin or Clojure or Elixir ever become truly popular, by that time they will have become established and "safe" (unless they were Microsoft technologies, but they're not).

<comment><USER33> If you agree with this principle, I think the end result is that you choose the most popular language for some window.

For banks and airlines, you conservatively pick a large window. At one point that ended up being COBOL. That is slowly migrating to Java now. I suspect it will move to TypeScript in about a decade or so.

For new code today, I'd probably pick TypeScript.

A few years ago, I'd have picked Ruby. Before that, Python, Before that, Perl/CGI. Before that, Java. Before that, C++.

I wonder if at some point the tides will turn back to writing pure-personal- computer-and-no-cloud C/C++ Windows applications.

<comment><USER34> You just need to go into life sciences lab robots, factory automation, medical devices, ticketing machines,.... to enjoy doing Windows WPF or C++ applications.

</comment></comment></comment><comment><USER35> It's tempting to just drop this one because it's borderline flamebait, but there are so many pernicious misconceptions here that it's worthwhile calling them out explicitly. I'm generally not into author-chiding, but TBH the post was written in a very inflammatory and ignorant fashion that I'd encourage the author to be more thoughtful in the future so that we can all get out of the muck.

1\. False choice between "unsafe" and "new" languages. No, just no. Safe languages have been around since the 1960s (e.g. LISP). While it's not really "C versus the world", C/C++ are in the vast minority when it comes to safety across all programming languages. Throw a stick, hit a safe programming language. Java, C#, Rust, Go, Python, Ruby, R, Lisp, Clojure, Scala, Haskell, ML, Modula 3, TCL, JavaScript: the list goes on and on and on.

2\. C programs don't break. Just plain _false_. C and C++ are underspecified languages, meaning they have undefined behavior in some situations--actually, most situations. Undefined behavior is silent and there are poor diagnostics. It's almost always a program bug. Undefined behavior and even nonportable behavior is absolutely rife in the C and C++ world. Programs aren't necessarily portable across platforms, compilers, language versions, and even compiler bugs. Well-specified languages give programs a much better chance of being portable. Which leads to:

3\. Portability is mostly a language issue. This is only partially true. The fact is that portability and forward compatibility (time safety as this person calls it) is a function of dependencies--on the language version, compiler, external libraries, and general environment around the program too. Fewer dependencies generally means better forward compatibility. It's also good if those dependencies are maintained by teams who care a lot about backward compatibility. Some languages do more than others.

4\. "Time safety" is a term. I have never heard of this term before, which just speaks to the uninformed nature of this post. I think the author means forward compatibility.

Anyway, if you feel like the core message of this post is that unsafe=future- proof, feel free to choose another unsafe language to do your next program. Hint: there aren't many.

PS: Java 1.0 is now 25 years old. Java 1.0 programs still compile _today_ and the binaries that compiler generated back then _still run on today 's JVMs_.

<comment><USER36> > PS: Java 1.0 is now 25 years old. Java 1.0 programs still compile today and > the binaries that compiler generated back then still run on today's JVMs.

If you want to write a random program that you don't plan to support but want to remain usable, Java is your best bet.

I've on multiple occasions recently used really random Java GUIs that are from the 2000s (Melee related). It sometimes took some finagling (iirc I had to use Java 8 or something .. luckily it was just a nix-shell away!)

</comment></comment><comment><USER34> What a pile of garbage.

First of all try to compile C code written for 8 bit and 16 bit 80's micros to see how well it has stood the time, without making use of hardware emulators, spoiler alert it won't even compile.

Then plenty of programming languages, some of them older than C, are doing great.

Anyone with enough money can enjoy NEWP on Unisys ClearPath, a systems programming language almost 10 years older than C.

Or for free one can enjoy Algol 68 programs in 2020, [http://algol68.sourceforge.net/](http://algol68.sourceforge.net/)

Guess what, those languages took engineering seriously, unlike C.

"The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. Thus no core dumps should ever be necessary. It was logically impossible for any source language program to cause the computer to run wild, either at compile time or at run time. A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary pre- cautions would have long been against the law."

"Hoare's The 1980 ACM Turing Award Lecture", [https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf](https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf)

Still disappointed how Azure Sphere can sell its security story, while offering only C as programming language, so...

Even C++, with its copy-paste C89 compatibility, is already better than writing plain old C. And guess what, the language is 40 years old now.

<comment><USER37> I think of C as the Volkswagen Beetle, easy to produce inexpensive thing that hit a niche that didn't previously exist. Worse is better, low end eats the high end plus Dijkstra quote on Basic.

The real message in Trusting Trust is that the language has been backdoored at the design level, it doesn't need a malicious compiler. A message always has multiple parts, most people miss the important ones and just assume that literal interpretation is the intended one.

</comment></comment><comment><USER38> > C is much more likely to be the "safe" option if time x usefulness of your > project is a goal.

What about using Lua? Sure, different versions of the language are incompatible, but you could target a particular version. Anyone in the future who would be able to compile your C program would also be able to compile the correct version of the Lua interpreter, because it's written in pure ANSI C.

Using Lua instead of C would gain memory safety, at the expense of performance.

</comment><comment><USER39> In theory, we are asymptotically approaching a stable set of programming languages - a constellation of local-optimums. When something comes along with a different name and new syntax and cleans up some semantics, it's called a new language, but that's missing the point - the intent of the programming environment it provides remains similar. And then writing code in it is no real issue.

What ties us down to old languages is the whole environment - it is Joe Armstrong's "to give a gorilla a banana you must pick up the entire jungle" run rife through our production systems. Because our code increasingly depends on globally-sourced libraries, we tend towards copying around the entire planet and so there are layers of accretion all over.

And yet emulators do exist and run software successfully. The trick there is that they have a terrarium of sorts: a boundary that limits the ecosystem. The explosions that obsolete software tend to occur where a terrarium was not planned for by the original authors, rather continuous dependence on an evolving ecosystem was taken for granted.

</comment><comment><USER40> I use Pascal for all my projects because it has memory safe strings and arrays.

Almost all buffer overflows and security bugs could be solved by rewriting all software in Pascal.

Everytime a software crashes, you should say, it crashed, because it was not written in Pascal

I just spend two hours modifying my xml parser to load files that have a doctype with inline declarations. Never needed to load an xml file with a doctype before, and I only wrote the parser for the files I have. I also have plans for a json parser. There is a surprising lack of Pascal libraries.

<comment><USER41> You would probably like go, its much like pascal. And it has libraries for everything!

<comment><USER42> Last time I checked, Pascal has generics and exception handling.

<comment><USER43> Pascal has neither generics nor exception handling. At least, with reference to ISO Pascal.

<comment><USER40> Nobody refers to ISO Pascal anymore. It is either Delphi or FreePascal.

</comment></comment></comment></comment></comment><comment><USER44> If you're planning that far ahead it may not be an either-or situation. That is, in the future C/C++ may also have an enforced memory safe subset. In which case the issue becomes, how do you write your code today so that it will conform to the safe subset? There are conformance tools in the works that can already give you a sense of the restrictions that will be imposed [1].

[1] [https://github.com/duneroadrunner/scpptool](https://github.com/duneroadrunner/scpptool)

<comment><USER45> Please don't use promotional accounts on HN. We're here for curious conversation, not promotion. I appreciate that you've been posting these links in threads where they're mostly relevant, as opposed to blanket-spamming the site, but it's still not in the spirit of HN to have single-purpose accounts or to use this place primarily for promotion. It's ok to post your own work occasionally, as long as it's part of a diverse mix of posts that are motivated primarily by intellectual curiosity. That's the value we're optimizing for here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment><comment><USER46> What kills code more than anything else is not the language of choice, but operating system vendors "improving" user experience by deprecating APIs and frameworks.

That said, there are language communities that definitely value change more than stability * cough * javascript * cough.

But go. Imho it's unfair to implicate go. It has no backward incompatible change that I know of, and it literally depends on nothing but the kernel interface, which is known to be very stable.

</comment><comment><USER47> From the title you might think it's talking about safety from pathologically slow inputs. Especially considering there's a different post also on the front page right now about that exact thing.

> PerfFuzz: Automatically Generating Pathological Inputs (2018) [pdf]

[https://news.ycombinator.com/item?id=22315542](https://news.ycombinator.com/item?id=22315542)

</comment><comment><USER48> I kinda disagree. With C, you risk old autoconf scripts breaking, depending on library versions that operating systems don't include anymore, compilers learning how to exploit undefined behaviour they didn't exploit before, programs breaking due to making incorrect assumptions (`char` is signed, right?). C++ also adds exciting issues in terms of backwards compatibility breaks (for instance, programs using `register` keyword won't work since C++14) - refer to Annex C in C++ specification for a long list of BC breaks.

None of this is an issue in Rust. Cargo is a proper build system, not a weird combination of shell script and M4 using programs that are prone to breaking changes (like awk). Cargo requires defining program dependencies and prevents accidentally using a dependency that exists on an operating system. Rust in safe code avoids undefined behaviour, noticeably avoiding the risk of accidental undefined behaviour. Rust has much less implementation-defined behaviour than C (`i8` is a well defined type). Rust edition system means that breaking changes avoid affecting old code (even if Rust were to, say, remove `static mut` in edition 2024, this change wouldn't affect programs that wouldn't explicitly upgrade to edition 2014).

Rust is serious about backwards compatibility. Breaking changes are mostly unacceptable (other than in cases of soundness bugs, but even then there is typically a warning cycle before fixing a bug). In fact, you may take a look at "Compatibility notes" sections in [https://github.com/rust- lang/rust/blob/master/RELEASES.md](https://github.com/rust- lang/rust/blob/master/RELEASES.md). The compatibility breaks tend to be very minor, and unlikely to break stuff. For instance, in Rust 1.39, `asinh(-0.0)` was changed to return `-0.0` instead of `0.0`. Strictly speaking a breaking change, but a program depending on that is very very unlikely. Rust also has crater which prevents accidentally breaking backwards compatibility by testing whether every public GitHub repository and crates.io library still works the same way. Additionally, even in case program compilation breaks anyway, it's possible to use an older version of a compiler with rustup.

Rust is here to stay. Even if Mozilla ended up supporting the project, some other company that uses Rust internally would continue to support it. It's free software after all. Even if that wouldn't happen, the old rustc releases would still work.

</comment><comment><USER49> usually the argument to keep using a bad language is "but we have all this stuff we built and we don't have that in newer things so we can't easily change". but this is a new take! we can't use new languages because we expect only these flawed ones to live FOREVER

</comment><comment><USER50> New programming languages should address this concern. C by itself doesn't, really.

</comment><comment><USER51> TL;DR: It's better to have buffer overflows and use-after-free bugs that still work in 50 years than to have secure code you may need to migrate.

<comment><USER52> I think you're being sarcastic? But I also think the article genuinely believes that's true.

In 50 years there will be C programmers who know how to fix a buffer overflow, compile, and run your program. Conversely, a program written in a language and dependent on a package repository that only existed from 2017-2024 will likely never find an academic willing to invest the thousands of hours in learning that legacy code, digging through archives, and making that program run again.

<comment><USER13> > _In 50 years there will be C programmers who know how to fix a buffer > overflow, compile, and run your program._

I don't think that's a given. In 2070, C might be today's COBOL. There are a few people who know it, and are paid obscene amounts of money to maintain aging systems to keep them from falling apart.

Now, there's certainly more C code now than there was COBOL code at COBOL's peak, but that's no predicting the future. What I'd call "modern" computing and software development has only been around for 30-40 years or so. In 50 years I expect things to be radically different.

</comment></comment></comment><comment><USER53> The infinity-plus-oneth HN pigpile-on-the-C-luddite thread. Ugh...

</comment><comment><USER54> The knowledge needed to compile a C program into executable code will never die, as long as there is a human race.

<comment><USER55> Lots of C code have already bitrotted because APIs it depends on have been abandoned. Resurrecting it isn't just a matter of compiling the code, but recreating the environment it ran in.

<comment><USER54> That was before storage become abundant and cheap; from a source code storage perspective. It will not become more expensive.

Nowadays storage capacity is developed to store video - this is really the only thing that needs a lot of new storage capacity.

Every line of sourcecode written by every programmer ever is a fart in the wind compared to what's being uploaded to Youtube in the next 60 seconds.

<comment><USER56> Which does nothing to address "it works on my machine" build related issues. And more modern languages have much more robust solutions to hermetic build and package management.

<comment><USER57> That's what docker images are for :-)

</comment></comment></comment></comment></comment><comment><USER58> I don't get the argument. Is the author complaining about complexity of languages like Rust? I.e. only simple languages supposedly have longevity? C++ is complex, yet it already exists for quite a long time too.

Just because C happens to be a long used language doesn't mean you shouldn't be using newer and better languages and that those languages can't be used for a long time too.

C is used not due to big benefits, but mostly for legacy reasons today. Basically a lot of projects are already stuck with it. But for new ones, surely use Rust, not C.

<comment><USER28> Honestly, if you care about longevity, Rust simply isn't the language yet. I'd at least wait until there's a specification and a GCC frontend.

Anyway, C does have _some_ benefits as a programming language.

• "Legacy" projects like Linux and CPython will keep it alive for decades to come.

• It's extremely portable. Rust is less portable, and even when Rust supports a niche platform, it's relatively clunky to get things started.

• C libraries are always very easy to call from other languages. Rust isn't quite there yet, and translating things like traits can be a bit of a pain.</comment></comment>


Cloud Functions – Serverless Environment - <AUTHOR> https://cloud.google.com/functions/ <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=13831370](https://news.ycombinator.com/item?id=13831370).

<comment><USER3> Not the same thing

[https://cloud.google.com/functions/](https://cloud.google.com/functions/)

vs

[https://firebase.google.com/features/functions/](https://firebase.google.com/features/functions/)</comment></comment>


Medium's Policies and Guidelines - <AUTHOR> https://github.com/Medium/medium-policy <comment><USER2> The title seems to have changed in the last couple minutes from "Medium puts their terms of service on github" to "medium's policies and guidelines".

Just in case anybody is wondering why medium's terms of service are at the top of HN right now

</comment><comment><AUTHOR> I don't know if there are other companies doing this, but putting privacy and terms of service updates on GitHub seems like a simple way to be transparent. It makes it easy to see what has been added and removed from previous updates.

<comment><USER3> All of my employer's legal documents are available on GitHub as well under the same license: [https://github.com/Automattic/legalmattic](https://github.com/Automattic/legalmattic)

We also keep a changelog on our site as an alternative: [https://wordpress.com/tos-change-log/](https://wordpress.com/tos-change-log/)

</comment></comment><comment><USER4> It's important to note that a malicious organization could always backdate revisions, and force push over the github repository.

<comment><USER5> All it takes is a single person having it cloned, who can call them out because the hash values would have changed. This isn't really a realistic threat.

<comment><USER6> That single person who cloned it could also backdate their hashes and claim things changed when they didn't.

</comment></comment></comment><comment><USER7> Imho such legal documents should be kept on machines under more direct control. You want to, at a minimum, be able to pull the plug if someone starts messing with the contract between you and your customers. They can do too much pr damage too quickly. I'm even hesitant to endorse hosting them via clouds.

<comment><USER8> There are copies of these on medium.com:

[https://medium.com/policy/medium-terms-of- service-9db0094a1e...](https://medium.com/policy/medium-terms-of- service-9db0094a1e0f)

[https://medium.com/policy/medium- rules-30e5502c4eb4](https://medium.com/policy/medium-rules-30e5502c4eb4)

[https://help.medium.com/hc/en- us/articles/214151487](https://help.medium.com/hc/en-us/articles/214151487)

I don't see an indication that the GitHub version is legally binding.

<comment><USER7> Ah. Then they probably already have someone like me in their organization.

</comment></comment></comment><comment><USER9> Whatever happened to that XML alternative Linus was working on? It was supposed to be very similar to git but document-focused.

<comment><USER10> Intriguing. Where'd you hear about it?

<comment><USER9> I read about it here on HN but this seems to be the original post: [https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV](https://plus.google.com/+LinusTorvalds/posts/X2XVf9Q7MfV)

</comment></comment></comment><comment><USER11> I think have seen this used for laws and law changes. Im surprised it has not been massively adopted</comment>


Ask HN: Review my startup joinbox.com (closed beta invites) - <AUTHOR>

I'd love some feedback; we're a startup from Switzerland trying to help stay connected with a sleek unified inbox (social networks, email, rss)<p>http://beta.joinbox.com/?code=36x7x6pp <comment><USER2> Why do you want my email password? I'm using gmail, so I assume you could use OAuth for that? Also the request permissions dialog for FB is just plain scary, do you really need all those permissions? I like the sleek interface!

edit: if I view a tweet with replies, I would like to click the tweets bellow that to see replies to that tweet (just like on twitter.com)

edit2: add google reader integration for news feeds

edit3: how about visually separating content from different sources? For instance I put more importance to stuff from FB and if posts from FB would have a blue background (just an example) I could find them more easily in the swarm of twitter posts ...

</comment><comment><USER3> Plop down some coin and buy an SSL certificate. Really not comfortable putting in my email password/other information on an unknown site.

</comment><comment><USER4> It's really hard to tell what the product actually does from just that one screenshot. I tried to sign up but it said my username was taken (even though I've definitely never signed up before). Looks like an interesting product if I could see what it does specifically.

<comment><AUTHOR> Hmm, there are still some available. Try again. On the other hand, there's a clip on joinbox.com

</comment></comment><comment><USER5> It seems it needs my email password? Not sure I wanna give that out to just anyone.

Also, FYI, your site made my Google Chrome crash (XP)

</comment><comment><AUTHOR> Here are more invites: <http://beta.joinbox.com/?code=o7us6gu5>

</comment><comment><USER6> Good idea. I like your video. Unfortuantely it seems that you are out of tokens - so I can't get you more feedback than that.

</comment><comment><USER7> I was just looking for something like this. It's really nice so far.

</comment><comment><USER8> Seems like token not available any more</comment>


Show HN: Today, a social diary for android - <AUTHOR> http://www.todayapp.io/

<comment><USER2> Android-First. That's what made me download this. Nice idea!</comment>


The perils of file replacement on *nix - <AUTHOR> http://www.pixelbeat.org/docs/unix_file_replacement.html <comment><USER2> sponge (1) is a simple way to do this, but not available on all systems. See <http://joey.kitenet.net/code/moreutils/>

<comment><USER3> This is the most convenient solution. "sponge reads standard input and writes it out to the specified file. Unlike a shell redirect, sponge soaks up all its input before opening the output file. This allows for constructing pipelines that read from and write to the same file."

I remember writing a script that did the same thing (in Perl or maybe it was Bash).

</comment></comment><comment><USER4> I use this technique a lot:

      mv thing thing.old && mv thing.new thing

It works whether the thing is a file or a directory; I have an automatic backup called thing.old; I suppose it's reasonably atomic; and I can do it in ssh with no worries about losing the network connection in between the two moves.

<comment><USER5> It's not atomic at all although you're unlikely to notice in most situations. Not what I would use in a script, though.

<comment><USER4> On second thought if you use symlinks I'm pretty sure this is atomic:

      ln -Tfs $dir $symlink

Where $dir is the name of a directory and $symlink is the name of a symlink.

</comment></comment></comment><comment><USER6> How many people actually use shell redirection to copy and filter a file?

<comment><USER7> I do it all the time. Is there a better way? I'd love to hear it.

<comment><USER8> cat filename | filter > newfile

<comment><USER9> The point is that if filename and newFile are the same file, then this will overwrite the contents before they are read in by cat.

</comment></comment></comment></comment><comment><USER10> Diagnosis for 2 is wrong. The shell won't be scheduled to truncate the file after the shell is scheduled to fork/exec cat. The shell is not multithreaded.

<comment><USER9> The shell doesn't need to be multithreaded to be scheduled; after the fork, there are multiple processes, not multiple threads. The shell that exec's cat is in a different process to the one that exec's $filter.

</comment></comment><comment><USER8> I don't understand this article. Saying "Replacing the contents of a file on the UNIX command line using the standard cp/mv commands is surprisingly tricky" is like saying "driving a car using only your ass is surprisingly tricky". That's true, but when there are standard, simple, non-tricky ways to do it then you're really just limiting yourself.

But hey, I'll play along. Won't this work: cp file /dev/stdout > file

<comment><USER11> >I don't understand this article.... cp file /dev/stdout > file

Clearly, since this is point 1 in TFA. file is truncated before it is read, leaving you with a 0-length file.</comment></comment>


A Look Back at HelpSpot's First 6 Months of Sales - <AUTHOR> http://www.userscape.com/blog/index.php/site/a_look_back_at_helpspots_first_6_months_of_sales/

<comment><USER2> PG: "I admit it's odd, but there are no suspicious statistical patterns in the voting. If it's a ring, it's a new one."

How odd now?

(for those of you following along: [http://www.userscape.com/blog/index.php/site/comments/a_look...](http://www.userscape.com/blog/index.php/site/comments/a_look_back_at_helpspots_first_6_months_of_sales/) is also at the top of news.yc atm)

UPDATE: Oh sweet, now THIS version is number one! 62 votes and I am the only comment!

<comment><USER3> We're starved for DATA. Any factual data will do well.

</comment></comment><comment><USER4> HelpSpot is what Weebly uses to handle our support requests... We've been VERY happy with it so far.

</comment><comment><USER5> Very interesting, it's good of him to open up information like this.

Id personally be very interested to hear about people's lives _after_ launching a start up. Even if the success is just to replace their 9-5 earnings and be their own boss.

After all, that's what we all dream of right?

Still it's very inspiring.

</comment><comment><USER6> I agree that it looks a bit suspicious but the content is still interesting. Its a few years old now, so he's not giving any information to his competitors that will hurt him, so good for him. There is something similar here from Ultraedit:

<http://www.ultraedit.com/company/IDM_full_story.html></comment>