51–60 of 60 posts
Earlier quoted context omitted.
I'd already made that point by excluding games from my statement. When someone says except for X, bla bla bla, you don't respond by saying yea but I do X.
But you can respond by going "But it's silly to exclude X from discussion". Which is why I have been trying (and, evidently failing) to convey.
Something the site didn't answer, what high-level languages are suitable for writing highly-parallel network code? I need to write some code that does stuff like: given a couple million URLs, download each, extract an element, gather all extracted elements in a list.
This pretty much rules out e.g. Python and Ruby, because the CPython/CRuby interpreters suck at concurrency (there are other implementations available, which are a little better). You can still do many Python processes, which do lightweight switching between I/O tasks somehow (e.g. with Twisted), but then load balancing between processes becomes a PITA. Node.js is similar, there's only one thread running at once. With Node.js (and twisted) you also have to manually "compile" your code for asynchronous style continuation passing style, something humans suck at but compilers do very well.
Now given the task you said, you could take C and epoll/kqueue and write a small framework yourself, but processing the data you got with C might not be too nice.
Or you could use an interpreter or a compiler that does this automatically for you. This is where the choice of language kicks in. In order for the language implementation to be able to effectively organize parallel execution, it needs some information from the language. C doesn't have any helpful information, which is why it often relies on full OS context switches where all machine state is stored and restored (or a non-portable hack with the stack). Something lisp-y with first class continuations might be helpful, but many lisp implementations don't really do concurrent execution well.
So, for a language that concurrently executes network I/O efficiently while still being high level and fast, my recommendation for your task would be: Haskell. There's years of research and engineering work done on just what you're looking for in Haskell. Just forkIO as much as you wish, write your code in regular sequential imperative style, compile for multithreaded execution (ghci --threaded) and let the compiler and runtime do all the hard work for you.
Erlang might do the job too. If anyone knows of other languages with smart I/O multiplexing and co-operative userland threads or fibers (with concurrent execution!), please reply here!
NOTE: my assumption was that you're actually processing the data you're receiving and you're more or less CPU limited. If you're I/O bound, you don't necessarily need concurrent execution and may get away with Twisted or Ruby fibers or Node.js (without using multiple processes and load balancing or task queues).
Really? Go is on there, but ActionScript is not? I realize that the future of the Flash Platform is in doubt, but Flash is still a great choice for a lot of things, like: - This language is good for beginners. - This language is well documented. - I find this language easy to prototype in.
Why would a beginner want to learn a dying technologlash unless you were writing games, Flash was never the right answer.
"This language has a niche in which it is great"
"This language has a niche outside of which I would not use it"
"I enjoy playing with this language but would never use it for "real code""
"I am sometimes embarrassed to admit to my peers that I know this language"
"The thought that I may still be using this language in twenty years time fills me with dread"
Really? Go is on there, but ActionScript is not? I realize that the future of the Flash Platform is in doubt, but Flash is still a great choice for a lot of things, like: - This language is good for beginners. - This language is well documented. - I find this language easy to prototype in.
Why would a beginner want to learn a dying technologlash unless you were writing games, Flash was never the right answer.
I did what I always do when presented with a list like this - I checked out Visual Basic. The list makes no distinction between BASIC, Visual Basic and VB.NET. That killed any credibility the list might otherwise have had, and after realising that it appears to be more of a "what's hot, what's not" list, I stopped reading. It definitely does not do what the title suggests it does. No value.
How inefficient is Ruby really? This tool surprised me. Can any Ruby-ists chime in? http://therighttool.hammerprinciple.com/statements/programs-...
The interpreter in 1.8 and earlier is definitely pretty sluggish; I believe the 1.9 implementation was intended to be quite a lot faster, and JRuby is pretty fast. No idea about Rubinius or IronRuby or other alternative implementations. It's definitely the case that stock Ruby 1.8 is slow for a great many applications, though. Having said that, there's alternatives, and a lot of the time efficiency of execution is no…
"faster" compared to what? "pretty fast" compared to what?
Earlier quoted context omitted.
The interpreter in 1.8 and earlier is definitely pretty sluggish; I believe the 1.9 implementation was intended to be quite a lot faster, and JRuby is pretty fast. No idea about Rubinius or IronRuby or other alternative implementations. It's definitely the case that stock Ruby 1.8 is slow for a great many applications, though. Having said that, there's alternatives, and a lot of the time efficiency of execution is no…
> I believe the 1.9 implementation was intended to be > quite a lot faster, and JRuby is pretty fast. "faster" compared to what? "pretty fast" compared to what?
I did what I always do when presented with a list like this - I checked out Visual Basic. The list makes no distinction between BASIC, Visual Basic and VB.NET. That killed any credibility the list might otherwise have had, and after realising that it appears to be more of a "what's hot, what's not" list, I stopped reading. It definitely does not do what the title suggests it does. No value.
I think it's safe to assume the rankings are for VB.NET.
Earlier quoted context omitted.
I think it's safe to assume the rankings are for VB.NET.
I doubt it. VB.NET does what C# does. There are more VB.NET code searches on MSDN than there are C# code searches, which doesn't align with the ranking in the article. The rankings make more sense when applied to VB6 and earlier.
The only thing that's certain is that language popularity surveys are painfully easy to cherry-pick.
Earlier quoted context omitted.
The interpreter in 1.8 and earlier is definitely pretty sluggish; I believe the 1.9 implementation was intended to be quite a lot faster, and JRuby is pretty fast. No idea about Rubinius or IronRuby or other alternative implementations. It's definitely the case that stock Ruby 1.8 is slow for a great many applications, though. Having said that, there's alternatives, and a lot of the time efficiency of execution is no…
> I believe the 1.9 implementation was intended to be > quite a lot faster, and JRuby is pretty fast. "faster" compared to what? "pretty fast" compared to what?
I was not trying to be precise though, just give a feel for the different implementations.