skysight-inc/HackerNews huggingface dataset:
You're 100% right. I was actually thinking of name-mangling when typing that, but that's still not quite right. The point I was trying (and failing) to make is that Rust uses things like name-mangling and a different ABI that makes interop more of a challenge - similar in challenge to interop with C++ from C.

C technically has name-mangling too, but generally speaking either there is no mangling at all, or they just add an '_' to every symbol name.

Edit: To address your second point, I think that is a step in the right direction - and I think that Rust's compatibility with C libraries is probably fine, and comparable to most languages. I don't consider that to be so big of a turn-off that I wouldn't want to use Rust for a new project, though obvious writing wrappers isn't always fun or error-free.

But, assuming I'm understanding what you're getting at correctly, I'm not sure that will really solve the core problem I'm trying to get at: Generally speaking, nobody wants to be maintaining compatibility wrappers for APIs that exist entirely within their program and are probably changing all the time, and that's really what you need if you want to replacing part of a C program with Rust.

For example, to take it to the 'extreme' - the Linux Kernel module API changes virtually every version of the kernel (And the ABI is not guaranteed at all), and maintaining a complete Rust wrapper for it would not be a fun time even if a certain amount of it can be auto-generated. The API includes a very complicated mess of functions, inline functions, macros, structures (with varying different types of alignment and padding). None of it is guaranteed to stay the same across versions. And I think it is fair to say that most C programs have internal APIs like this (Though not as crazy) that are changing all the time and not intended to be seen by the 'outside world'. It's these types of things that I see being a problem for interfacing with Rust - APIs that are changing all the time in complicated ways which make writing and maintaining a wrapper very annoying and error-prone.
If you're looking to do a desktop GUI type of application, then those two are decent choices.

If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's docs are very good. None of the "oh, I was advised to use this class. Where are the docs? What do you mean... go read the source code?".

Gah... sorry... still haven't gotten my extremely bad experiences with Gtk out of my system (years later). ;)

If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good docs, very large user base, actively helpful Community on IRC. (I'm not really a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for getting ideas from.

Hope that's useful. :)
Licensing and cost is similar to Qt (free for open source, $$$ for commercial applications, though I think JUCE is cheaper). So, at least relatively to Qt, it doesn't particularly limit popularity.

And even in an absolute sense, you can't confidently say that dual-licensing limits popularity in the long term. If JUCE and Qt were free for everyone, perhaps they wouldn't be able to have the full-time developers they both currently have. So maybe they wouldn't be as good, thereby decreasing popularity against competing dual-licensed libraries. This is all wild speculation, of course, but it's an example to show how their model works.
Not a fan. Not to say this isn't perhaps more readable to a layperson than the regex equivalent. However, I dislike these sorts of "syntactic sugar" libraries as a rule due to the cognitive overhead they add to a project; every programmer working on this code now needs to know this API in addition to the regex equivalent, which, let's face it, they would've needed to know anyways.

Nonetheless, I commend you for putting a well documented/examples API out there. Cheers.
I suppose the whole crux and beauty of the article is that we can talk about physics without numbers. As soon as numbers enter the picture, we have discretized something that is beyond discretization.
On speaking at community conferences
If your argument is that terrestrial radio broadcasts mean we don't need the laser... then why do we need the laser?

Re: interstellar invasion, perhaps not, but hard to rule out the possibility that the response we get to our broadcasts is something like a relativistic projectile.
This article was really hard to read. Here's my attempt at a summary:

* The author expects new cars to be networked and to have beefy CPUs.

* There are lots of cars, and each car will use lots of data. To network all these cars, you'll need investment from telecom companies like carriers.

* Today the car's systems don't talk to each other, or the internet that much. Once you network them, it'll be good for companies who make cars to see how their product is used in the wild.

* Now that you have smart cars, people can write apps for them. The author thinks this will be a large market with a few killer apps.

* Car's are really complex, and were not designed to be networked. You should expect a lot of security issues during this transition.
> the web is more open now than it's ever been.

mmm... How are you measuring that?

> Everything you need to build a web application like Facebook is free to try and use.

That is not what is being discussed. However, you have a HUGE disadvantage that is growing exponentially.
There ARE benefits to correctness from better languages, just not as amazing as people think.

I'm just saying a vulnerability in C is just going to be an out of bounds exception in another language. both cases the code is not correct, one is just safer than the other when it comes to exploits.

Keep making more languages, we can't know for sure if we don't try.
Google Tests Software That Judges Hollywood's Portrayal of Women
To re-iterate what gankro said, we care a _lot_ about making sure that it's trivial to update your Rust. Your ABI compatibility comment is correct, but the rest of them aren't. We only break backwards compatibility in very few cases: if there's a soundness hole, or if we have to fix something in certain underspecified areas of the language. For those latter ones, if it's not a trivial fix, then it's a no-go, and even if it is, we do warnings until we don't see them in the ecosystem any longer.

But really, it's not about rules-lawyering over technicalities about what our policies are: the underlying attitude we share towards new Rust versions is that it should be trivial to upgrade. And we collect data to make sure that we're on target there: part of it is the train-based release strategy, part of it is stuff like testing everything on crates.io, part of it is things like the community survey, where most people said their code has never broken, and if it did, it was extremely easy to fix.
Would love to see that paper!
How about murder by judge/trial? Thiel didn't buy a private court and force a judgement.
> By comparison, the average new car in the U.S. today sells for about $33,000.

That may be the mean but I'll bet it's nowhere near the median.
It's all good! :)

Oh, and another thing that makes C interop hard that you didn't mention: unions. We have those coming, though, and it should help a lot.
The answer to almost all of his complaints is not : have Google do it, but rather: use a credit union.
True, it's not fair. I didn't say that your first implementation had to be beneath C, but if you really want to replace the language at the bottom of the stack, you have to rewrite the stack. Otherwise, you haven't really replaced it, now have you?
Bummer. It was up there a couple months ago.
I'm fortunate(?) enough to have spent a lot of time in Silicon Valley; cumulatively ~9 months of my life in the past few years.

I used the word fortunate because my time there has only convinced me that it's somewhere I would never want to live, being as crowded and expensive as it is. It also reminds of Washington DC where everyone wants to know what you do for a living right away. It seems like everybody's got a plan; it's kind of like Nashville with a tan.

I hear all these arguments like 'talent center' and 'network effects' and 'efficiency', but then look at the results of cramming all that talent into such a tiny area: stress and misery. We can go on and on about building more houses or condos. In fact, they could build thousands more houses and condos and make it all perfectly affordable for everyone.

But then what? Who wants to spend 3 hours getting over 17 just to go to Santa Cruz? What about parking once you get there? Do you want to wait for an hour for a chance to get one of the spots at the tiny parking lot above the water? Long lines for ice cream and water. It would be like the Hamptons in summer, which is to say it would be dreadful.

Even if you can afford it, who wants to live that kind of life? Just so that billionaire so-and-so can have another jet or another yacht or another mansion?

It just doesn't make any sense to me at all. I think it would be much more efficient to have multiple tech talent centers all over the country. I think most network guys would also say that such an arrangement would be more fault tolerant. I'm a programmer, so I guess I would say that it would make tech more loosely coupled.
All for electric cars here, but think a minute about the convienence of gasoline auto travel, especially refueling at a gas station. They must get electric charging stations everywhere, but they also must reduce the 30 to 60 min. Recharging time. Gas is what 2 minutes? Especially in the age of tech and gadgets people will not stand for LESS convienence, only more. Replacing gas will take a while.
If I remember correctly from the article, if this object were capable of perturbing Earth in any significant way, then we would be under much greater threat from Jupiter and Saturn, which are at least order of magnitude closer to us at any given time. Gravitation is a very weak force, and it scales as the inverse square of the distance between two objects. An order of magnitude reduction in distance would multiply the force by roughly 100 times. Thus, we would see these effects all the time as a result of our proximity to Jupiter and Saturn.

So no, what you're suggesting is impossible.
I know full well: my point was that you cannot depend on that which you wish to replace: Targeting something that doesn't is a valid approach for doing so.
C is beautiful in its way and it is rather minimalist from the syntax point of view (especially the pre-C99 variants). Judging by the code examples shown on the page, this new language has a pretty noisy (compared to C, downright ugly) syntax. Granted, it may be dictated by some logic and possibly even its inner beauty, but on the surface it does not seem to be much of an improvement compared to the languages we already know and love (or love to hate), including Perl and JavaScript.
Yeah. I came across C library that used Cython to create Python bindings. It was funny, they could easily support both Python 2 and Python 3 at the same time since all their binding code was in Cython, it was only their installation script witch used an incompatibility (print statement)
A giant pyramid hidden inside a mountain
Fair 'nuff on the compiler stuff. I was talking about replacing C globally, however, and that's not happening any more than we're replacing FORTRAN.
MXE has an ok reputation. Not everything seems to play well with it though. :(

For example, we (sqlitebrowser.org) compile our window nightly releases from Linux, using MXE. But, SQLCipher (an encryption library) doesn't build with MXE. So the nightlies don't support encryption.

Meanwhile, we've figured out how to do full Windows dev setup and builds. eg:

https://github.com/sqlitebrowser/sqlitebrowser/wiki/Setting-up-a-Win64-development-environment-for-DB4S

We're building our releases natively now, and the nightlies will be built natively too in (hopefully near) future.

Guess we just outgrew MXE?
I'm reminded of another horse breeding scheme that got Nazi funding: Hermann Fegelein's SS-Hauptreitschule München: https://en.wikipedia.org/wiki/Hermann_Fegelein
What aren't you understanding? Of course I don't seriously believe aliens move objects around the solar system. It's just a silly thought experiment.

The point is it seems absurd that the past history of an object should matter, for this definition. Like if it's a big round object orbiting a star, it's a planet. It shouldn't matter how it got there. It seems quite possible there could be cases where another object clears the orbit of another object. Perhaps not aliens, but a rogue planet.

I was trying to recreate the "star trek test" argument that I heard a real astronomer use. He was upset with the new definition, and made an analogy to start trek. On the show they don't wait around for 12 months to observe the planet and any objects in its orbit, let alone it's past history. He argued that any sensible definition should be possible to determine immediately.

Of course we are arguing about the definition of a word, and all arguments are subjective and appeal to intuition. But still there can be bad definitions.
Shows what I know about selling houses. Definitely sounds like a better solution
What does "packages" mean here? Sorry.
Well, most of the scientific computing in Python is happening on NumPy. Which uses Fortran compatible data structures. I doubt that a C++ backed python extension will be compatible with that. For that reason, if anything, I'd advocate to transpile to Fortran rather than C++ if you want more comfort for scientific users.
If you're just commuting, an electric car has it's own convenience - every morning it's full up and ready to go as it's been charging in your garage all night. No need to even think about remaining range or if you need to fill up or what gas station to go to.
el.email = Object.assign(document.createElement('input'),{type:'email'});
But isn't Haskell's runtime (RTS) written in C?
It's lowlevel, that's why there's so much spec. And much of it is just defining that behaviour is implementation defined.

And as I said, it's as lowlevel as an HLL can be.

I wish we could check the carry flag. You could totally write a C library for that, I bet, by mixing in some asm, and using conditional compilation. Language extension!
That was a very good doc that I put on about a year ago. I'm not a wine guy, but it's a great story.
Huh? I don't get what you are saying. Are you referencing something here?
(Not a physics person, but) As I read it, he is just arguing against the implication that Countability implies Particles. So he is saying that adding a quantum that is monochromatic has an effect across all space (which is clearly a non-particle like effect). Then he admits that you can get localization through superpositions of quanta.

Since he is arguing against a logical implication he only needs to show a counterexample exists.

The problematic part in choosing a single mode like this is that it can lead to a non-normalizable integral at some point (ie, it won't be a member of the Hilbert space).

QFT always made more since to me. Everything flows more naturally than in QM, where out of the blue, they introduce wave packets.

The paper does feel a bit shaky though especially as it is essentially taking a pedagogical point (start teaching from a QFT viewpoint) and making it into an argument about the foundations of physics. The non-relativistic QM view point is taught because it represents a smooth departure point from classical thinking without requiring the full mathematical complexity of field theory.
FBI. https://www.quandl.com/data/FBI/WEAPONS11-US-Murders-by-Weap...

The FBI and BJS usually have pretty good criminology data.
Yes, supplying a random string to a hash function to get a hashed random string is what I am inferring is the author's intent. Why do that? To get a unique ID that can be used as an API key, as opposed to using a GUID for example. And sometime you need public API keys, for example the browser keys you need to use google maps.
Unless you renting and don't have access to a plug. Or want to go on a weekend trip. Electric is interesting, but nothing more as a result for me personally.
Well that's half the reason for staying at a backpackers. Forced interaction with lots of strangers, most of whom you will never meet again.
I've posted about this before, but my work (non IT Department at a State Govt agency) has been using Docker in production for about a year. We are small by HN standards (~12 apps on 5 hosts that are a mix of API's, front ends, and several more complex GIS apps). Moving to Docker was a massive improvement for us in terms of deployment and development. Deploying with Docker is ridiculously easy (no more taking a node out of HAProxy for an update, rollbacks are painless, and we love that what you deploy is what you get - there is no question over what the container is actually doing since you define it in the Dockerfile). I can't remember the last time we had a bad deployment or even cared about making a change to production. It's that reliable. It's also been a massive improvement for QA and development because of the ability to standardize the container using the Dockerfile.

We've been using CentOS for the production hosts and CentOS/OSX for developing on. There were a couple of minor issues when we started but the benefits outweighed the negatives then. It's been completely painless since Docker came out of beta. We have some containers that are deployed daily and others that run for months without being touched.

I've never quite understood the negative attitude towards Docker. Perhaps we are too small to see many of the issues that people often complain about, but moving to Docker was a great decision in our office.
There's a reason there are multiple OS's, right?

One of the reasons is different UI paradigms and choices.
I've seen a few friends go down this path, happy to introduce you if you're interested.

Contact info is in my profile.
How Purism Avoids Intel’s Active Management Technology
I very much enjoyed Earthsea, but they are astoundingly different from the Hainish stuff.
Couldn't agree more! When I go on a car trip I want it to be a long way away, and a long way from any thing. That's why most electric cars can't be my only car, and I don't want two cars either. For someone like me a plug-in hybrid like the Volt makes a lot more sense because I can drive it ten hours out into the desert when I want to.

The only reason we're reaching a tipping point in the American car market is because families with two cars are so common. If you have two cars it makes perfect sense to have one that can go around your city, and another one that can go anywhere.
In cars, "killer apps" takes a whole new meaning. Will Christine.app [1] be an unexpected hit on the carOS App Store?

[1] https://en.wikipedia.org/wiki/Christine_(1983_film)
"something which can give some hints where to debug based on the nature of the problem"

That could be something as simple as keeping those hints on a wiki. Why does it need to be integrated into the debugger?
I went to Ameoba in LA 2 years ago. It had been a awhile since I was in a record store.

It seemed sooooo dated. No way to listen to the CDs to see if I want one. No way to check reviews like if I wanted to see which of 5 albums I should consider. Plus I don't even own a CD player at the moment. My laptop doesn't have one so I'd have to ask someone to rip it.

I used to love records stores and some of my favorite music is stuff I discovered at the store but it feels like snail mail to email at this point. Sure album covers and liner notes are awesome but I've been online since 2003 with Rhapsody and other stuff since and just being able to play any album and then look at the influences lists and follow those totally killed doing it at the store for me.

In Japan there are a couple of CD stores where all the CDs are open and there are 20-30 CD players for you to listen to them in. It's fun as nostalgia but even then it's not as convenient as online.

It all feels like from another era like a livery or something.
> C is very close to the hardware

At this point, I'd more say that the hardware does an awful lot of work trying to look like it's close to C.
It is not. It was derived from the banner image on this page:

http://airportparkingguides.com/jfk-airport-parking-guide/

I found it via a Google image search for "JFK airport"; it was the fifth result.
Also the inconvenience for those who live in apartments and condos.
I've been teaching kids to code for 19 years now, and I still make them do it the hard way.

Just two days ago this year's crop of 83 students wrote their first Java programs in Notepad and compiled and ran it from the command-line.

And I have a waiting list to get into my class.

I do work with older students (aged 14-18) and the key is TREMENDOUS support. I'll happily show them the command-line stuff over and over again for a month if need be.

And my curriculum goes through the basics of Java very slowly. As I've said on HN before, I make my students code FizzBuzz, but they will have literally done 106 complete programming projects before it.
> Gas is what 2 minutes?

Depends quite a lot on where you are. There are 12 gas stations south of 96th St. in Manhattan. SF will have lost 40% of the service stations it had 10 years ago as of 2017. Boston, same. The gas station at Divisadero and Fell has what looks like a 20 minute wait at all times. This is all due to real estate prices. Getting gas in affluent coastal metropolises is not a pleasant experience. Not coincidentally, these are the same people who are buying electric cars.
I agree across the board with your assessment.

It is a shame that OP does not want to go HTML/CSS engine, because over the years, I have found that to be the easiest to update, the most reliable across platforms, and (most importantly) the easiest to support for multiple users.

I have tried (and used in production) most of the UI tookits mentioned here.

WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and show it.

Java (SWT, etc), looks wonky across platforms and really do not stand up to the "write once, run anywhere" promise. Also, if you have to do anything even a little out of the lines, count on keeping multiple codebases for different platforms.

Although I had a brief love affair with other VM-type platforms (Adobe Air, Silverlight), mobile mostly pushed support for them out (Air just pivoted to mobile altogether, I believe). They offered single codebase, easy updates, and easy-ish support at a cost of have the user install additional software, but worth the tradeoff in my opinion.

All of the python UI libs are a pain in the ass to distribute, update, and support.

Ultimate++ and Borland Delphi are pretty polished, but you either have to buy into their ecosystems or accept their limitations.

At the end of the day, even though Javascript is a bullshit language for desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are just pleasant for maintaining codebase, pushing out updates, doing anything you want with the UI, and support has been a breeze.
Wow, Quandl is AWESOME! Graphs, data export, programming language bindings...
Please check the special $1000+ power cables for audiophiles...
What was the library?
New Way to Save Money
yeah, and maybe they should factor in the average car bought and sold, there's still a LOT of car owners/buyers that stick to the used lots.
I was looking at buying a new car recently. I wanted a commuter car while my wife kept the utilitarian Rav 4. I wanted to buy the GM Spark, the electric version.

http://www.chevrolet.com/spark-ev-electric-vehicle.html

The irony being that a car named Spark originally isn't electric, but only in certain markets.
Why can't the car generate electricity and last like 5x as long? Each wheel could probably generate quite a bit of static electricity and refuel the tank. Honestly I think hybrids will be the go-to method for the next decade or two, unless they can get batteries to 500+ miles. -- If they get the battery to 1000 miles though it's game over for gasoline cars though.