Yes, JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
That's not what I am trying to convey here. JVM is amazing and it is a feat that java is as fast as it is and javascript and v8 are order of magnitude slower.
Also even though I also found java too verbose, I kept believing that we need it to be so to write good software. I still enjoy java but it doesn't compare to the ergonomics of typescript for me. And nimbleness of the experience according to me plays a decent role.
Currently for me, either I really care about performance and I default to rust for those applications or I need solutions where the product will evolve quickly over time and I need great DX over performance and I default to typescript for those.
Java definitely has a role to play but its role in my work has certainly diminished.
You're saying it like it's an absolutely good thing. Some (many?) users would rather pay the cost upfront in compilation time (doesn't really matter if it's AOT or JIT) than pay the same cost many times over through a significantly slower runtime. JVM also scales up to supercomputers (and everything in between) if you want it to, so depending on your requirements a single-threaded alternative might not even be an option.
The GIL does not prevent race conditions in your Python code. It only prevents race conditions in internal data structures inside the interpreter and in atomic operations, i.e., operations that take a single Python bytecode. But many things that appear atomic in Python code take more than one Python bytecode. The GIL gives you no protection if you do such operations in multiple threads on the same object.
I think what many will experience, is that they want to switch to multithreading without GIL, but learn they have code that will have race conditions. But that don't have race conditions today, as it's run as multiple processes, and not threads.
For instance our webserver. It uses multiple processes. Each request then can modify some global variable, use as cache or whatever, and only after it's completely done handling the request the same process will serve a new request. But when people see the GIL is gone, they probably would like to start using it. Can handle more requests without spamming processes / using beefy computer with lots of RAM etc.
And then one might discover new race conditions one never really had before.
If you are writing Python code, the GIL can already be dropped at pretty much any point and there isn't much way of controlling when. Iirc, this includes in the middle of things like +=. There are some operations that Python defines as atomic, but, as I recall, there aren't all that many.
In what way is the GIL preventing races for your use case?
It is not about your code, it is about C extensions you are relying on. Without GIL, you can't even be sure that refcounting works reliably. Bugs in C extensions are always possible. No GIL makes them more likely. Even if you are not the author of C extension, you have to debug the consequences.
I mean that, if the GIL didn't prevent races, it would be trivially removable. Races that are already there in people's Python code have probably been debugged (or at least they are tolerated), so there are some races that will happen when the GIL is removed, and they will be a surprise.
The GIL prevents the corruption of Pythons internal structures. It's hard to remove because:
1. Lots of extensions, which can control when they release the GIL unlike regular Python code, depend on it
2. Removing the GIL requires some sort of other mechanism to protect internal Python stuff
3. But for a long time, such a mechanism was resisted by th Python team because all attempts to remove the GIL either made single threaded code slower or were considered too complicated.
But, as far as I understand, the GIL does somewhere between nothing and very little to prevent races in pure Python code. And, my rough understanding, is that removing the GIL isn't expected to really impact pure Python code.
My understanding, is that many extensions will release the GIL when doing anything expensive. So, if you are doing CPU or IO bound operations in an extension _and_ you are calling that operation in multiple threads, even with the GIL you can potentially fully utilize all of the CPUs in your machine.
> removing the GIL isn't expected to really impact pure Python code.
If your Python code assumes it's just going to run in a single thread now, and it is run in a single thread without the GIL, yes, removing the GIL will make no difference.
> If your Python code assumes it's just going to run in a single thread now, and it is run in a single thread without the GIL, yes, removing the GIL will make no difference.
I'm not sure I understand your point.
Yes, singled thread code will run the same with or without the GIL.
My understanding, was that multi-threaded pure-Python code would also run more or less the same without the GIL. In that, removing the GIL won't introduce races into pure-Python code that is already race free with the GIL. (and that relatedly, pure-Python code that suffers from races without the GIL also already suffers from them with the GIL)
Are you saying that you expect that pure-Python code will be significantly impacted by the removal of the GIL? If so, I'd love to learn more.
> removing the GIL won't introduce races into pure-Python code that is already race free with the GIL.
What do you mean by "race free"? Do you mean the code expects to be run in multiple threads and uses the tools provided by Python, such as locks, mutexes, and semaphores, to ensure thread safety, and has been tested to ensure that it is race free when run multi-threaded? If that is what you mean, then yes, of course such code will still be race free without the GIL, because it was never depending on the GIL to protect it in the first place.
But there is a lot of pure Python code out there that is not written that way. Removal of the GIL would allow such code to be naively run in multiple threads using, for example, Python's support for thread pools. Anyone under the impression that removing the GIL was intended to allow this sort of thing without any further checking of the code is mistaken. That is the kind of thing my comment was intended to exclude.
> But there is a lot of pure Python code out there that is not written that way. Removal of the GIL would allow such code to be naively run in multiple threads using, for example, Python's support for thread pools.
I guess this is what I don't understand. This code could already be run in multiple threads today, with a GIL. And it would be broken - in all the same ways it would be broken without a GIL, correct?
> Anyone under the impression that removing the GIL was intended to allow this sort of thing without any further checking of the code is mistaken. That is the kind of thing my comment was intended to exclude.
Ah, so, is your point that removing the GIL will cause people to take non-multithread code and run it in multiple threads without realizing that it is broken in that context? That its not so much a technical change, but a change of perception that will lead to issues?
> This code could already be run in multiple threads today, with a GIL.
Yes.
> And it would be broken - in all the same ways it would be broken without a GIL, correct?
Yes, but the absence of the GIL would make race conditions more likely to happen.
> is your point that removing the GIL will cause people to take non-multithread code and run it in multiple threads without realizing that it is broken in that context?
Yes. They could run it in multiple threads with the GIL today, but as above, race conditions might not show up as often, so it might not be realized that the code is broken. But also, with the GIL there is the common perception that Python doesn't do multithreading well anyway, so it's less likely to be used for that. With the GIL removed, I suspect many people will want to use multithreading a lot more in Python to parallelize code, without fully realizing the implications.
> Yes, but the absence of the GIL would make race conditions more likely to happen.
Does it though? I'm not saying it doesn't, I'm quite curious. Switching between threads with the GIL is already fairly unpredictable from the perspective of pure-Python code. Does it get significantly more troublesome without the GIL?
> Yes. They could run it in multiple threads with the GIL today, but as above, race conditions might not show up as often, so it might not be realized that the code is broken. But also, with the GIL there is the common perception that Python doesn't do multithreading well anyway, so it's less likely to be used for that. With the GIL removed, I suspect many people will want to use multithreading a lot more in Python to parallelize code, without fully realizing the implications.
> Switching between threads with the GIL is already fairly unpredictable from the perspective of pure-Python code.
But it still prevents multiple threads from running Python bytecode at the same time: in other words, at any given time, only one Python bytecode can be executing in the entire interpreter.
Without the GIL that is no longer true; an arbitrary number of threads can all be executing a Python bytecode at the same time. So even Python-level operations that only take a single bytecode now must be protected to be thread-safe--where under the GIL, they didn't have to be. That is a significant increase in the "attack surface", so to speak, for race conditions in the absence of thread safety protections.
(Note that this does mean that even multi-threaded code that was race-free with the GIL due to using explicit locks, mutexes, semaphores, etc., might not be without the GIL if those protections were only used for multi-bytecode operations. In practice, whether or not a particular Python operation takes a single bytecode or multiple bytecodes is not something you can just read off from the Python code--you have to either have intimate knowledge of the interpreter's internals or you have to explicitly disassemble each piece of code and look at the bytecode that is generated. Of course the vast majority of programmers don't do that, they just use thread safety protections for every data mutation, which will work without the GIL as well as with it.)
> if the GIL didn't prevent races, it would be trivially removable
Nobody is saying the GIL doesn't prevent races at all. We are saying that the GIL does not prevent races in your Python code. It's not "trivially removable" because it does prevent races in the interpreter's internal data structures and in operations that are done in a single Python bytecode, and there are a lot of possible races in those places.
Also, perhaps you haven't considered the fact that Python provides tools such as mutexes, locks, and semaphores to help you prevent races in your Python code. Python programmers who do write multi-threaded Python code (for example, code where threads spend most of their time waiting on I/O, which releases the GIL and allows other threads to run) do have to use these tools. Why? Because the GIL by itself does not prevent races in your Python code. You have to do it, just as you do with multi-threaded code in any language.
> Races that are already there in people's Python code have probably been debugged
Um, no, they haven't, because they've never been exposed to multi-threading. Most people's Python code is not written to be thread-safe, so it can't safely be parallelized as it is, GIL or no GIL.
That may be your definition, but that's not everyone's definition. Wikipedia, for example, says:
> Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.
ULAs aren't the same as a NAT setup. You can assign all of your local devices stable ULAs _and_ also reputable addresses that randomly change. If you do that, there is no need for NAT.
Right, I picked the word “eroded” because it’s not like the benefit is completely gone, but it’s not what was originally envisioned.
I do ULA+global unicast too, but it would be far simpler if I actually had a reliable stable prefix and could just use that. I put my ULA addresses in local DNS (because that’s why I need ULA, I need to not worry about rewriting my zone file whenever my cable modem reboots), but that means I have to do split horizon DNS. I wish I didn’t have to. (Yes I do mDNS too but I need real DNS for lots of use cases.)
> Right, I picked the word “eroded” because it’s not like the benefit is completely gone, but it’s not what was originally envisioned.
You also said
> NAT is here to stay
Which, uh, it sure sounds like you're not using IPv6 NAT. In fact, it looks like aside from probably being confused about what "split horizon DNS" is [0] your setup is exactly like mine. Address autoconfig for both a annoyingly-frequently-changing global prefix, and a constant ULA prefix with DNS entries for the ULA addresses.
[0] Does your DNS server serve LAN _and_ WAN clients? If it doesn't, and it only serves LAN clients, you're almost certainly confused.
They pretty clearly talk about public hosts, so it seems quite likely that they are in fact doing split-horizon DNS (i.e. machine1.site.com will be resolved to an ULA address if the query is coming from the same subnet, or to the public address otherwise).
IF homie is serving public-facing DNS for the site with the same server that's serving local DNS, then yeah, sure, split-horizon DNS is probably the thing that you'd do. But:
> They pretty clearly talk about public hosts
Thing is, I ALSO have public hosts on my LAN. And they're in both the public DNS and in the DNS on my LAN. But public DNS is not served from my local DNS, so I don't have a split-horizon setup.
The mere act of maintaining (in two entirely unrelated DNS servers) records for the same resource but with different data doesn't make a split-horizon setup. If it did, then I could reasonably claim "I'm running a split-horizon setup for mit.com!" just by adding an A record for "mit.com" to my local DNS server, despite being neither connected to any MIT internal networks, nor in a position to serve any data to MIT's Internet clients.
I do DNS such that the same hostname, which I control, resolves to the ULA address if asking locally, but the public address if asking from an external machine. But it's not literally the same server, I use DNSimple for my public DNS and unbound on my local DNS. You can split hairs about whether split horizon means "the same DNS server serving both views" or not, but that's a needlessly pedantic snipe. But to cut off this argument: Sure, you're right. You score one internet point, I used the word "split horizon" incorrectly. You're very smart.
It's not generally good form to cherry-pick things I said from other threads and put them out of context. "NAT is here to stay" can for the purposes of this discussion mean "Thinking about global vs local addresses is here to stay", even if it's not NAT per se that is happening (ie. if you're using a ULA + global unicast, like I do.)
> you're almost certainly confused
I'm not confused. I do split horizon DNS. I serve WAN and LAN clients (not currently from the same DNS server, although that's what I'd prefer to do. The same hostnames are currently configured in different DNS systems depending on who's asking, hence "split horizon".)
To be clear, here's my setup. It's not unique or interesting compared to any other "home lab" setup:
- I have multiple machines that I want to be able to access by DNS name externally.
- I also want to be able to use those same DNS names for local configuration, to keep things sane.
To do this, I have two options:
1) Use the publicly-routable global unicast addresses in my DNS, and make a system to keep them updated in a reprefix
2) Use a ULA prefix for local DNS, and the global unicast equivalent addresses for public DNS, and make a system to update only the public DNS when I get reprefixed
I chose option (2) because I want to mitigate the damage that happens when my ISP reprefixes me. (It's happened 6 times over the past year, it's not uncommon.)
When I get reprefixed, any local traffic that's using DNS to lookup the address keeps working as usual, because the ULA address doesn't change. I have to worry about reconfiguring public DNS, but that's the lesser of two evils IMO:
Because if I picked option (1), I'd have to reconfigure public DNS and my local traffic would all be disrupted while the reprefix happened: My hosts would all be trying to communicate with one another via their old prefixes, and failing until DNS reconfigures.
And this is all not to mention that I have to do the exact same reconfiguration dance with my firewall config: When I get reprefixed, my pf.conf is now referencing invalid IP's. I disable-by-default so it's not a security issue, but it's something that I had to solve with automation (in my case, by templatizing my pf.conf and writing dhcpcd hooks that reconfigure it when the prefix changes. It wasn't trivial.)
Now, to get back to my original argument: IPv6's simplicity benefits "erode" when you consider that worrying about internal vs external addresses is still something you have to deal with in the real world, at least in residential deployments where you don't own your own prefix. Granted: These issues are inherent to any system where your ISP is dynamically assigning you IP's, but it's important to understand: Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work, due to it being the real world.
> It's not generally good form to cherry-pick things I said from other threads...
What? Press "parent" on the comment of yours that I'm quoting from right now four times. You'll find the comment of yours where you say "NAT is here to stay" right here in this comment tree.
> To be clear, here's my setup.
Yep, that's my setup as well, except I don't screw around with applying per-host inbound traffic firewall rules at my router. Either traffic is worth blocking to an entire subnet, or it gets blocked at the host that cares about it. Saves a ton of maintenance.
> Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work...
Yep. It's less complexity than with NAT. Substantially so. That's like the entire point. The additional complexity you keep pointing at is because of a feature that you can't have with typical end-user NAT... the ability for each host on your LAN to have a globally-accessible IP address. And you can get rid of most of what you're complaining about by paying for a static prefix and getting it tunneled to your site, as folks elsewhere in this sprawling conversation tree have mentioned (or getting friendly with a local clued-in ISP and having them statically-assign you one).
Apparently there is only 1 level that no one (except the creator) has beaten. Its only 10-20 seconds long, but is so hard that its not clear if anyone will complete it before the servers shut down: https://www.youtube.com/watch?v=KmikpEVCuZE
Can't speak for OP, but Google pushes through too many "standards" that are just "Do what Chrome already pushed to prod, or else users will think your browser is broken". Could be the same thing here
> The law prohibits or chills a substantial amount of First Amendment protected activity and is unnecessary to prevent interference with police officers given other Arizona laws in effect,” [Federal Judge] Tuchi ruled.
The original Republican sponsor of the measure has been unable to find someone to defend it, as the article notes.
> Republican state Sen. John Kavanagh, who sponsored the measure, has said he was unable to find an outside group to defend the legislation.
There's plenty of instances of this exact thing captured on YouTube. Police can be seen walking up to people filming and placing themselves in close proximity to block views.
