mdomans

10 ms·

31.
by mdomans 9y ago
Chapeau bas. But apart from my rather obnoxious joking - how the whole Stream and GIL interoperate. I mean, this is technically a complex problem.
32.
by mdomans 9y ago
Here's a question from an old Redis hater (the note is important, since my question is going to be slightly biased - I disagree with a lot of core decisions behind Redis): How is this going to be different from Kafka? And I don't
33.
by mdomans 9y ago
31, professionally since being 20. I think many people mistake that programming is a young man's job. Yet I found out that over time, as I aged, married and had a child - I got better in my work. Many argue that programming is an art,
34.
by mdomans 10y ago
Node.js internally has a small pool of threads. Processing of response/request is by design handled in one thread designated to handle event loop. Therefore - if your handler blocks, the _handling_ of requests will be blocked. Your ser
35.
by mdomans 10y ago
That's correct, but looking at the Python internals it seems that working around the GIL is possible if having this pattern exposed to end programmer.
36.
by mdomans 10y ago
To a certain (high) degree I agree. First of all, when I'm wrote this article by coroutines I meant specifically Python async/await pattern which I don't find easy to use or read. And I agree on Tornado. Over the years I&#x27
37.
by mdomans 10y ago
Also, I've been thinking on what you've written about cooperative multitasking OS'es and why preemptive concurrency took over. Cooperative multitasking is easier in regard to design of OS or language that implements it - but
38.
by mdomans 10y ago
It's not hype really - it's me getting fed up with authors arguing that their software solves every problem. Redis is very good at being data structures store. In regard to Python - generators make sense, coroutines, much less. Th
39.
by mdomans 10y ago
Eventually we come to a point where I agree with you, almost. One exception is Redis/Node.js - I don't like them because they indeed work in certain cases, but that set is much less than what authors of Redis/Node.js advertis
40.
by mdomans 10y ago
Cooperative concurrency and event-based programming are different concepts. You need events for the coroutine since scheduler needs to base trampolining of something. Alas, you can do event based programming without coroutines. Yes, I used
41.
by mdomans 10y ago
I disagree with you and here's why; Opinions of mine were made after trying both Redis and Node.js and finding them in poor state. You can read about Redis's problems here: http://redis.io/topics/latency and
42.
by mdomans 10y ago
I personally quite dislike Redis, which is highly unconcurrent. And don't get me started on Node.js. Of course people do use coroutines - I simple don't think they're a good idea. I think they're a bad idea. They're
43.
by mdomans 10y ago
Not merely a choice of mine to make - working in a team actually makes .subtask better
44.
by mdomans 10y ago
In all honesty .subtask() is more readable for me than .s() Also, I don't want Celery to replace asyncio and/or threading. I was trying to point out that the programming model can be back ported to Python as a way of approaching c
45.
by mdomans 10y ago
I disagree. Most people working on GIL in Python this days are definitely smart, but they're brute forcing the problem. It's not about writing more code, for me, but about writing smarter code. GCD was, for me, an example of such
46.
by mdomans 10y ago
It is for the community. Personally I consider GIL to be an awesome idea and it'd work if we went with a concurrency model that avoids implicit locking
47.
by mdomans 10y ago
Talking about shared memory benefits and overheads in Python is a pretty abstract problem, if you account for how much objects Python interpreter creates and what OS does under certain load levels. I'm merely advocating a different mod
48.
by mdomans 10y ago
Fair point.
49.
by mdomans 10y ago
Yup. If you don't have to care about thread safety on API level, e.g. list, problems such as what's going on currently in gilectomy are no longer yours.
50.
by mdomans 10y ago
This comment and nick together ... flawless victory
51.
by mdomans 10y ago
Assuming that people will stop talking about something because it's not a problem or it isn't real is a bit ... uninformed :) The main point I was trying to make is that if you can force the programmer to guarantee safety, you don
52.
by mdomans 10y ago
I think there are a few other options. But deploying RabbitMQ isn't that hard. I can actually write something about that. Is Linode cheap enough for you?
53.
by mdomans 10y ago
Have you seen a program of any Python conference :D
54.
by mdomans 10y ago
Well, the point I'm making is that I don't see why we we can't have a simple API in Python to define work to do, e.g. access something over the web, without making 30 decisions about the implementation details. And it's
55.
by mdomans 10y ago
And why GIL is the problem, in your opinion? Honest question, explain your point of view.
56.
by mdomans 10y ago
Depends on how much memory we're talking about. In regard to GCD - AFAIK it uses classic posix threads. In regard to GIL, if you can indeed guarantee that each task is atomic and lockless, you can use the same approach pyparralel uses
57.
by mdomans 10y ago
Here's the deal, most tasks I've seen are both CPU and I/O bound, only in different part of the same task. Of course you can very aggressively optimise the design, but sometimes it becomes so unreadable, the cost you incur th
58.
by mdomans 10y ago
AFAIK you can have RabitMQ SaaS these days. And yes, RabbitMQ is very good.
59.
by mdomans 10y ago
I haven't slept through 2012 - I just try to not acknowledge it :)
60.
by mdomans 10y ago
I know of goroutines and comparing Python's coroutines to goroutines is like saying that Porsche and Tata car's are same, since both have 4 wheels.

More ›