winstonewert

Many rust crates actually do package code written in other languages. There are plenty of useful C/C++/Fortran libraries that nobody has rewritten into Rust but for which wrappers have been created that call into C. It works in Rust because the build.rs lets libraries do whatever they want during the build process, including invoking compilers for other languages.

Various factors still make the Rust and Python story different (Python uses more mixed-language packages, the Rust demographic is more technically advanced, etc). But a big one is that in Rust, the FFI is defined in Rust. Recompiling just the Rust code gives you an updated FFI compatible with your version of Rust. In Python, the FFI is typically defined in C, so recompiling the python won't get you a compatible FFI. If Python did all FFI through something like ctypes, it would be much more smooth.

That's exactly my perspective. Tailwind tries to make inline CSS workable, but there are so much better options in available in a frontend frameworks.

Its hard keeping track of different usernames on here.

From my perspective, "almost never" and "won't actually happen" aren't that different. Both indicate that the probability of success is very low. It seems to be, if the probability is already really low, is not worth extending effort maintaining it.

Ok, sure. But that's not what you were saying in the comment I responded to.

Tailwind done correctly would have you use another system like react/templates so that you still only have to modify one place.

In practice however I see a lot of copy paste in tailwind html so it doesn't work quite as well in reality.

Can you explain something about why you prefer the separation of style and content? From my perspective all that it accomplished is making me modify two files (html template and CSS) instead of one.

Let's not spend extra effort supporting a theoretical feature that won't actually happen.

How would either approach be different? In both cases you would have to rewrite the code that directly interacts with your Excel library.

This doesn't track for me. Lots of people forecast, rightly or wrongly, events much worse then we've ever experienced: catastrophic climate change, apocalyptic nuclear war, immentiment economic collapse, etc. So no, I don't think we are somehow limited in our imagination to events that we've already observed to happen.

Yes.

The same way that review sites are good because they help people buy products without doing work. Or Hacker News is good is because it finds news stories that interest us without us doing the work.

Except that without parties, its really hard to tell who stands for what. In the local elections where I live, there aren't parties. Voting requires researching each candidate carefully to determine what they stand for. Now, I'm nerdy enough to do that research. But the general population isn't.

That's an imagined and unrealistic scenario.

Most countries with proportional systems have a threshold that requires something like 5% of the vote to earn seats. So nobody with 2% of the vote is going to be part of the coalition. Furthermore, pulling out of coalition, without a very good reason, is an excellent way to ensure that nobody wants you as a coalition partner in the future.

Yes, some countries with PR have government stability issues. So does the US, see government shutdowns, accusation of obstructionism, etc. That's just an inevitable consequence of humans disagreeing about policy.

I can make two observations that explain some of it.

Other aspects of a language can matter more than the types. Python, for example, was a well constructed language in many ways that make up for much of its disadvantage on the typing side.

Many commonly used statically typed languages have poor type systems. They will both fail to detect some important errors (like null pointers) and get in the way when writing more generic code.

I used to do this sort of thing in Python. But then I realized that if I wrote my code in something like C++, I had fast code without running through all these hoops. Then I learned Rust which has many of advantages of Python in terms of higher-level niceties. Today, its just way easier to write some Rust code for a simulation then go through all the hoops to make Python code fast enough.

Speaking as someone who despises Tailwind, my impression is certainly that HN generally likes it. It is amusing that somebody else gets quite a different impression. Shows how biased human memory can be.

Many people on this site seem in favor of these age-based government restrictions on working. But at the same time, it seems they also opposed age-based government restrictions in many other areas like access to particular kinds of online content. These positions seem like a contradiction to me. Why do they think that it is reasonable for the state to restrict a child's ability to work but not their access to online content?

Rust's large file sizes are due to relying on static linking, not particularly the extra bounds checking.

Because even though typescript improves on Javascript and even golang, it still is much less nice than Rust.

From a Rustacean's perspective: Golang is a no go because it lacks enum types, sensible error handling, generics (I think it has some version of this now), non-nullable types, or macros. Once you've gotten used to using these kinds of features in Rust, it is really annoying to go back and work in a language that lacks them. Basically, golang takes such an opposite design approach to Rust, that if you like Rust you'll probably hate golang.

We also find that once you get used to the borrow checker, we mostly don't miss garbage collection. And garbage collection isn't a panacea either, as almost any large project still ends up with memory leaks caused by stray references.

So, basically, we like Rust and think its a well designed language. It is quite frankly better, as a language, than any of the alternatives that we could be writing in. As such, it'd be nice if we could develop GUI applications in it.

Are you sandboxing your applications when you run them on your dev machine?

So... if I'm using a third party crate, I'm already trusting it not to do bad things in my running application. Why is it such a big deal that it could do bad things during build time just before I run it? If I'm using a third party crate... I've got to trust it one way or the other. So what's the big deal here?

They run Rust compiled to WebAssembly.

I've found success in such cases by splitting the struct in question. This example is a bit contrived, but you could do something like:

    self.counter.inc();

Where `self.counter` is a new struct that holds `x`. Because `counter` is its own struct field, I can call mutable methods on it while holding mutable references to other fields.

What I've found is that often the current "object" naturally decomposes into different parts each of which can have their own methods that only need to work with their particular subset of the fields.

Well, I'd say having the option to watch is a win because options are good.

But maybe you don't see it that way. Fine. Perhaps the availability of these other channels is neutral. I think they key point is that it's not a loss.

Essentially, you are paying for the few channels that you actually want and the hundred of other channels are being provided for free. It's a win because you get free channels even if you don't watch them.

The thing is that there is essentially zero cost to providing channels to you that you are not watching. There are costs to sending the signals to your house but that doesn't increase based on how many channels you have access to. There also costs to producing content, but those costs are independent of the number of viewers. Add to that the fact these channels typically have advertising which is a good chunk of revenue, they aren't paid for by your cable service fees.

The result is that the costs involved don't correspond simply a cost per user per available channel. Consequently, it doesn't make sense to charge users that way.

The post you are responding to is probably referring to the Gramm–Leach–Bliley Act. According to some, that act (signed by Clinton) was (somewhat) responsible for the financial crash. But this is certainly a matter of dispute.

Check again, its wonkier then that. E.g. C (#2) shows a description for Java (#5)

> when the file system became hierarchical (it had a very different structure early on).

This leaves me to wonder, what was the structure early on?

> that does not depend on whitespace

This is precisely one of my complaints against XML, it does depend on whitespace. In JSON, I know that any excess formatting whitespace can safely be removed. But excess formatting whitespace is part of the document in XML and I can't know in general whether it can be safely removed or not.

Your short term suggestion appears confused. Panics are already the result of runtime checks. The issue isn't whether or not we have runtime checks, but what to do when those checks fail.

But to your original point, its true that a multiplexing server should probably try to stay up even if there is a bug uncovered in handling a request. But that's precisely why rust allows you to catch panics.