Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gh-116167: Allow disabling the GIL

github.com

Post reply on HN
Print view View original

251–259 of 259 posts

Re: gh-116167: Allow disabling the GIL

#251

Post by progmetaldev »

dimitrios1 wrote: post #209
progmetaldev wrote: post #198

Earlier quoted context omitted.

I truly appreciate your answer, as someone that primarily does C#, but learned Java first back around 2003 to 2005. More so because my son is going to be learning Java next year in high school, and I know he'll be looking to me for help, and I'd like to at least be at the same language version as he's learning. I've also been looking at Go quite a bit, especially from a lot of commentary even recently on YouTube, as…

No problem. I am also a huge Dream Theater fan.

Cool that you picked up on my username. Love lots of progressive metal, from the really heavy stuff, to the noodley jam-band type improvisation.

Re: gh-116167: Allow disabling the GIL

#252

Post by nextlevelwizard »

aunderscored wrote: post #244
nextlevelwizard wrote: post #222

Earlier quoted context omitted.

Thats a lot of words for: yeah, you are right

A lot of words for "yes, but all languages have this problem." The amount of effort to break the type system is the only difference.

any type safe lnguage will indeed "blow up" while python just continues and you dont get as much as a warning. you are wrong take the L

Re: gh-116167: Allow disabling the GIL

#253

Post by progmetaldev »

flakes wrote: post #224
progmetaldev wrote: post #196

Earlier quoted context omitted.

I haven't used Java since v1.5, roughly around 2005. I do use C# quite a bit, and have since v1.1 (I got into .NET through VB.NET at v1.0, as I had just learned VB through schooling). I look back at all the features that have been added over time, and since I have followed along as it has developed, I embrace the changes. They have made my code more concise and easier to read, with less boilerplate. When I think abou…

> I wouldn't be surprised if he's going to be dealing with Java v1.5 instead of the latest features. Well I certainly hope not… LTS for Java 5 probably hit end of life when he was 2. I’d say most likely the version being installed is Java 17, or 11 if theyre really dated. Java 8 would likely be the absolute minimum, mainly due to the industry being so slow to migrate away from it. Newer programmers are unlikely to ev…

I hope not as well, but I went through the same school system. In 1994 I took a computer graphics course, and was taught Apple Basic. It was fun, but I already knew Atari Basic, so it didn't really help other than creatively. The skills did not transfer, even when I went to DOS QuickBasic in 1996! I hope that they have people that understand development, but I won't hold my breath. At least if he is stuck with v1.5, I can use it as an opportunity to increase my knowledge on newer versions, assuming he enjoys the language. I haven't even used or deeply looked into lambdas in Java (but have in a few other languages).

He's enjoyed playing with Lua for Roblox, and I've gotten him to go through some of the easier C# tutorials from Microsoft where the execution happens right in the browser.

Re: gh-116167: Allow disabling the GIL

#254

Post by nerpderp82 »

kelnos wrote: post #218
nerpderp82 wrote: post #133

Earlier quoted context omitted.

I didn't mention C++ at all. Was that my argument? This thread is about Python, the GIL. Mojo was brought up as a way to speed up Python code. C++ predates on C in a similar way to how Mojo predates on Python. At least C++ has extern C. https://docs.modular.com/mojo/manual/python/#call-mojo-from-... > As shown above, you can call out to Python modules from Mojo. However, there's currently no way to do the reverse—imp…

I think the person you're replying to is just trying to use an analogous example; you didn't need to bring it up. Regardless, I think it's a bit alarmist and overly aggressive to assume nefarious intent. Have the developers acted in ways such that this reputation is deserved? Also, little OT, but it took me unreasonably long to understand that you meant "predates" as the verb form of "predator", not as in "comes befo…

They aren't just trying to bring up an analogous example. It derails the discussion, it is a rhetorical device that has no bearing on the conversation at hand.

> Regardless, I think it's a bit alarmist and overly aggressive to assume nefarious intent.

You can think those things. You can try and color my points using whatever language you want. That doesn't make it true, you are putting words in my mouth about "nefarious intent". Mojo is taking Python programmers and their programs out of the Python ecosystem and bring them into their ecosystem.

Thanks for the splaining about predates, I'll continue to use it. Mojo is definitely 'taking booty' from Python.

Re: gh-116167: Allow disabling the GIL

#255

Post by neilkk »

Kranar wrote: post #65
neilkk wrote: post #23

Earlier quoted context omitted.

This isn't correct. TFA said that small threaded programs had been run successfully, but that the test suite broke in asyncio. Async I/O and threads are two different things, and either can be present in real code without the other.

Not quite sure what your comment means exactly or how it implies what I said is incorrect. At any rate, test_asyncio contains a lot of tests that involve threads and specifically thread safety between coroutines and those tests fail. As far as async I/O and threads being distinct, I mean sure that is true of a lot of features but people mix features together and mixing asyncio with threads will not work with this par…

> this release will break any code that uses threads.

> small threaded programs had been run successfully

The second obviously contradicts the first, doesn't it?

> mixing asyncio with threads will not work with this particular release.

That's a very different claim to the first, and one that no longer conflicts with the second, isn't it?

Re: gh-116167: Allow disabling the GIL

#256

Post by bb88 »

bmitc wrote: post #226
bb88 wrote: post #214

Earlier quoted context omitted.

And the python people would just point to multiprocessing...which works pretty well.

Which has its own set of challenges and yet another implementation of queue.

Yes, but the shared-mutable-state issue goes away.

Re: gh-116167: Allow disabling the GIL

#257

Post by bb88 »

bmitc wrote: post #249
bb88 wrote: post #248

Earlier quoted context omitted.

> If I launch 50 threads with run away while loops in Python, it takes minutes to laumch and barely works after. I can run hundreds of thousands and even millions of runaway processes in Elixir/Erlang that launch very fast and processes keep chugging along just fine. I'm not sure that argument helps your position on threading. I once saw a java program spin off 3000 threads doing god knows what. Debugging the fucking…

The point there is that processes in Elixir and Erlang are effectively like functions, in that you do not need to "manage" them in any sort of way. They are automatically distributed across all cores, pre-emptively scheduled, killable, have a built-in inbox, etc. One doesn't need to worry about what concurrency library to use nor manually create mailboxes using queues or whatever else. It just works, and you fire the…

> require a huge amount of ceremony and management

I think Java made it quite easy to spin off threads, and again, it doesn't help the argument. It just made the f'ing thing worse. Race conditions are still f'ing hard to solve. Particularly when a shared-mutable-state exists outside of the program.

Re: gh-116167: Allow disabling the GIL

#258

Post by jen20 »

thisismyswamp wrote: post #232
AdamJacobMuller wrote: post #210

Earlier quoted context omitted.

> Learn golang or rust instead. Bad take. Learn golang and rust and python. You should use the language which is suited to the task, sometimes that's golang sometimes that's python and sometimes it's rust. It's impressive that the python team as a whole continues to improve in such big ways after more than 30 years of development. It's more impressive that the python team managed to navigate 2to3 and come out stronge…

> Learn golang Having to "if err != nil" every single function call is a big put off - imagine having to "try catch" everything in a language like C#!

Two functions solve this (in Go):

    func Must(err error) {
        if err != nil {
            panic(err)
        }
    }

    func Panic[T any](v T, err error) T {
        if err != nil {
            panic(err)
        }
        return v
    }

Re: gh-116167: Allow disabling the GIL

#259

Post by jen20 »

takeda wrote: post #206
purpleidea wrote: post #200

It's neat that this will eventually improve some python code, but at the end of the day, it's still a badly typed language, which will still be slower and less safe than more modern languages. Learn golang or rust instead. Impressive that they are managing this though!

Rust, sure, but typing in golang isn't superior to python's type annotations. Also Rust became a quite popular tool for python extensions, where you can offload performance to rust and business logic to python.

> typing in golang isn't superior to python's type annotations.

Yes it is, in every way. When the first job of choosing to use types is choosing which of the five or so type checkers, each deficient in their own way and incapable of dealing with the poor idioms the language encourages to proliferate, you know you're on the wrong path.

Post reply on HN