AK's weblog - Comments

Clifford Wolf: Eine Replik auf Fefes Lizenz-Bashing

clifford@clifford.at (Clifford Wolf) — Sat, 20 Apr 2013 13:51:33 +0200

Ich hab aus aehnlichen Gruenden vor ein paar Jahren aufgehoert GPL zu verwenden und lizensiere vieler meiner neuen projekte unter der ISC Lizenz:

Equivialent zur 2-clause BSD Lizenz
Laenge der Lizenz: 33 Woerter (plus 78 woerter disclaimer)

ak: About my experience with the Dart programming language

blog@synflood.at (ak) — Wed, 09 May 2012 15:56:11 +0200

Why do you think so? In fact, Go was designed for exactly that kind of task, building massively concurrent servers. I like the brevity and clarity of the Go code in my example, so I need really good reasons why I should replace Go with Dart on the server side.

garywu125: About my experience with the Dart programming language

garywu125@gmail.com (garywu125) — Wed, 09 May 2012 03:39:08 +0200

It will be more better to replace go language with dart language in server side for implement websocket server

Anonymous: Rebooting the baconbird project

blog@synflood.at () — Thu, 20 Oct 2011 03:46:10 +0200

It may not be CPAN, but there is the Go Dashboard.
http://godashboard.appspot.com/package

Christian Walde: Rebooting the baconbird project

walde.christian@googlemail.com (Christian Walde) — Wed, 19 Oct 2011 22:16:02 +0200

"the go runtime is the event-based system, it abstracts away all the details"

That is a perspective on the matter i had not considered before. You might be right on that, especially since the task of writing event-based code in itself is like writing parts of an OS yourself.

ak: Rebooting the baconbird project

blog@synflood.at (ak) — Wed, 19 Oct 2011 20:59:22 +0200

Err, the go runtime is the event-based system, it abstracts away all the details (see e.g. http://swtch.com/libtask/ for preceding work by one of the Go developers). goroutines are not threads. The number of OS-level processes that is created is always limited by GOMAXPROCS.

Philip Durbin: Rebooting the baconbird project

philipdurbin@gmail.com (Philip Durbin) — Wed, 19 Oct 2011 20:38:24 +0200

yeah, that was me at http://blogs.perl.org/users/philip_durbin/2011/10/perl-dropped-and-go-adopted-due-to-concurrency-issues-in-baconbird.html . i hope you don't mind! i've learned a lot from this discussion! and i do plan to give gockel a try, maybe even package it up!

Christian Walde: Rebooting the baconbird project

walde.christian@googlemail.com (Christian Walde) — Wed, 19 Oct 2011 20:12:38 +0200

At its core, the problem you're trying to solve is IO-bound, which means an event-based system the correct solution. (Threads are a tool to be used for CPU-bound problems.)

Right now you still have a few edge cases, like the "request getting stuck" thing i mentioned that might become issues. Additional goroutines might be a bandaid for this, but the docs seem to imply that they'd create more threads, which means you run the risk of exhausting system resources.

The only perfect solution for this would be an event system, but i have to admit, the likelihood of these things occurring is small enough to not bother them.

Which means the simple three-threaded solution you have right now is "good enough" to not have to worry about any issues in real world application.

ak: Rebooting the baconbird project

blog@synflood.at (ak) — Wed, 19 Oct 2011 19:53:49 +0200

I don't understand what you mean by "good enough".

Christian Walde: Rebooting the baconbird project

walde.christian@googlemail.com (Christian Walde) — Wed, 19 Oct 2011 19:08:30 +0200

Alright, so you're opting for "good enough" in the implementation, which makes sense given what it is.

ak: Rebooting the baconbird project

blog@synflood.at (ak) — Wed, 19 Oct 2011 17:52:50 +0200

The continuous loading from the userstream API runs in a different goroutine than the other API calls (like posting a tweet, retweeting, favoriting a tweet, ...). These other API call can run concurrently to the userstream API, but are currently queued in a buffered channel. I could fire off those as separate goroutines, though, since each API calls is an independent HTTP request.

ak: Rebooting the baconbird project

blog@synflood.at (ak) — Wed, 19 Oct 2011 17:49:02 +0200

I totally admit it, I'm dumb, and so I enjoy using programming languages that make things reasonably easy for me.

BTW: I never cried out loud, I merely mentioned it (actually I posted this blog entry to point at my shiny new project, not the problems I had with Perl), others put the focus on my Perl criticism.

Steffen Mueller: Rebooting the baconbird project

smueller@cpan.org (Steffen Mueller) — Wed, 19 Oct 2011 16:55:50 +0200

I've used Perl ithreads in anger successfully. The result is the first generation of Padre's Task API for background tasks. That being said, ithreads are more like a portable variant of fork'ed processes (with additional headaches for XS modules) than what most people expect when you use the word "thread".

Christian Walde: Rebooting the baconbird project

walde.christian@googlemail.com (Christian Walde) — Wed, 19 Oct 2011 16:12:22 +0200

In all seriousness: If you're suggesting to use threading in Perl then that says more about your level of expertise than anything else.

lol: Rebooting the baconbird project

lol (lol) — Wed, 19 Oct 2011 15:57:01 +0200

Noob can't do multithreading in perl in his noob project, cries loud. More at 11.