New Adventures for Elm - <AUTHOR> http://elm-lang.org/blog/new-adventures-for-elm <comment><USER2> I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy, by default). It's also well suited for both server and client code, and even has a C++11 backend in the works in addition to the native JS backend.

In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved.

Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?

<comment><USER3> Well, "superior" is subjective in this case.

It's like an OO programmer claiming that Smalltalk is a superior language than Elm. Besides, Purescript is squarely targeted at experienced Haskell programmers, which is not the case of Elm. Elm is an ML language, not a Haskell dialect that compiles to JS.

I also evaluated Elm, Purescript, Roy, F#, JS_of_Ocaml and ended up choosing Elm precisely for the reasons you chose to stay away from it. I only use JS for front-end stuff, I value simplicity over expressivity and I don't want to spend many weeks learning Haskell-like abstractions to start being productive in a new language (in contrast, it only took me an afternoon to start being productive in Elm).

<comment><USER4> > "Elm is an ML language, not a Haskell dialect that compiles to JS."

To be clear, Haskell also comes from the ML lineage.

<comment><USER5> ML stands for machine learning, correct?

<comment><USER6> In this context, it stands for MetaLanguage, which is a language family (and was at one point a language itself, I believe). The family includes Ocaml (see the ml there?) and Haskell, among many others.

<comment><USER7> As a point of possible interest to people who are interested in programming language history, I'm going to elaborate a bit on this topic:

The root of this particular family tree is essentially a fusion of the lambda calculus-inspired parts of Algol 60 and Lisp with some new ideas for syntax that were promoted by Peter Landin in his highly influential paper from 1966, "The Next 700 Programming Languages". He called this language ISWIM; it was studied extensively but never directly implemented. Landin was also associated with Dana Scott and Christopher Strachey in their foundational work on programming language semantics.

Robin Milner was interested in the relationship between the logic underlying the semantics of programming languages and the possibility of using computers to prove propositions in that logic (a logic developed by Dana Scott in support of his semantics work). At Stanford, he and a small team (including Whitfield Diffie, who later went into cryptography...) developed a system called Stanford LCF (for Logic of Computable Functions). This was an interactive system in which the user states a main goal in the logic, then splits it to subgoals and more subgoals until they can be solved directly. Proofs were represented directly by data structures and were built directly by the proof manipulation commands, which corresponded to the inference rules of the system.

Milner moved to Edinburgh in 1973, where he worked on a subsequent version of LCF, Edinburgh LCF. Stanford LCF was limited by the size of the proof data structures; for Edinburgh LCF Milner had the idea to forget the proofs, but store the results of them; i.e. the theorems. The proof steps would be performed, but not recorded. To ensure that theorems could only be constructed via valid proofs, a meta-language was developed with a static type system that would only allow data structures corresponding to valid theorems to be built. It also allowed more sophisticated proof development, since the meta-language was a full higher-order programming language modeled after Landin's ISWIM. Exceptions were included to deal with the possibility of failure of particular proof strategies. This version was implemented in Lisp.

LCF spread to other universities; it was early on split into two parallel tracks, ML and Caml. Both have continued to be strongly associated with implementation of theorem proving systems. ML and LCF have become Standard ML and HOL; Caml has become OCaml and Coq. A lot of programming language research has also gone into ML and OCaml as languages in themselves due to their close association with the logic underlying semantics of programming languages.

Meanwhile, a language called PAL was developed in 1968 at MIT in response to ISWIM and Strachey's ideas on programming languages. David Turner, while starting his Ph.D. research at Oxford, got access to the PAL sources and used a simplified form of the language as the basis for his lectures on functional programming at St. Andrews; he called this language SASL. It was initially just a blackboard language, but a colleague surprised him by implementing it in Lisp.

In 1976, Turner changed the semantics of SASL from eager to lazy, based on a lazy version Landin's SECD machine. Somewhat later in his career, he combined ideas from lazy SASL, a cut-down version of SASL called KRC, and the ML- originated Hindley-Milner type system to form a language called Miranda. And Miranda is one of the primary influences on Haskell.

So, this leaves out a lot of other languages such as HOPE and lazy-ML that also were developed in this space. But what's interesting to me is how all these languages, from ML to Haskell, are so strongly related to Algol and thus the Pascal, C, Java, etc. languages that are more familiar to industry.

That got a lot bigger than I intended; I hope someone takes some interest from the digression.

<comment><USER8> I thought that you might be one of my college profs, but then realized that he would never apologize for a long post.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Here's the path I've been following :

(ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm...

But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons!

My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing without quacks, it's MVC without objects and last but not least evan Czaplisky (the creaor) is the new Aaron Patterson (bright __and __fun!)

I'm all in (but yeah I've been bitten before)...

<comment><USER10> That's a lot of churn. You should stop and ask yourself if it's worth being on the cutting edge all of the time. Are you making better projects as a result of dropping "old" tech the moment something shinier comes around?

Everything has tradeoffs. Elm has no server side rendering, for example.

<comment><USER11> >Are you making better projects as a result of dropping "old" tech the moment something shinier comes around?

That's a lot of assumptions you are making there. Why "better projects" is the only metric considered here? Perhaps, OP utility in front end technologies is based on their learning. Or what's you reason to assume OP is dropping old tech "the moment something shinier comes around" and not after a reasonable period of exploration and trial?

Prototype.js was created in 2005, 10 years ago. Angular was released in 2009. React was released in 2013.

A lot of churn? Absolutely not. Someone staying current, perfecting their skills and knowledge? Good for them!

The HN trend of "hipster shaming" people trying new, sometimes esoteric technologies (even if it's only for the novelty factor!) is not conductive to constructive discussions and really has no place in the community named _Hacker_ News.

<comment><USER12> Unless building a taste for long lived techs as opposed to favoring the newest reinvention of old ideas is part of the learning process?

</comment></comment></comment></comment><comment><USER8> Most of these comments boil down to, "the food's awful and the portions are too small!". Someone wants better JS interop because Elm will be a small part of their stack; someone wants server-side and isomorphic apps because Elm will be a large part of their stack. Yes, the tooling and language features have a long way to go, and hopefully Evan will make progress while at NoRedInk. If you enjoy Haskell, you're not really Elm's target audience. If you hawkishly watch HN, you're probably not the target audience - the point is that it's sane programming for the rest of us.

</comment><comment><USER13> For those just getting started in FRP or whom may have not seen the presentations at StangeLoop:

\- [https://www.youtube.com/watch?v=Agu6jipKfYw](https://www.youtube.com/watch?v=Agu6jipKfYw) \- Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi)

\- [https://www.youtube.com/watch?v=1XNATGjqM6U](https://www.youtube.com/watch?v=1XNATGjqM6U) \- FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub)

\- [https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18](https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18) \- ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

</comment><comment><USER4> What's the best programming environment for Elm? I know there's a Light Table plugin for Elm, which I think is promising (in some ways they seem like a natural fit, whilst they started separately the direction of both was inspired at least in part by Bret Victor's ideas), but I wonder what other tools are being used to code Elm.

[https://github.com/rundis/elm-light](https://github.com/rundis/elm-light)

<comment><USER14> Sublime Text with Elm language support[1] does auto compilation and is plenty enough. It also comes with an extension to SublimeREPL[2]

[1] [https://github.com/deadfoxygrandpa/Elm.tmLanguage](https://github.com/deadfoxygrandpa/Elm.tmLanguage) [2] [https://github.com/wuub/SublimeREPL](https://github.com/wuub/SublimeREPL)

</comment></comment><comment><USER15> One of the things I found odd (or maybe just annoying) is how the Elm Architecture doc [1] keeps mentioning how you can cleanly model your code using modules. But the module system is about as primitive as you could imagine. The language would be much more expressive with ML's module system, and functors would relieve some of the pain of not having type classes.

[1] [https://github.com/evancz/elm-architecture- tutorial/](https://github.com/evancz/elm-architecture-tutorial/)

</comment><comment><USER16> Congrats! I hope one day to work for NoRedInk. Elm is a big reason why.

<comment><USER17> Please apply! We're hiring. :)

[http://noredink.com/jobs](http://noredink.com/jobs)

<comment><USER18> Remote US only or remote EU also?

<comment><USER17> We currently have remote developers from the UK, Germany, and São Paulo. (We do wantjunior hires to be in the office, though, to facilitate mentoring.)

We do a solid amount of pair programming, but remote pairing via ScreenHero is pretty sweet. :)

<comment><USER19> What would the requirements to apply for remote, "non-junior", position be?

<comment><USER20> There are more details for each position at our jobs page :)

[https://www.noredink.com/jobs](https://www.noredink.com/jobs)

</comment></comment></comment></comment></comment></comment><comment><USER21> I am a frontend developer and I wanted to learn Haskell for a long time. But I just can't wrap my head around it. Is Elm or Purescript a good way to ease into it? If so, which one is better?

<comment><USER22> One of the major goals of Elm is being easy to learn, both from a language and a library point of view. PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well. Elm is going to be much more approachable, and has a major focus on readable documentation and simple, straightforward concepts. It takes trade offs in language features in exchange, but is probably a better bet for someone who wants to get up and running quickly.

<comment><USER23> > PureScript is, for better or worse, no simpler than Haskell as a language, > with all of the power of Haskell but its complexity as well

Is it really no simpler? A few common complexity complaints i hear about Haskell that don't apply to purescript in order of frequency:

\- Haskell is lazy by default

\- has too many language extensions

\- records pollute global namespace

\- has fmap and map

\- $ is confusing

<comment><USER24> Except that Purescript uses the liberty from Haskell legacy libraries to become even more hardcore on algebra and categoric language. The relatively small user base also consist of experienced Haskellers, and the libraries tend to be quite advanced. For example, the "basic component" in the beginning of the Halogen tutorial already mentions natural transformations (which made me instantly intrigued, personally, but I'm one of those experienced Haskellers).

<comment><USER25> > to become even more hardcore on algebra and categoric language

In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude)

[https://github.com/paf31/purescript- preface](https://github.com/paf31/purescript-preface)

[http://pursuit.purescript.org/packages/purescript- neon/0.1.1](http://pursuit.purescript.org/packages/purescript-neon/0.1.1)

</comment></comment></comment></comment></comment><comment><USER26> As an experiment I tried rendering elm in the server. It's renders fine but I'm not sure that it doesn't re-render everything on page load.

[http://blog.overstuffedgorilla.com/server-side-elm-with- phoe...](http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/)

</comment><comment><USER27> When is back-end elm?

</comment><comment><USER28> These are some very exciting news for Elm and its community. Well done!

</comment><comment><USER29> Nice.

</comment><comment><USER30> "It's unprecedented for a company our size to hire a language creator," says R.Feldman of NoRedInk. [http://tech.noredink.com/post/136615783598/welcome- evan](http://tech.noredink.com/post/136615783598/welcome-evan) This might be true, but it's also a very smart marketing investment. I would have never visited NoRedInk otherwise, and it's the kind of company that would benefit immensely from general word of mouth discussion

</comment><comment> open-source-ux My comment is off-topic and likely to annoy people here, but I'll say it anyway: that entire page appears to have been generated in Javascript. If you view source, there is no HTML at all. What would a user with a screen reader hear if he or she were to visit that page?

If the page had been written in plain HTML and CSS, it might be about 10-15k in size. At the moment, written in Javascript, it's over 300K in page weight. So both inaccessible and bloated in page weight. This is really bad practice.

<comment><USER31> > What would a user with a screen reader hear if he or she were to visit that > page?

Well, the page still renders paragraphs and titles to good ol' <p>s and <hX>s, so i'd presume a screen reader would just read those things as the page content. Wouldn't it?

<comment><USER32> the screen reader needs to execute the javascript before it can read the tags. I'm not sure if they do that

<comment><USER33> Most do, thankfully, and have done for a while now :)</comment></comment></comment></comment>


The Top 6 Things You Should Know About LLCs - <AUTHOR> http://venturefizz.com/blog/top-6-things-you-should-know-about-llcs <comment><USER2> I was instantly curious to read this article because the choice to set up an llc vs. another entity has troubled me several times. I have read extensively about the various options and still walk away saying... "well my accountant says I should do llc" but I never understand WHY. I think that you could expand what you are saying here- like offering an llc vs s-corp explanation... or whatever else is relevant. You have a good start here but I would like to see this be a more robust post.</comment>


A$AP Learn Go (GoLang) - <AUTHOR> https://exlskills.com/learn-en/courses/aap-learn-go-golang--learn_golang_asap <comment><AUTHOR> This free A$AP Learn Go course is meant to be a highly-accelerated open program that's best-suited for people with a bit of background in software engineering to quickly pick up Go, learn the essential best practices, and hit the ground running! After this course, you'll be able to build basic Go applications in addition to lightweight webservers, highly-concurrent programs, and reusable libraries in Go that you can share with other developers!

Contributions welcome on GitHub: [https://github.com/exlskills/course-ASAP- learn-golang](https://github.com/exlskills/course-ASAP-learn-golang) :)</comment>


Ask HN: Software Testing Philosophy? - <AUTHOR> What is your philosophy for deciding if your software is well-tested?
Beyond the amorphous "do test reports inspire developer confidence?" I realize I don't know how to think about different testing thresholds.
I am taking over engineering at a young startup. Their approach to testing has been some automated smoke tests, and "90%" code coverage for unit tests. 90% seems too high for the speed tradeoff we have to make, but where to draw the line? Why 90% and not 84%?
Should we just try to find something that works and let production bugs be our guide? I would also like to explore other methods of testing I've never used, e.g. crowd testing, but I'm unsure how to fit that into my mental model of knowing  well-tested software when I see it.
Any insight or articles are welcome. Thanks! <comment><USER2> I've found 80% to be a good number for unit tests. BUT things like integration testing and end-to-end user story testing can really make all the difference, and complement a solid unit test suite. Also focussing on the numbers can leave you going down the wrong path and trying to shoehorn as much testing in as possible without giving any tangible benefit for the sake of a higher number.

As it's a young startup I would focus on writing tests for the business- critical use cases, which should allow a team the confidence to "move fast and break things" knowing comfortably that the day-to-day is still functioning as per usual.

Ultimately, I would say most code should be covered with unit tests, but functionality covered by automated integration/end-to-end testing. To me that would be 'well-tested'.

(and no flakiness!)

<comment><USER3> I broadly agree with this approach. Automated functional end-to-end tests may not pinpoint what line of code has an issue but they will identify there's a problem somewhere which is better than not knowing. Your product code and tests can be setup to help isolate where the source of the issue may be. Have developers continue to write unit tests but if you're big enough to it have one developer focused on writing end-to-end automated functional tests it will give everyone a sense of assurance at each release that nothing is fundamentally broken. If you're not big enough, like the parent comment said, try to do the major ones eg. sign up flow, core functionality.

Someone else made the point about using data effectively and I agree with that too. I've been involved with automated testing and tooling for a few years now and solid test reporting and test case management is something I advocate. I'm the lead dev and founder at Tesults ([http://www.tesults.com](http://www.tesults.com)) - try it and push your results data to it and house your manual test cases. There's a free tier and if you contact me I'm happy to expand it. Basically if you set up your CI system to run your tests regularly, or even if you schedule them to run regularly (E.g. nightly/daily) then having something like this boosts your ROI because you can track history easily, link bugs, and do things like get indications about which tests may be flaky.

We don't know exactly how small your team is, it may be you have to rely on manual testing if there's no one to spare but I'd try to move some of your end-to-end to be automated sooner rather later if you end up growing otherwise you'll make testing a bottleneck to releasing, full regression testing of even a moderately complex application can end up taking days.

<comment><USER2> Why would I want to link tests to bugs? Or track the history of tests? Or assign someone to a failing test? I've found they either fail or they pass, and you find why they failed and you fix the failure.

Just genuinely curious about the purpose of this software, as it's quite expensive, and most CI tools provide enough information for history / scheduling etc.

<comment><USER3> If you don't see it as something you need, you probably don't ... at least not yet.

Ive been an Engineering Manager and Head of Quality Engineering and when you end up with hundreds or thousands of test cases, either in one product or service or across many, managing the output of testing becomes a challenge. There may be low priority regressions that you want to fix later and create bugs for and link to failing tests so you know you're waiting on those fixes before you expect the tests to pass.

If there is a problem with a test itself then assigning it to a team member to fix is useful. Tracking history helps identify flaky test cases - they're automatically highlighted as being flaky. Consolidating tests from several sources helps understand the overall health of a project.

If you're maintaining a product or service that goes through a lot of change and there's say 10 people or more on a team managing all of this becomes increasingly difficult. With respect to pricing it's free to try and $25/month per target so not particularly expensive.

</comment></comment></comment></comment><comment><USER4> What I do is classify parts as either prototype or release.

Prototype is code that is built for the sake of proving something - it might be to gauge user behavior, or convince investors/customers you can do this cool stuff. It might be because it's hard to plan something and easier to hack it together.

Prototype code is built disposable. You can throw it away and replace it with an optimized thing later, and they're decoupled enough to be disposed. For pre-PMF startups, nearly 100% of code is prototype.

For prototypes, I write tests, but it's a manual checklist. It's also usually user behavior focused, such as "user tries to upload 15 images from third party photo gallery and gets an error limiting them to 5 images at a time".

There's some point where it's more efficient to write tests than keep pressing buttons.

Once you decide a feature is concrete (probably someone is paying for it), then you can refactor that and do some TDD on it.

</comment><comment><USER5> Disclaimer: context is king, we don't know your business so you'll get an "average" answer.

Google and read about the Modern Testing Principles [1], it's a set of principles and a community around it (join the Slack channel through the same link) that tries to bring change to the " test reports inspire developer confidence" state of mind. There's not a lot of tangibles around it yet but it's a good start.

As for coverage percentage, there are multiple papers showing that (usually) anything above 80%-85% does not contribute to the quality of the product. Also remember that unit test are not great at finding "good" regression bugs, especially those subtle bugs related to timing, concurrency or external resources (e.g. your DB).

I can throw dome ideas but you'll need to be more specific for them to be useful-

\- Use Data, from CI tests through just-before-big-release tests to production bugs having more Data and better ways to utilize it will help you find problems earlier and solve them faster.

\- Don't be afraid of some level of manual testing, sometimes it's the most cost effective solution especially for start ups. Mobiles are the best example, it's very costly and difficult to build a stable test environment especially if you want to have good phone models coverage.

\- Cover bottom up (aka "The Test Pyramid"), have more unit tests, a bit less integration tests (contract tests, sub sets of modules where the rest is mocked), have good but less API tests and finally have only a handful of E2E tests and even less UI tests.

\- None of the above is set in stone though if it works for you, for example if your UI is simple and stable enough go ahead and use it as your main interface.

Finally remember that testing is hard and knowing that you have good results is even harder than for your actual product, so iterate and learn as you go.

[1] [https://www.angryweasel.com/ABTesting/modern-testing- princip...](https://www.angryweasel.com/ABTesting/modern-testing-principles/)

</comment><comment><USER6> On the frontend part of things, I tend to test the user behavior and not functions (unless critical).

The coverage tends to revolve around ~75% but that's not a number I actively think about. Instead I think about it in terms of interactions, possible errors etc..

<comment><AUTHOR> Meaning you focus more on integration/e2e testing over unit tests?

That jives with my own inclinations. I'm ok with much lower unit test coverage levels on the UI where I can use something like Cypress or Robot over just testing functions.

<comment><USER6> Exactly, pairing testing-library and jest make these kind of tests super easy. No need to spin Cypress

</comment></comment></comment><comment><USER7> I find this question useful: What is your objective evidence that the software does what it's supposed to?

Note that there's no "percent coverage" whatsoever in that question. Instead, it's a question of what behaviors of your code you need to test.</comment>


The 0.00% Yield - <AUTHOR> http://www.avc.com/a_vc/2010/03/the-000-yield.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+AVc+%28A+VC%29 <comment><USER2> I don't think investing in municipal bonds is a very good idea right now. If you look at the problems of pensions around the country counties and cities are going to declare bankruptcy unless unions back off their demands which they probably won't. All around the country politicians are putting their heads in the sand hoping that these problems will just blow over and hope for another housing boom.

Right now holding onto cash is probably the best bet. I'd expect deflationary pressures to continue despite the federal reserve's inflation. They haven't started dumping money out of planes yet but they will if the default rate starts to climb much more.

The rating companies who assign those AA and AAA are useless as well. Recently Moody's Investors Service threatened to lower Iceland's debt rating to junk. Why isn't it there already? It's absurd.

Right now I prefer to invest my money in business opportunities and hold onto as much as cash as I can. It seems like risk out there is extreme when interest rates are 0%. How can you judge what's actually going on in the economy when the price of money is so distorted? We're facing a serious shortage of capital right now and the notion that a 0% interest rate is the way to raise more is insane.

Anyway if these municipal bonds explode on you I don't think anyone is going to bail you out.

<comment><USER3> It's not sexy, but if you have the space for it, picking up a long term supply of necessities isn't a bad place to put your money. Various sales and firesales happen, picking up canned goods, toiletries, and so on is a decent hedge against inflation and the bulk savings from buying a year's worth is probably going to exceed anything you'd get on the market. Of course, this is more for people with low tens of thousands of cash around, not quite as applicable to people with hundreds of thousands and higher in cash trying to figure out what to do with it.

But if I had a house, I'd go pick up a year's supply of the basics whenever I saw them come moderately to deeply on sale. It's going to save more money than you'd make on any bond in the near future.

<comment><USER4> For this to be true, you'd have to imagine the investment as at least 1 year, wouldn't you agree? So probably several years? And you'd have to purchase goods that would last that long.

The reason I say that, is that you can still find 3% FDIC insured savings and money market accounts (look at your local Credit Unions). For me to get a better return on canned pears and chicken stock, we'd need real consumer price inflation > 3%. If you take a look at the consumer price index and remove energy costs, it's been quite some time since we've experienced 3% annual inflation. (Removing energy costs is the key here).

Now.. if you hold it for 3 years, it would probably be a no brainer. As long as you don't mind actually eating what you bought over those years -- eg no 40 cases of Peanut Butter!

<comment><USER5> I think the issue is not only inflation, but the price fluctuations that happen all the time, that are much bigger. If one day, at the supermarket, you see toilet paper in a two for one offer, and you buy a whole year of supply, you'll be saving 50% over the year. I think the goal is not playing against inflation but to play against the stock issues of supermarkets (if you have a way to have the stock locally).

</comment></comment></comment></comment><comment><USER6> _That's why this "hyper low" rate environment is dangerous. Because it won't last and when rates start to go up, the market will stall or even decline._

Excellent point. Of course, the government knows this, and will thus be terrified to raise rates for a long time to come. Any raising of rates will quickly cut short the recovery, and then the government will panic and lower them again. Welcome to Japan!

</comment><comment><USER7> Here in NJ, the Governor is swinging blindly with an axe. If much of his cuts get passed, there is a real possibility some local munis will actually go bankrupt... along with their bonds. While this is speculation right now, it does seem that either counties are going to go broke or the State is.

There was also a story not too long ago about foreign investors forgoing the usually favorable T-bills because there were considered too risky. I am not quite sure what that really means. Here it is at WSJ: [http://online.wsj.com/article/SB3000142405274870480420457506...](http://online.wsj.com/article/SB30001424052748704804204575069172269719754.html)

Now, about this 0.00%. I firmly believe that we are in a time vacuum, by design. You see, consumers form the foundation of our economic system. They are the engine. By keeping interest rates across the board obscenely low, we are providing much needed time for them to pay off debts. Once the bulk of the consumers become stable, then the rates should rise. Until then, the front of the caterpillar has to wait for the back to catch up!

<comment><USER8> _If much of his cuts get passed, there is a real possibility some local munis will actually go bankrupt._

Yes, and I hope that happens. Just like the fed bailout of banks and of GM were wrong, we need to let bad institutions die. How else can society learn what works and what doesn't?

 _By keeping interest rates across the board obscenely low, we are providing much needed time for them to pay off debts._

Interesting thought, I hadn't considered it that way. The question is whether it's worth the cost.

</comment></comment><comment><USER9> We've been here before.

After the implosion of the Japanese asset bubble in the early 1990s, Japan set effectively 0% interest rates in an effort to stimulate the economy. This led to what's known as a 'carry trade', where investors would borrow free money from Japan, and then invest it in higher-yield investments abroad.

After the collapse of the American equity markets in 2001, higher yields were hard to come by. So, all that liquidity went looking for a new home and largely landed in mortgage-backed securities, credit default swaps, and their associated derivatives. Of course, a lot of these investments yielded only a few percent, so investment funds would often leverage up 20x-30x to get a respectable rate of return.

When those investments started to unwind, they unwound _hard_. The end result was that the Japanese carry trade contributed to the eventual devastation of the American financial system. Which, ironically, means that we now have 0% interest rates. The great cycle continues.

Now, the Japanese carry trade certainly isn't the whole story, and there's a lot of other factors that were in play. However, there's no doubt in my mind that the BOJ's 0% interest rates helped us dig the hole that we find ourselves in today.

</comment><comment><USER10> ProShares UltraShort 20+ Year (TBT) is an ETF that moves inversely with US Treasury bond prices. In other words, if interest rates rise then you make money. I think it's getting harder (although not impossible) to envision a future in which we won't have substantially higher interest rates. Might be a worthy add to portfolios if you're concerned about this.

BTW, watched I.O.U.S.A. this week (<http://www.iousathemovie.com/>). If you want to have the crap scared out of you about the impending issues with the debt that's the movie to watch.

<comment><USER11> I do prefer reading about this stuff and watching movies like the above over horror flics. :D

<comment><USER10> Some might argue that the documentary above is a horror movie.

</comment></comment></comment><comment><USER12> The article left a lot unsaid (granted, readability would've been sacrificed to cover everything sufficiently). Here are some thoughts on a few of those missing things...

In real terms, the investments quoted actually had a _negative return_ during 2009 (nominal interest rates mean little outside of an apples-to-apples comparison). With the unadjusted CPI rising 2.7%, those dollars can now buy less than they could one year ago.

The negative return actually suggests a lot about the economy (see Japan's lost decade -- <http://en.wikipedia.org/wiki/Lost_Decade_%28Japan%29>). Here are a few of the conclusions one might draw:

\- There is considerable fear remaining among investors.

\- The government is encouraging risk taking and investment, while discouraging savings.

\- US treasuries represent the risk-free rate in many traditional financial models; the traditional models are either changing _OR_ returns that seem sub- optimal when compared with yields from 3 years ago actually have significant amounts of risk embedded in them.

\- Banks & local governments can borrow at very low rates, thereby strengthening their balance sheets, making for a potentially attractive investment opportunity (this is, of course, dependent on how wisely you expect them to allocate the capital they borrow).

\- The implications are far reaching. This is only the tip of the iceberg.

Take away: Look for inefficiencies and exploit them.

</comment><comment><USER13> Paypal money market is paying 0.04%.

<comment><USER4> Local credit unions here are all offering 3% checking accounts on balances up to, usually, 25k to 50k. It means your cash is spread out but that's not really a bad thing.

</comment></comment><comment><USER14> > _Regardless of whether or not my bank or any bank is taking advantage of its > customers (and I am not sure they are), this zero interest rate environment > is worth thinking about._

Is the bank paying large bonuses (UK banks are paying bonuses bigger than their profits) if so they can afford to pay their creditors for giving them money to use.

</comment><comment><USER15> My Vanguard money market is yielding 0.01%. Ouch.

<comment><USER16> FYI, a HSBC Advance savings account gets you 1.1% at the moment

<comment><USER17> And, since it's FDIC insured, it's as safe as treasuries as long as you keep below $100k in the account (or was it $250k? I don't remember.)

</comment></comment></comment><comment><USER18> Your Current Account Balance is: 0.00 IDR (Real Credits)

Your Current Playable Balance is: 0.00 IDR

</comment><comment><USER19> I don't even waste my time reading this guy's blog anymore. He's illustrated to me that he is corrupt and supports revenue models that are fraudulent ripoffs of his startups' customers.

As hackers who want to create a better web, we should stop promoting the words of people like him and jc and others who give the internet a bad name. We should just banish them from the web -- they make it worse for everyone but themselves and their uber-elite little group of scammers.

<comment><USER20> He's got some money, and he wants to safely invest them without too much risk so he buys bonds. Then he states his opinion on the risk of the historically low rates we're experiencing right now.

How exactly is that corrupt and supports revenue models that are fraudulent ripoffs of his startups' customers?

<comment><USER19> It's favorite investment, Zynga, is a notorious ripoff artist and he has supported them before and after it was made apparent that their revenue model was a scam.

<comment><USER11> They had a small fraction of revenue from a questionable source (scammy sign ups). It was corrected immediately, Mark Pincus is an interesting guy, but I don't think of him as a scam artist. I think of him as a founder who wants to control the destiny of his company through revenue.

<comment><USER19> I suppose my definition of "corrected" is different from yours. My definition of corrected means making the people you have wronged whole again. They took money from people and kept it and would have continued taking money from people in the same manner if Techcrunch hadn't have been so vocal about the zynga scam.

There's a video floating around of Mark Pincus telling a group of startups that it's okay to rip off people as long as you're making money.

It's atrocious behavior and I don't believe anything about it is at all acceptable. Until the situation really _is_ corrected, this dude will have no respect from me.

<comment><USER11> There's plenty more information out there about Mr. Pincus. He's not the monster he was made out to be.</comment></comment></comment></comment></comment></comment>


The ultimate productivity suite shootout for OS X and iOS - <AUTHOR> http://thenextweb.com/lifehacks/2012/11/03/the-ultimate-productivity-suite-shootout-for-os-x-ios/ <comment><USER2> I'm starting to get tired of "shootouts" where nobody wins. Come on. Be a mensch and pick a winner.</comment>


Ask HN: What to do when someone accessed you credit report and SSN? - <AUTHOR> How to save your personal information after its leaked. <comment><USER2> Get a credit freeze at all the services. That's a first-line defense.

</comment><comment><USER3> Use a identity theft protection.</comment>


Show HN: Hacker News full text rss feeds for your feed reader - <AUTHOR> http://feeds.feedburner.com/feedsapi/BwPx <comment><USER2> Unfortunately it doesn't contain links back to the HN comments which is often more interesting than the article itself.

</comment><comment><AUTHOR> This was generated using <http://www.feedsapi.com> and feedburner

</comment><comment><USER3> You can also use fullfeed.net. It attempts to extract the content of the article from the URL in the feed.

</comment><comment><USER4> I prefer headlines with content available on click. Likewise no point without access to comments...</comment>


I Never Said Snowden Is a Hero; He Should Be Tried - <AUTHOR> http://online.wsj.com/news/articles/SB10001424052702304347904579310463077857076 <comment><USER2> The biggest problem I have with his statement is that it would be almost impossible for Snowden to receive what most people would consider a fair trial.

He likely wouldn't be allowed to argue his motivation and intention for the leaks, make the case that his actions contributed significantly to vital public knowledge about government activity, or that his leaks didn't result in any harm to the US.

<comment><USER3> Furthermore, AFAIK he wouldn't be tried in the jurisdiction in which he committed the crimes (Hawaii) and instead would be tried in the backyard of the intelligence community (Virginia), where the makeup of any jury would likely be members of the IC community or greatly sympathetic to the IC way of doing things.

</comment></comment><comment><USER4> > I have not argued, as you allege, that Mr. Snowden is a hero. I have stated > that history will decide.

This is moral cowardice and political pragmatism at its finest [1]. There is no "history" to decide anything only people who live in the future, far removed from the consequences of making a stand or judgement now. You know how the saying goes... with friends like this...

In my judgement, not only is Snowden a hero but he was wise to leave the country as a fair trial seems hopeless, as throwaway420 points out. Given the lack of support for Snowden and the general apathy toward dangerous NSA and other govt programs I am not optimistic.

[1] To be clear, I do not consider pragmatism to be a virtue. Political pragmatism means acting without reference or guide to any principles whatsoever and acting on the range of the moment. There is a distinction between being politically _practical_ , i.e. accepting what is and is not politically feasible, and jettisoning your principles when confronted with a threat to those principles. What does Rand Paul stand for? Nothing.</comment>


You don't need an MBA to become a product manager - <AUTHOR> https://hackernoon.com/forget-the-mba-heres-the-fastest-way-to-become-a-product-manager-b3a230a7c055#.1tjoph52q <comment><USER3> Related Note: Personal MBA by Josh Kaufmann a helpful read. Here's his presentation @Google > [https://youtu.be/fp8H8EMm464](https://youtu.be/fp8H8EMm464)

</comment><comment><USER4> You don't need an MBA to become anything. In fact, it often makes it harder.

<comment><USER5> Very true. People forget that the MBA was invented back in the early post war era when large corporations identified a need to train new managers. It would allow a broad range of skills to be quickly picked up by a specialist moving to a general management role. You can learn the same information nowadays using books and online resources in a way that was harder to do back in the day. Doing an MBA before you have worked in actual junior management for a few years has always struck me as kind of odd. Doing an MBA straight after your first degree is strange because how can you actually relate the issues of people management when you have never managed a single person? Bizarre.

</comment></comment><comment><USER6> Definitely agree that you don't need an MBA to become a Product Manager - <USER2> training for Product Management can be quite different to most of what you learn in more traditional Business Administration courses.

That said, I do feel that one can benefit the other - MBA's teach a lot about practically running a business, background learning that can really assist when running a product development and management cycle or team, even if only for the fact that it gives you a better ability to understand and build relationships with other areas of the business.</comment>


Ask YC: startups around remittances - <AUTHOR>

Sending money home is a 60 billion/year, inefficient market. I live in Colombia so I've been thinking about this for a while. Wondering if there are startups out there that are taking interesting approaches to this, or thoughts on how to take on this market. Combining with mobile could be interesting as well. <comment><USER2> Probably requires quite a bit more financial/legal hacking than technical. That said - I agree that it seems like a real opportunity.

The entire "payments industry" boggles the techie mind - Visa, MasterCard, and Western Union (to name a publicly-recognizable few) enjoy very high ROI having a nearly trivial (for a serious organization) technical problem to solve.

<comment><USER3> It's trivial if and only if you ignore fraud, which contributes a huge amount of technical and legal complexity.

Read the Paypal interview in Founders at Work. It wasn't market or technical reasons which killed their competitors, it was their inability to deal with fraud.</comment></comment>


Typography App for iPhone - <AUTHOR> http://typographyapp.com/ <comment><USER2> One of only a handful of programs I've seen on the iPhone that hyphenate properly. I wish the typeface specimen list was larger and included other, common typefaces (for example, Bembo, or a wider selection of sans serifs); those are some of my favorite things to peruse. There's quite a few odd little things thrown in that are entertaining--the Mac keyboard layout, for example.

It's not going to replace a specimen catalog, but might be useful for someone with a designer's eye who wants to learn more about the typographic side.

</comment><comment><USER3> Is this available in a convenient desktop format? I don't do web design on my phone but I _do_ do it on my computer ;)

<comment><USER4> Yeah, but if it were a desktop app, it wouldn't have magic App Store juju and would lose all novelty. :) I'm buying it though.

</comment></comment><comment><USER5> This looks like a cool, interesting, and useful app. Why _aren't_ there more apps like this for the desktop? Is it because the Iphone is a cooler platform?

Also, typographic reference books can double as art books, so I wonder if designers will use this app and apps like these instead of books?

<comment><USER4> Art Director's Toolkit is a great app for the Mac whose feature set has a _little_ intersection with this app's: <http://www.code- line.com/software/artdirectorstoolkit5/></comment></comment>


Mystical way to transform data into reusable view in Swift - siam-biswas https://github.com/siam-biswas/Transfiguration <comment> siam-biswas A solution for creating data driven iOS applications with minimal block of codes.</comment>


Show HN: Who is on Tonight? - A one stop website to see late night guest lineups - <AUTHOR> http://whoisontonight.com/

<comment><USER2> Cool tool. If you're scraping this, maybe it would be easy to scrape the time each show airs as well, and sort by that?</comment>


New Mexico observatory closure stemmed from FBI child porn probe - <AUTHOR> https://af.reuters.com/article/commoditiesNews/idAFL2N1W51VK <comment><USER2> "In August, they began speaking to the chief observer at Sunspot, who said he found a laptop running in several empty offices over the last few months.

He told the feds what he found on the desktop was "not good," and that it appeared to be child porn.

The search warrant states the feds then monitored all the IP addresses and found the exact time child porn was being sent out.

It matched only one employee: a janitor.

Once that janitor realized his computer was no longer there, the director says he "feverishly started looking through the facility," started making comments about "lax security at the facility," said it was "only a matter of time before the facility got hit, and he "believed there was a serial killer in the area" and that killer might enter the facility and execute someone.

The director says that's when he became concerned for his personal safety, and along with the agencies that operate the facility decided to evaluate it and shut it down. "

<comment><USER3> "but the whole facility? .... for 11 days?"

\- future Congressional House Budget Committee hearing

<comment> King-Aaron Maybe they were under the impression that he could have left an explosive device in or around the facility - going by the above comments - and closing the facility for that time was required until they were 100% sure that no device existed?

One explanation I suppose.

</comment></comment></comment><comment><USER4> I'm sure this is what it is. But... if it actually _was_ aliens, this will certainly make people totally dismissive!

<comment><USER5> Definitely aliens, this is a cover up

<comment><USER6> Maybe the janitor was the alien?

</comment></comment></comment><comment><USER7> Weren't people reporting that they were seeing BlackHawk helicopters around the installation. Seems awfully overkill for a child porn probe.

<comment><USER8> _Weren 't people reporting that they were seeing BlackHawk helicopters around the installation._

A lot of military aircraft were relocated around the country because of the hurricane.

Plus, the average person couldn't tell a Blackhawk helicopter from a Blackhawk hockey player.

<comment><USER9> You are exaggerating, but, yeah, most civilians don't know the difference between a Bradley fighting vehicle and a tank.

When I was a kid, my cousin and I would lay in the grass in the front yard and watch the house across the street and basically spin the slightest shadow or bit of wind or what not into some tall tale for entertainment, being very serious and like we were actually onto some X Files style mystery and had the detective skills of Sherlock Holmes.

<comment><USER10> > yeah, most civilians don't know the difference between a Bradley fighting > vehicle and a tank

Most ancient Jews couldn't have told you the difference between whales and fish, either. Some distinctions just don't matter most of the time:

[http://slatestarcodex.com/2014/11/21/the-categories-were- mad...](http://slatestarcodex.com/2014/11/21/the-categories-were-made-for-man- not-man-for-the-categories/)

<comment><USER9> That's true. And irrelevant. The point is that we have statements that may not be reliable.

</comment></comment></comment></comment></comment><comment><USER11> Okay, but what's the _real_ reason?

<comment><USER12> Aliens downloading child porn.

<comment><USER13> Maybe it was aliens _uploading_ child porn. To frame people who were trying to expose them. ~

</comment></comment></comment><comment><USER14> That's strangely pedestrian, though if you didn't know who was the suspect, I suppose closing down the entire place is the best course of action to prevent tampering.

</comment><comment><USER2> Anyone have a link to the unsealed documents?

<comment><USER5> Alex Jones is on it!

</comment></comment><comment><USER15> And here I was thinking it was aliens.</comment>


Lavaboom is shutting down - <AUTHOR> https://lavaboom.com/ <comment><USER2> I can't help but wonder how much government influence had on this...</comment>


The Curious Case of the Longevity of C - <AUTHOR> https://www.ahl.com/ahl-tech-the-curious-case-of-the-longevity-of-c <comment><USER2> I've always like the description of C as just being "raw memory, but with syntactic sugar."

I think C is still so pervasive for 2 simple reasons (I might be wrong):

1) It's a small language. Compared to many newer languages (Swift, modern C++, old C++, Objective-C, Java), it's quite tiny. The language itself can be learned in short time. (Which is deceptive, because properly using what you have learned takes longer than a short time).

2) It's fast. It's just direct memory access, direct and explicit hardware manipulation. And whether justified or not, there is a very large portion of the developer community that remains obsessed with speed. I see it all the time, even when speed isn't not going to matter enough to justify C. I often see people going way out of their way, making their work much more time- consuming, because of their everlasting pursuit of writing the fastest damn program they possibly can.

<comment><USER3> The thing I love about C is it almost always does what you want fast, but you are never certain. No matter how much you think you know C, there is always some new edge case to experience. C is exciting.

<comment><USER4> I completely disagree with this. C is the only language I ever used I felt I had mastered. Sometimes I needed to check things in the spec or pause to consider the C99/C89 discrepancies, but essentially I knew everything about it after just a few years of daily use.

I've never felt that way with Python, JS, Ruby, Java, C++ or any of the other languages I've used. They are at least 10X more complex in terms of primitives and non-trivial interactions.

<comment><USER5> C is deceptive, though. It encourages a mental model of high-level assembler, but it's an assembler for an abstract machine, not the actual machine; and compilers are increasingly making the difference evident.

<comment><USER4> Maybe many people do have incorrect assumptions about C, but I wouldn't say it's deceptive. The abstract nature becomes plain when using an optimising compiler for a while. And they have been the norm for at least 20 years.

<comment><USER6> Optimizing compilers have been around for yonks, sure, but I think taking aggressive advantage of UB is relatively recent. See e.g. Regehr in 2012 [1] :

> _The current crop of C and C++ compilers will exploit undefined behaviors to > generate efficient code [...], but not consistently or well. It's time for > us to take this seriously._

[1] [https://blog.regehr.org/archives/761](https://blog.regehr.org/archives/761)

<comment><USER4> I see your comment is grey, so I guess people down-voted you and maybe you want to know why. It's because you are wrong. Compiler optimisations have always been relevant; even in the 90's they would omit entire blocks of code or reorder operations for example.

I assume now it's more aggressive, because undefined behavior should never be relied upon. That's the point.

<comment><USER6> I think you're reading me as saying something much stronger than what I actually meant. When we talk about C being "deceptive" we don't need to consider optimizations that respect the as-if rule. (Well, maybe when looking at the C->asm mapping or trying to benchmark, but that's not the level most people are working at.)

The trend toward UB-based optimizations seems significant to me because they can and will take a bunch of C code which _looks_ superficially reasonable, and which _used_ to do X as intended, and suddenly (and perfectly legally) make it start doing Y instead. I assumed that's what barrkel was alluding to above.

And yes, I'm sure there are old optimizations which will also do that, but basic things like hoisting and reordering and unrolling and dead-code elimination don't fall into that category.

<comment><USER4> _> And yes, I'm sure there are old optimizations which will also do that_

So then it's not new behavior.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> _Add to this the disastrously central role that C has played in our ongoing computer security nightmare_

One sees plenty of news on the downsides, but on the other hand the lack of security has also enabled console homebrew, iOS jailbreaking, Android rooting, and a bunch of other creatively liberating activities which involve doing something not officially sanctioned. It's worth pondering whether we would be better off, had everyone switched to something much "safer" (maybe even with formal verification) a long time ago. I think it's debatable.

<comment><USER8> Feels like the old claim that Macs didn't catch viruses like Windows does. Turned out that no one bothered to make viruses for something no one uses. In other words the "security nightmare" is as much due to its popularity and ubiquity as it is to do with any particular detail of the language itself.

Maybe the most secure language is the one so esoteric, and complex, and incomprehensible that no one uses it to make anything and therefore is never exploited.

<comment><USER9> That lie? They on the other hand recommended that people install anti-virus programs till that got pointed out. [https://www.cnet.com/news/apple-suggests- mac-users-install-a...](https://www.cnet.com/news/apple-suggests-mac-users- install-antivirus-software/)

I hate that it is okay to lie. Of course any OS can have a virus and malicious code. It runs code.

</comment></comment></comment><comment><USER10> > _We rely on Python which is written in C89, a standard older than many of > our developers._

Python ≥ 3.6 requires (some features of) C99.

> _Perhaps the reluctance to move to a more 'modern' C is that even C99 can't > legally buy a drink_

Perhaps it's because MSVC didn't fully support anything newer.

Source: [https://www.python.org/dev/peps/pep-0007/#c-dialect](https://www.python.org/dev/peps/pep-0007/#c-dialect)

<comment><USER11> Yeah... good luck taking a newer version of Python an compiling it on Visual Studio 2012. I had to jump through hoops even to get 2.7 to compile and wound up abandoning it because it caused problems down the line with ctypes.

<comment><USER12> VS2012 is quite pre-historic, we already had 2013, 2015 (with three updates) and are now on the third 2017 update.

C99 support was added in VS2015 to the extent required by C++14, similarly C11 support was added in 2017 to the extent required by C++17.

<comment><USER13> > VS2012 is quite pre-historic

You don't work in the enterprise domain which is VS's core market, do you?

<comment><USER14> Still on Visual Studio 2010 here... The pain is that _everyone_ has to move at once due to the way the project files are upgraded when you open them in a newer version.

<comment> T-hawk Microsoft fixed this after 2010. VS 2012 and onwards can open a 2010 project file with no changes. A mixed population of Visual Studios from 2010+ can work on the same project file.

<comment><USER14> That is actually extremely good to know. Thanks for the information!

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> "C is the desert island language". see [http://crypto.stanford.edu/~blynn/c/intro.html](http://crypto.stanford.edu/~blynn/c/intro.html)

For me, Linux is a huge development environment dedicated to C programming. Chapter 2 and 3 of manual pages gives C api. C gives the most direct access to kernel. IMHO we should try to find a replacement for C and the first target for this language should be linux kernel. If you can conceive a language that Linus Torvalds accepts, the rest of the planet will follow ;-)

<comment><USER16> > If you can conceive a language that Linus Torvalds accepts

Good luck!

</comment></comment><comment><USER17> In my mind, C very closely resembles what's going on in my mind's model of the computer. I "think" in C when I'm thinking about an algorithm. It's almost exactly the same as the fake language people sometimes use for explaining an algorithm. I think this property contributes towards the popularity. No "artificial" abstractions like classes, templates, modules, imports etc. Just think of the first step you would do to solve a problem, and write it. Then think of the next step, and write that. And you get fast, portable code that produces tiny binaries! What more do you need?

<comment><USER18> Thou shall embrace the true power of functional programming

</comment></comment><comment><USER19> I think that during the nineties the focus switched from compiled, small runtime, unmanaged language to higher level, garbage collected, "big runtime" languages like Java or the scripting languages. One notable exception being C++ but its complexity and the difficulty to interface it with other languages meant that it couldn't completely replace C.

So for a long time if you wanted to do low level, fast, small, reasonably portable code you simply didn't have much of a choice.

Rust is the first language in a long time that I think could end up replacing C in all of its use cases but there's still some way to go. The main difficulty I can foresee is that like C++ it's significantly more complex than C and harder to interface with other programing languages (you end up making an unsafe C interface).

I think C is here to stay. The billions of lines of C code out there won't be rewritten in a fortnight.

<comment><USER20> Rust would need severe changes to replace C where C shines, being able to cobble object files together into something that works. I can run malloc from userspace and 14 different previous invocations of a C compiler later I have registers with my parameters in touching page tables.

ABIs, APIs etc have to be able to propagate size and type information that is basically how C defines them if you want anything to work (pointers, integers, floats).

C embeds a remarkable amount of cross-object-file information about a function just with 'int f();'. We know the range of valid values, we know how big the object is, etc.

Rust literally has none of these mechanisms and likely never will, interfacing Rust to other Rust, such that you will get any benefit at all from using it would require megs of type, scope, size, etc information to crawl across the calling convention.

There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have or plan to have anything like this yet, and it'd need to be 20x more complicated.

If you get rid of Rust's magic about being able to remove guards and checks by infering things about the data to make it conform to calling conventions instead of using types, you have just invented C.

<comment><USER19> Well, you get what you pay for. Rust can call and expose C-style ABI functions natively so you can always do what C does. If you want a safer Rust API you can also have that but it makes interfacing with 3rd party code more difficult.

I disagree somewhat with your assertion that:

> C embeds a remarkable amount of cross-object-file information about a > function just with 'int f();'. We know the range of valid values, we know > how big the object is, etc.".

First of all this is not embedded in the object file but rather in the header, Rust doesn't need that. The object only tells you the name of the symbol and that's about it. In particular that means that the C linker can't detect ABI mismatch if the prototype of a function or the layout of a struct changed, as long as the symbol is found it'll link just fine.

Furthermore even with the header available a lot of the time C prototypes are not sufficient to know how to use a method. Take for instance:

        sometype_t *some_function(someothertype_t *param, int flag);

Is param an input or output parameter? Do I own the return value or is it allocated by the function? Or maybe it's just a member of param so it has the same lifetime? I know that flag is an int but that doesn't really tell me which are the valid values I can put in there. In Rust function signatures tell you all of that and it's enforced by the compiler.

So yeah, there's a significant overhead in Rust here, but it's for a good reason IMO. It does make it harder to make quick hacks with the linker though.

> There's a reason C++ names look like CintFuncf!!!@34$902, Rust doesn't have > or plan to have anything like this yet, and it'd need to be 20x more > complicated.

Are you talking about name mangling? Rust does that too but that's not really the same issue, it's just about generating unique "flat" names for objects that include namespacing and generic info. Like if you have a "fn foo<T>(t: &T)" and you instanciate it with T = i32 and T = String you need to generate two symbols. C doesn't need that because it doesn't have namespaces, generics or overloading.

<comment><USER21> _> C doesn't need that because it doesn't have namespaces, generics or overloading._

Overloading as in operator overloading? Because I don't see how that would affect symbols.

Though along with namespaces and generics, there is one thing that Rust also bakes into symbols: versioning information. This is how, in the case of deep dependency graphs, it's possible for a finished binary to include multiple copies of the same library in the event that multiple versions are transitively depended upon. But that doesn't add any complexity to symbol mangling on its own, because if you already have namespaces then you can just treat it as a namespace that only the compiler can see.

<comment><USER19> No I meant parameter-based function overloading like C++ has (or is it not the wrong term? I forget).

So like:

        int do_something(int param);
        int do_something(double param, char *param2);

I don't see how you can avoid some form of name mangling since obviously you can't just define two duplicate "do_something" symbols.

<comment><USER22> Rust does not currently support parameter-based function overloading, and there are no plans to in the near-term, if ever.

(This isn't the only way to end up with duplicate symbols, just trying to make it clear that this specifically won't be a problem with Rust.)

</comment></comment></comment></comment></comment></comment><comment><USER23> C works everywhere, and everyone knows C, or can learn it in a couple of weeks and get coding. This is a hard combination to wholesale replace, but then not even Rust aims to do that. Instead it aims to chip away gradually, and I don't see why it can't do _that_ .

<comment><USER24> > C works everywhere, and everyone knows C, or can learn it in a couple of > weeks and get coding.

You hit the nail in the head. The go-to tutorial and reference book of C is «The C programming language» by Brian Kernighan and Dennis Ritchie, which provides a complete and very thorough description of C and its standard library in less than 260 pages. That's unbeatable.

As a comparison, the go-to book for C++, «the C++ programming language» by Bjarne Stroustrup, goes beyond 1200 pages and doesn't cover some fundamental aspects of C++, and even «The Rust Programming Language» by Steve Klabnik and Carol Nichols, a book on a programming language which was designed to eat away C's market, is over 400 pages.

This speaks volumes on the effort required by anyone to get on their feet and be productive with these programming language.

<comment><USER22> Different books have different goals. K&R is short, but the standard is ~700 pages. The Rust book is over 400 pages, but contains entire chapters of just "let's build a project together." There's no spec yet like C has. Writing styles differ dramatically, K&R are more concise than I am, and don't dive into some details as much.

Then, you may also consider the framing of "simple" vs "easy", they're not the same thing. And that's even if we agree that C is simple in the first place, which I personally consider not true.

Basically, I don't think that comparing page counts of random documents says anything meaningful about language complexity.

<comment><USER25> As an aside I don't have time or any purpose beyond curiosity to learn Rust right now. But having glanced through the Rust book a few times, I wish I did. It's the sort of book (a bit like K&R in this sense) that could lead one astray ..

<comment><USER22> Thank you; even saying "a bit like K&R" at all is high praise to me.

That said, not everyone likes my writing style, so I'm glad that there are other books coming out as well.

</comment></comment></comment></comment></comment><comment><USER26> My 2 cents, from the perspective of someone who built a career on writing software in C for small devices.

C has longevity b/c its compact and provides a straightforward model of memory on the machine. I understand the desire to use safe, garbage collected, memory safe language when you're serving HTTP requests, but sometimes you need to access the hardware: twiddle a GPIO or read from a DMA device. This is where I've yet to see a good replacement for C, and by extension, C++ (b/c its fundamentally still just C). Maybe rust is there, but I don't have experience there to judge.

[edited for clarity]

<comment><USER22> To be clear, since I have seen this pop up lately, Rust doesn't have a GC and absolutely gives you access to hardware. The challenges for it on embedded are mostly toolchain issues.

<comment><USER27> So, are vendors working on rust toolchains for their hardware? I'm asking from a place of genuine curiosity, I left embedded a number of years ago. I've always viewed the 'rust breaking into embedded' problem as a toolchain issue, as well. But, my intuition is that vendors will be slow to release rust support in toolchains because the industry is still firmly in the "we write in C" camp.

<comment><USER28> This is an interesting thread...

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

In my view the industry inertia is a chicken and egg thing. You want a chip that runs your existing code. Then you want to write new code on your existing chip. And you have ongoing projects at different stages, sharing chips and code.

</comment></comment></comment></comment><comment><USER29> C was originally a language for modest size programs on machines with 64K address spaces. C isn't a bad language for a thousand line program. It's a terrible language for a million line program. Just to get memory safety, there's too much that has to be manually coordinated across compilation unit boundaries.

The three big questions in C are "how big is it?", "who owns it?", and "who locks it?" The language gives zero help with all of those issues. Most later languages deal with some or all of those issues.

<comment><USER30> C could use a few features to help with million line codebases, like namespaces. Beyond that, programs that large require good human engineering to manage complexity.

</comment></comment><comment><USER31> I'm quite bored by the obsession of some for replacing C.

Yes, it does exactly what you tell it to do and that's dangerous. It was a high level language 25 years ago, but today the metaphor should be assembly. Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same.

The biggest threat to the tech sector is Linus dying and being replaced by some charlatan who insists on replacing C and using Jira.

</offtopic>

<comment><USER32> >Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same.

But I bet they would criticize _programs_ for being written in assembly, if they didn't need to be.

If you could have a language with all the performance of C without the footguns, why wouldn't you want that?

<comment><USER33> > a language with all the performance of C without the footguns, why wouldn't > you want that?

I've yet to see a language that actually delivered on this claim.

<comment><USER34> Perhaps you aren't looking?

Rust delivers on all these claims. And there have been others before it. Rust hits all the sweet spots for me.

<comment><USER35> Rust sits in a really weird spot. It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work.

Example for the first case: Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust.

For high-level work, almost all [1] of what Rust gives you is memory safety and that comes at the price of dealing with a LOT of extra language complexity. But aside from dynamic memory management, memory safety isn't hard (we did that back in the 1970s and 1980s), and for dynamic memory management, we can get memory safety with a garbage collector and much less complexity. So Rust is primarily of interest for those use cases where garbage collection is not an option.

While that still gives you plenty of interesting use cases for Rust, there are also plenty of programming niches that it serves poorly.

[1] People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard. That more languages don't do it is partly because they simply neglected that aspect [2], but also because any mechanism – including Rust's – for doing so inherently constrains your options w.r.t. concurrency [3]. Plus, avoiding data races is the easy part of getting concurrency right.

[3] Concurrent Pascal had guaranteed absence of data races in the absence of pointers in the 1970s, Eiffel had done it with pointers in the 1980s, and there was a plethora of research in the 1990s to do it in various other ways.

[3] For example, there are plenty of use cases, such as certain idempotent operations, where data races are not only perfectly safe, but also desired for performance. There are also use cases where you can prove that no data races occur, but a type system cannot easily capture that.

<comment><USER36>
      It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work.

This is true in the very specific cases that you gave, but I believe that is the minority of use cases, not the majority.

Even the example of writing a GC that requires tons of unsafe code, that is not a good argument for making _all_ the code unsafe. All the unsafe GC code would be abstracted away into a module and would be more obvious to those looking at it that they will need to be watchful for undefined behavior. Now you can proceed writing the rest of the project in safe, simple Rust.

      People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard

Maybe for developers that are very familiar with the race conditions of parallel code, but definitely not for most people. Even seasoned developers will make mistakes with simple multithreaded code.

Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable. The whole point is that you have a guarantee. Have you never had a compiler catch a stupid mistake before it happened and felt relieved? I doubt it. Now imagine if instead of debugging stupid data races in your parallel code you can spend that time optimizing and improving it. I fail to see how this can be viewed as negative.

Sure Rust doesn't cover 100% of use cases, but it definitely covers more than you're implying. It's low-level enough that Redox OS can be written in Rust, but high-level enough that Firefox is now outpacing other browsers and parallelizing everything with Rust.

<comment><USER35> > All the unsafe GC code would be abstracted away into a module and would be > more obvious to those looking at it that they will need to be watchful for > undefined behavior.

That code that could be "abstracted away" would be "virtually all the code" in my example.

> Maybe for developers that are very familiar with the race conditions of > parallel code, but definitely not for most people. Even seasoned developers > will make mistakes with simple multithreaded code.

I'm not talking about manually guaranteeing absence of data races. I mean absence of data races as a language feature.

> Also, the reasoning behind "x is easy so why do I need my language to check > it for me" is questionable.

This is not at all what I was talking about. You completely misunderstood me.

<comment><USER22> I think you'd be surprised, even operating systems, the canonical unsafe activity, has a relatively low percentage of unsafe code. For example, [https://doc.redox-os.org/book/introduction/unsafes.html](https://doc.redox- os.org/book/introduction/unsafes.html) says

> A quick grep gives us some stats: the kernel has about 70 invocations of > unsafe in about 4500 lines of code overall.

<comment><USER35> > I think you'd be surprised, even operating systems, the canonical unsafe > activity, has a relatively low percentage of unsafe code.

My example was a GC runtime, not an OS kernel. If I have only very little unsafe code, then I could just do that in C and the rest in whatever other high-level language suits my project and not see any difference.

The bigger problem – where Rust failed to pick some low-hanging fruit, IMO – is that "unsafe" is too much like the bad parts of C. There is no medium position between "everything is defined and memory-safe" and "everything may explode at a moment's notice".

My most practical need for a low-level language is a language that is in that in-between position: semantics that remain easy to comprehend and predictable even if there are no static guarantees, and where I have to use a different strategy for software assurance. The point here is that for such a language I _can_ resort to alternate validation tools (think Ada and SPARK for an example). Rust's unsafe mode does not handle that situation well because (like C) it does not provide a foundation for alternate validation strategies.

It's perhaps also worth pointing out that I have a formal methods background. In short, I've done formal specifications/proofs for software before. In this context, safe Rust has a fairly high cost for only providing memory safety (and few other guarantees), and unsafe Rust is not a good foundation (or at least, not much better than C) for bringing advanced tools to bear.

<comment><USER37> There are several things that make unsafe Rust better than C wrt to ensuring correctness. For example the stronger, more expressive type-system and fewer instances of undefined behavior for common operations. The standardized, modern tools for unit-testing and fuzzing are also nicer in Rust.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> As maddening as it may be, my gut tells me it has more to do with the precompiler than anything else. When it comes to wrestling with cross-platform differences, I don't know of a corresponding feature in Rust or Go that is equally powerful (or equally ugly!).

As long as computing remains a battleground where rich assholes put vastly different wrappers around the exact same shit so they can wring more money out of us, I will probably be writing in that abominable assembly language w/ turing-complete string-paster for many years to come.

<comment><USER21> Speaking of the C preprocessor, I found this recently: from the Firefox source code, a red-black tree written entirely in 800 lines of C macros: [http://searchfox.org/mozilla- central/rev/f54c1723befe6bcc722...](http://searchfox.org/mozilla- central/rev/f54c1723befe6bcc7229f005217d5c681128fcad/memory/build/rb.h) . Submitted for your enjoyment. :)

<comment><USER39> Why would someone do that?

<comment><USER40> Because long ago (and probably in a different product) making a function call was significantly costly and worthwhile optimizing away via macros.

</comment></comment></comment></comment><comment><USER41> >Perhaps now it is time for a new generation to make their mark, will their efforts last 40 years? Rust anyone?

I'd think it's quite difficult for a new language to replace a language whose main attractive points are it's longevity, stability (not the code and programs coming out of it, but the syntax and tools etc), and broad support.

There are many fields where C is easy to beat. But I don't think the next 40 year lasting language will be a C replacement.

<comment><USER42> Indeed. I think the obvious candidate is JavaScript.

C is what it is partly because of its relationship with Unix, and also because it was the language that gave most straightforward access to "the machine" \-- whatever that is.

And the hard truth is that The Machine was the only real universal platform around. But now we have this thing called The Web, which is not _quite_ as universal but is getting there, and is much more like a single platform. JS has a special relationship with it.

The only thing that might upset this JS+Web applecart is WebAssembly. A "C of the Web" (call it W) would be a language high level enough to be pleasant to use, but which would have little or no runtime beyond what is native to WebAsm, and thus anyone could use libraries written in W.

<comment><USER43> I note looking at webassembly.org's getting started page that their hello world example is written in C. Maybe the "C of the Web" will actually be C. ([http://webassembly.org/getting-started/developers- guide/](http://webassembly.org/getting-started/developers-guide/))

<comment><USER21> The ability to compile C code to WASM will be invaluable for porting well-used C libraries to the web, but given that the goal of WASM is to define a ("more- or-less") language-agnostic bytecode, I see little reason why people would prefer to use C when they could continue using Javascript, or, eventually, whatever the 40-years-from-now equivalent of Python is. (Of course, you'll always be able to use C if you do want to, so it's not like it's ever going to risk vanishing.)

<comment><USER44> > I see little reason why people would continue using C when they could > continue using Javascript, or, eventually, whatever the 40-years-from-now > equivalent of Python is.

People will use C or Python or whatever on the web for the same reasons so many people transpile to javascript today, including that they simply don't like javascript and would rather write code in a language they prefer.

<comment><USER21> Indeed, but, as much as I admire Typescript, the vast majority of people aren't transpiling anything to Javascript. The grandfather comment was concerned with whether the future "C of the web" would literally be C, but I don't see how the introduction of WASM will start convincing the majority of people to start shipping webapps written in C. C is useful today as a low- level lingua franca, but on the web WASM will be the lingua franca, by definition, and C will be competing with many other languages that compile to WASM.

<comment><USER44> > The grandfather comment was concerned with whether the future "C of the web" > would literally be C, but I don't see how the introduction of WASM will > start convincing the majority of people to start shipping webapps written in > C.

WebAssembly supports C/C++ _now_ , and there is a lot of existing code that could be tested or convered. WebAssembly will probably get garbage collection and be able to support many other languages soon, but by then network effects may have taken over - especially if most online tutorials for WASM cover C or C++.

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> > In 1987 this code took around half an hour to run, today 0.03 seconds. > Progress eh?

The thing I take away when reading this is that in 1987 there were superior languages to C which — while usable — were just a _bit_ too sluggish, and hence lost out. I'm thinking specifically of Smalltalk & Lisp, but I'm sure that there are others (maybe ML was around that far back?).

Well, if a program which once ran in half an hour can now run in 300 milliseconds, I think that maybe we should reconsider using just a little of that extra performance to run a better language environment.

Imagine if we had OSes written in safe languages which catch errors rather than allowing programs to misbehave. Honestly, it's hard for me to do because I've become so accustomed to crashes. Recently I've been doing some X programming with Lisp, and it's amazing — even when I make a mistake, things keep on running properly. I just see an error and that's that.

Well, most of the time, anyway. Nothing's perfect. Still, the experience is _orders_ of magnitude better than writing C. I mean that literally, not figuratively.

(Also, as an aside: when I switched tabs to the article, it displayed for just a second, then disappeared. Reader mode didn't even work. I had to enable JavaScript just to view some text. What gives‽)

<comment><USER46> > reconsider using just a little of that extra performance

Welcome to software development, where the code is shit, and the hardware improvements don't matter.

</comment></comment><comment><USER47> > Add to this the disastrously central role that C has played in our ongoing > computer security nightmare

Hindsight is 20/20.

C was simply the pervasive language when the internet happened. C was designed when the world was a friendlier place, where buffer overflows did not exist. It was embraced by everyone because of its speed and simplicity.

No C programmer was raised/educated to have security in the front of his mind. Hell, many programmers of any language still don't.

Stop bashing C and start using Oauth instead of inventing your own authentication schemes.

<comment><USER12> Hoare in 1981 referring to C.

"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 precautions would have long been against the law."

Fran Allen on "Coders at Work," about C.

"Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

</comment></comment><comment><USER48> C was the first language I learned in the mid-90s and I still go back to it once and a while when I want raw speed and direct memory access. I know other languages, sure, but I have yet to find a suitable replacement that lets me do what I want to do on a machine level without getting in the way.

Lately I've been doing some of the stuff I would normally do in C in GoLang instead. But it still can't match C in performance. (beats the hell out of Node.js though which is where I do most of my middle-tier / front-end code)

It also makes an excellent foot gun for the same reason.

</comment><comment><USER49> If something is to replace C (or C++), I hope it's not Rust, because Rust is even more complicated than C++.

People should not have to bend their mind to satisfy some tool like the borrow checker, the tool should do the right thing and allow them to express their ideas in code with as little effort as possible.

<comment><USER21> _> Rust is even more complicated than C++_

Example? In my experience, those saying this have either never used Rust, or never used C++. A strict compiler does not a complicated language make. To wit, if the response is "lifetimes", note that lifetime tracking is also critically important in C++ (not to mention C), it's just that C++ compilers give one far less help in doing so than Rust does.

<comment><USER49> Take for instance [http://cglab.ca/~abeinges/blah/too-many- lists/book/README.ht...](http://cglab.ca/~abeinges/blah/too-many- lists/book/README.html). I could feel the frustration when reading those compiler errors. I mean it's a list, one of the simplest data structures to implement, I was doing that stuff in high-school.

But it's not just about a particular example, instead I get a general feeling of inaccessibility when reading Rust code. It's not enough to know C or C++, one has to understand the Rust way. This might seem unfair to complain about, but I didn't have any such issues when learning e.g. Swift or Objective-C, to give an example of non-GC languages.

<comment><USER22> Side note, we have completely re-done the format of compiler errors since that was published. To take a random example from 2.1:

      src/first.rs:1:1: 4:2 error: illegal recursive enum type; wrap the inner value in a box to make it representable [E0072]
      src/first.rs:1 pub enum List {
      src/first.rs:2    Empty,
      src/first.rs:3    Elem(T, List),
      src/first.rs:4 }
      error: aborting due to previous error

is now

      error[E0072]: recursive type `List` has infinite size
       --> src/main.rs:1:1
        |
      1 | pub enum List {
        | ^^^^^^^^^^^^^ recursive type has infinite size
      2 |     Empty,
      3 |     Elem(i32, List),
        |               ----- recursive without indirection
        |
        = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `List` representable

Users have reported a lot less frustration after these changes, and we're always trying to make them better. For more on this effort [https://blog.rust- lang.org/2016/08/10/Shape-of-errors-to-com...](https://blog.rust- lang.org/2016/08/10/Shape-of-errors-to-come.html)

<comment><USER50> I'd like to thank you a lot for those error messages. As somebody learning the language, they are incredibly helpful.

<comment><USER22> I will tell that to the people who actually did said work, I'm sure they will appreciate it :D

</comment></comment></comment></comment></comment></comment><comment><USER51> I wonder if the danger of C is something people like, deep down. I spent some time talking to people who do dangerous jobs, thinking about automating their jobs with robots. Most of them _liked_ the danger. They enjoyed having mastered the art of not getting killed by falling tree branches, or live wires, or runaway trucks, or whatever the job involved. They felt satisfaction at doing a job where, if someone else tried to do it, they'd probably get hurt on their first day. You can imagine various ways this could have evolved in hunter-gatherer societies.

Most new languages are far safer than C. For some that's the main selling point, for others it's just a side-effect of having GC. I wonder if you could get a lot of traction with a language as expressive as Ruby, but with footguns galore. I'm not sure that space has been adequately explored.

<comment><USER52> I wouldn't put it as "danger", exactly. It's freedom. The language won't trap you, pretty much ever. You need to write directly to hardware registers? Fine. You need to drop into assembly for a bit? Go for it. However down-and-dirty you have to get, you can do it.

Whereas with some other languages, if you ever need to get more down-and-dirty than the language is designed to allow, even for just a little bit of your program, well, too bad - you're not allowed to.

<comment><USER12> I could do all of that in Turbo Pascal, Turbo Basic and Modula-2 compilers.

<comment><USER52> Ah, I had forgotten that Turbo Pascal let you drop into assembly.

But could you write directly to a hardware address? I don't know, but I doubt it - Turbo Pascal ran on the PC, which didn't have memory-mapped hardware. You could do an outp. But in C, you could do

      *(unsigned long*)0xFFFE0004 = 0x8000FF2C;

which was either absolutely necessary or absolutely stupid, depending on whether or not you had custom memory-mapped hardware at the specified address. Could you do that in Turbo Pascal?

What's more, Turbo Pascal was PC-only, at least initially. If you had to work on a 68000-based embedded system running PDOS ( _not_ PC-DOS), and you had to use Pascal, it _wasn 't_ Turbo Pascal. It was just bog-standard Pascal. Inline assembler? No way. Pointer to a variable-sized array? Can't do it (you cannot give it a type). It was _painful_ to work in that environment. And that environment was Pascal as specified by the language standard. Turbo Pascal fixed most of the problems, but it trampled all over the standard to do it. (At least it did have separate compilation.)

Why was it painful to work in that environment? First, we couldn't access our custom hardware without having to link to an assembly-language subroutine. In doing so, we lost type safety, which led to at least one hard-to-find crash. It also was just much more difficult and error-prone to write those routines. Second, we wanted to have a user-specified variable-sized array. We wound up having to create the largest array we could given the memory the machine had, and only using the part that the user specified, which was a pretty ugly kludge. Third, Pascal was just clumsier to use than C. It was more verbose and more finicky. (One part I remember in particular was the semicolons. You couldn't have a semicolon on the last statement in a block. As you added or removed statements, you kept having to fiddle with the semicolons, including on lines other than the ones you were changing.)

<comment><USER12> Something like,

        myMemoryAddr : Longint absolute $FFFE0004;

There were Turbo Pascal compatible compilers for Amiga, and it was the most common dialect, to the point ISO Extended Pascal compatibility was mostly ignored.

There are still companies selling Turbo Pascal compatible compilers for embedded systems.

[https://www.mikroe.com/mikropascal/](https://www.mikroe.com/mikropascal/)

Inline Assemly is not part of C, it is a common compiler extension, whose semantics are not even portable across compilers.

Back in the day when Pascal compilers were more widespread, C was hardly much more portable, with each compiler having its own little world between K&R C and ANSI C89.

</comment></comment></comment></comment></comment><comment><USER53> It shouldn't be such a surprise, unless one is ignorant of a stable, decades old, computing maxim:

Old computers (and by definition, old computer software) never dies. _The users do_.

</comment><comment><USER54> Even in relatively new fields like machine learning, nearly every software that we use at work is written in C or is a wrapper around a C library, or in some cases in Fortran (a 60 years old programming language) : we use extensively PyTorch, torch, numpy, LAPACK, Scipy, etc.

</comment><comment><USER55> PHP is having it's 21st this year and is in use on around 200 million websites, I think it'll make it :)

Logo is 50 :)

</comment><comment><USER56> The "AHL" name brings me fond memories of Creative Computing magazine and their editor, David H. Ahl.

Sadly these AHL's are unrelated.

</comment><comment><USER57> Binary compatibility is as much a reason as the language itself.

For C++ I remember spending years trying to carefully track compiler versions, precise build setup, etc. or your library would probably fail to link. I have never had a binary compatibility problem with a plain C library.

</comment><comment><USER58> C exposes you to low level programming environment, memory management and system internals. Its a great base to build upon for programmers. Even after more than a decade, I still have fond memories for K&R C - a must read for programmers.

</comment><comment><USER59> C was so successful because it had, and to a large extent still has, no competitors.

<comment><USER40> It was also free.

<comment><USER12> Only on UNIX, until Sun started to charge money for their SDK, which lead to many devs starting to help GCC development.

</comment></comment></comment><comment><USER60> "We use git for source control. hg, largely written in Python, was started within a few days with the same goals. Who won?"

I somehow doubt git's popularity has a whole lot to do with it having been written in C.

</comment><comment><USER61> So COBOL and Fortan is still going strong in the areas its appropriate for.

<comment><USER62> Lisp is still around too. SmallTalk as well.

</comment></comment><comment><USER63> c.f. [https://en.wikipedia.org/wiki/Lindy_effect](https://en.wikipedia.org/wiki/Lindy_effect)

</comment><comment><USER64> it's time we admitted bad code isn't because of the tools we use but a function of how we write code. You can write bad code even in "safe" languages. Leak memory with languages that come with a GC, etc etc.

<comment> Ar-Curunir Yes, but some languages make it far easier than others.

</comment></comment><comment><USER65> C is simple and beautiful.

<comment><USER66> C _looks_ simple, but is not. That's part of the problem with it.</comment></comment>


The French Genocide That Has Been Air-Brushed from History - <AUTHOR> https://quillette.com/2019/03/10/the-french-genocide-that-has-been-air-brushed-from-history/ <comment><USER2> This article is about the massacre in Vendee, which was a particularly nasty chapter in the already nasty French Revolution. I feel that 'genocide' is the whole word for what happened because the peasants in Vendee were just as French as the revolutionaries they revolted against; they were not some distinct ethnicity.

<comment><USER3> Although the most commonly definition of genocide applies to race/ethnicity, it can also apply to class or group for instance. On this case, the events being related can indeed be considered a genocide as long as there was intent in effacing that class/group: [https://en.m.wikipedia.org/wiki/Genocide_definitions](https://en.m.wikipedia.org/wiki/Genocide_definitions)</comment></comment>