Hacker Newsnew | past | comments | ask | show | jobs | submit | rar_ram's commentslogin

I used to use this to analyze ab load testing results. After ipython notebooks (mathplotlib) , its been a long time, since I have looked into this.


I like the concepts introduced in the video. But, the Q syntax hurts my eyes. I am personally, not in favor of fitting my entire program in a tweet. Readability helps!


Readability is subjective and largely colored by your experience. Verbosity or succinctness isn't the problem here; it's that the syntax and semantics of Q are unfamiliar to you. I think it's very important to take a moment to step back and consider how many choices in language design you may be casually taking for granted.

Many mainstream languages today- Java, Python, Ruby, C, PHP etc.- have very similar core semantics and syntax. Choices of keywords and type systems differ, but loads of ideas work the same, especially when you consider idiomatic everyday code- for loops, scalar variables, some superset of the algebraic rules for operator precedence you learn in math class. Whitespace in an expression tends to be irrelevant, but sometimes its absence is significant. To add a scalar to a list, you use a loop. Assignment operators flow right to left. Lists tend to be indexed from zero. How many of these choices are essential and how many are arbitrary? All of these languages are descendants of FORTRAN and ALGOL, sometimes with some ideas from the Lisp family thrown in. They share a common heritage.

Q, K, J, A+ and APL represent an entirely parallel course of evolution. Within this family there is a great deal of mutual intelligibility. I'm very familiar with K, but the Q dialect doesn't surprise me. When learned, it's familar- readable. What did source code look like to you before you learned to program?

The APL family isn't amazing because programs tend to be short; that's a side-effect of the positive properties of these languages. They teach you to write naturally parallel solutions to problems and offer a simple, consistent way to compound together and apply functions to large structures at once. Please don't say "this looks different than I'm used to" and then close your mind to what the paradigm has to offer.


Debugging poorly written or convoluted K programs is much more complicated than debugging equivalent C/C++/Java/Python programs.

It's decent for prototyping though, although I bet most people would prototype just as fast or faster in Python.


I'll grant that the debugging story for K isn't as sophisticated as with many other languages. Having a REPL and preferring programs that are mostly pure functions helps, but there's room for improvement. Tooling is about the community, though- not the language. I think that making documentation, screencasts and generally encouraging the expansion of K's open-source ecosystem will, with time, close that gap.


Correct me, if I am wrong. InfluxDb is written in Golang and not Java as the table 1 mentions in the paper.


I think you are right


Excellent work guys! I had developed a custom caching solution for storm in v0.9.6. Its great that distributed caching is being supported now. I would love to see some more documentation and examples on it.


> Messages are not guaranteed to be delivered, if the client is running behind on processing messages, newer messages could be dropped.

> Messages are not stored until they are delivered, if no client is available to receive the message, then it is dropped without being sent anywhere.

Not sure in which use cases can I use this ? Doesn't this defeat the purpose of having a message queue.


Mist isn't intended to be a message queue, its simply a message passer.

Similar to the old question, "if a tree falls in the woods and no one is there to hear it does it make a sound?" Yes; similarly Mist will send a message whether or not anyone is listening, and will keep sending them whether or not the client is prepared to handle them.


So to the first question, there's not a transactional layer to guarantee the client handled the message. Once a message is sent to the client, it is assumed the client has a mechanism for queuing messages if it can't keep up.

As to the second, the caveat is basically saying that if a message is broadcast and nobody cares about the message (ie: there aren't any subscriptions) then mist isn't going to store the message anywhere, it just gets dropped.


Err, I get that! but I am still wondering on where would I use this ? If I dont need transactional layer or buffering, I could use event listener and dispatcher pattern. Anything more than that, a message queue like ZMQ works. Where does this fit in ?


Oh I see. Sorry for the confusion. The initial need was for a rails app to send data model updates to dashboard clients. Later, as our infrastructure became more micro-service-oriented, mist has been used as a place for the dashboard javascript client to subscribe to a centralized event queue. Each micro-service will publish messages to the mist cluster, and the dashboard can respond accordingly.


How about they fix the public transport system first ? The bay area (united states in general, except for a few places) has the worst public transportation system.

The VTA light rails and buses are nothing compared to new york or even boston for that matter!


> The bay area (united states in general, except for a few places) has the worst public transportation system.

Living in small tech enclaves in the South (e.g. Atlanta, Chattanooga, Raleigh) would make you eat those words. You might be surprised to find these areas are attractive because there is lots of room for leasing out data centers.

MUNI, BART, CalTrain are (albeit, sadly) leagues ahead of anything these cities have to offer.


SV isn't even remotely close to being in the same universe in terms of density, which is needed to make transit really work.


False choice much?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: