winstonewert

For anyone who might be confused about the pardoning a turkey reference: https://en.wikipedia.org/wiki/National_Thanksgiving_Turkey_P...

Perhaps you could refrain from slandering Rust proponents without any evidence.

I think the real question has to be: how do we determine what the regulations should be. Today, regulations are typically the product of dysfunctional political processes, and, no surprise, a lot of those regulations are unhelpful and a lot of helpful regulations are absent.

> but not everything is necessarily backed by the same kind of heap-allocated memory object.

Do you have an example, I thought literally everything in Python did trace to a PyObject*.

The problem is that sometimes it is not a necessary condition. Rather, the tests might have been checking implementation details or just been wrong in the first place. Now, when tests fails I have extra work to figure out if its a real break or just a bad test.

Some thoughts:

- It says that 3/4 of people kept working; to me, that seems like a big drop.

- Data is based on a survey of people in the program; I distrust data from surveys on principle.

- There seems to have been a reduction in the payment as they earned money, so its not really UBI as typically advocated.

There is likely a cost to the infrastructure necessary to enable calling 911 that scales with the number of users not the number of 911 calls. Where I'm at, there is a 75 cent per month fee added to phone plans to cover the costs of access to 911. If most people are on the free plan, the margin from the few paying customers won't cover it.

Then I'm sure you're willing to donate the cash to make it happen.

Perhaps - but they could just do what Microsoft did: bundle a version of Chromium.

It sounds to me like you are thinking something like: if they use XML, they'll have a well defined schema and will follow standardized XML types. But if they use JSON they may not have a well-defined schema at all, and may not follow any sort of standardized formats.

But to my mind, whether they have a well-defined schema and follow proper datatypes really has very little to do with the choice of XML or JSON.

My specific claim was that you could represent it in JSON, so you can't claim, as the post I responded to did, that JSON "cannot be used."

I'll fully grant, I don't want to write a document by hand in either of the JSON formats I suggested. Although, given the choice, I'd rather receive it in that format to be parsed than in any XML format.

I think I can see something of where you're coming from. But a question:

You complain about dates in JSON (really a specific case of parsing text in JSON):

> If they implement dates, sometimes it's unix-time, sometimes it's 1000x off from > that, sometimes it's a ISO8601-inspired string, and fuck sometimes I just get an > HTTP date. And so on.

Sure, but does not XML have the exact same problem because everything is just a text?

`{ type: "p", children: [{type: "text", text: "How would you represent "}, {type: "b", children: [{type: "i", children: [{type: "text", text: "mixed content"}]], {type: "text", text: " in JSON?"]}`

or:

`{paragraphs: [{spans: [{ text: "How you represent "}, {bold: true, italic: true, text: "mixed content"},{text: " in JSON?"}]}`

What actually prevents JSON from being used in these spaces? It seems to me that any XML structure can be represented in JSON. Personally, I've yet to come across an XML document I didn't wish was JSON, but perhaps in spaces I haven't worked with, it exists.

Really? Is there no level of compensation that would make you think that getting punched was worthwhile?

Well, if they did that, then people could expect/demand stability with regard to what scenarios get the checks/panics optimized out. This would be a bit of a burden for the Rust maintainers. It would effectively make the optimizer part of the language specification, and that's undesireable.

But the great thing about Rust is that the panic traces back to the exact place where I thought something couldn't be None, but it was. In Java, I frequently found it mysterious why some variable or parameter was unexpectedly null.

I think the causation runs in the opposite direction. These exceptions for these platforms were implemented in an inefficient fashion BECAUSE they thought that exceptions should almost never be thrown.

My wish: people stop using the dumb line that exceptions are gotos.

To attempt a more measured response: given that the NRLB hasn't gotten involved in any company with this policy that's clearly not true.

I'm sorry for my earlier responses. I was becoming ill, didn't realize it, and that messes with my temper. One day I'll learn not to argue with people on the internet when that happens.

The difference is that me and others have repeatedly explained why you are wrong in this thread, and you keep repeating the same nonsense assertions.

You are wrong. Since you show no signs of recognizing that, or providing any reason to back up your assertions, I'm done with this conversation.

I suspect it's much easier for someone to sue on the claim of being unfairly discriminated against than on the claim that a particular company policy with a legitimate stated justification is an unfair labor practice.

But what if you get a bad letter of recommendation and sue about it? What if the manager refuses to write you a letter of recommendation and you sue them? The easiest solution from the company is simple: don't allow any letters of recommendation.

That is what my former manager told me when I left my previous employer. He thought highly of my skills, but couldn't write me a letter due to company policy motivated by these concerns about being sued.

The same system is in Canada, and typically the party in power tries to time the election so they have the best chance of winning. Any numbers of factors could come into this (polling numbers, expected news event during the campaign, length of campaign, etc).

An important aspect of this is that it's not legal for most people to run a prediction market. PredictIt is allowed to operate because it is run by a university, and even that is now under question. The result is that there is little competition in this space, which is why PredictIt has huge fees and limits. As others have pointed out, that's a big part of why these markets deviate from reality.

It seems to me that your examples rather show the futility of trying to use a license to force good behaviour rather than a reason to change licenses.

Why? If you are using a crate, its code will be running in your application. Its not really any more of a concern if it can run code while building.

When I referred to build.rs - I merely meant that the build script made it possible to build code written in other languages - not that it solved all the problems. It very much doesn't solve all the problems involved.