Think that’s linked to Assange?

Who can prove it’s not?

The Block is quite a nice place to work.. http://theblock.cafe/

Unfortunately Bitcoin's a dealbreaker for me 😞

How so? They accept euros

How I think it would work best is all using Kafka for messages, with the same 'type' of massages. For example strings as keys, and values avro encoded with schema's. And on each topic there is only one producer. Of all JVM you could use specific records if you want. If you also makes sure the schema's are always backwards compatible I think most things are tackled. Depends a bit on what the product is, but towards the front-end I would expose multiple topics with GraphQL.

This is a big topic for me also, another question I had was: do the microservices need to be written in the same language? I would say of course not but many Enterprise companies are worried that it would be a mess recruiting people...dunno

What do you mean by “multiple sources for the same entity”? Different teams are duplicating work so there are multiple models for the exact same data?

@U0C8489U6 I think it’s fine for microservices to use different languages, but for a number of reasons I advocate that companies limit “approved” languages to two or three with very few exceptions.

Could you please describe a specific example of a structure transformation? I think using Message Brokers like RabbitMQ and ZeroMQ can really help reduce duplicate code. And you could even use foreign language interfaces… e.g. how Clojure can call other languages inside of it. I am researching Vert.x because I could write it in Clojure, Python/Jython or even Jruby/Ruby. You can compare and contrast that to Elixir Umbrella Projects that try to combine monolithic with micro services.

Kafka: I guess a big enterprise bus is one way to solve it, or at least for a subsystem. Polyglot: multiple languages is not an issue.(Just use one lang for service) I guess the issue I tried to mention is being a mediator between multiple "bounded-contexts", that's not exactly model duplication, but thats the part where we start to speak different tongues

You might try Vert.x because it builds a message bus into the tool. They built it for providing micro services (reactive programming) and polyglots. It supports most of the JVM languages. But I need to do a proof of concept… to make sure it’s not another callback hell async problem. It has a promises/futures library to fix that, I believe.

you really love Vert.x 😁

I love the idea of it. But I can’t say yet until I put it in production and load test it.

It’s also not the easiest to setup. But sometimes the easier stuff to setup is a headache in the long term.

The only disadvantage for me so far with Vert.x is that it doesn’t auto scale as easily as Elixir. But Vert.x has so many more advantages. JVM, libraries, machine learning, foreign language interfaces, actor model + reactive model + blocking thread worker pool… and more

Elixir gives you rapid dev with a monolith and umbrella style micro services. But it’s not a general purpose tool for machine learning, cpu number crunching. And Vue JS can give me the rapid monolith advantage.

From my experience using Kafka is a lot easier then VertX. The Kafka ecosystem is huge making it easy to connect basically whatever you want. If you have a legacy service you still need, you can create events from the changes to the the database. Also you have access to almost all languages for clients thanks to librkafka. But maybe most importantly Kafka allows parallel async programming as a whole, with execution of 'simple' synchronous code.

Yes they are, its the task of your operating system to schedule threads and processes on the CPU

but the story is not often as simple

Ahh ok. So it’s a virtualized thread count. They CPU interleaves them (schedules them) on the actual hardware threads?

Well, what your operating system is concerned, a octa-core with HT is actually just 16 cores

it doesn’t “know” that half of them are not physical cores

ahh, the hyper threading makes it look like 2 cores from the operating system’s perspective?

yes

I am researching Clojure threading primitives in comparison to just the actor model. e.g. clojure agents

from what I remember, JVM will map each thread to an O.S. managed thread.

threads are "abstraction" for "concurrency", but we you go down the hardware there is a limit to what is actually done in "parallel"

JVM will introduce (cooperative) fibers\\continuations in near future, which is a lightweight replacement for (pre-emptive) threads, it will allow JVM to manage async tasks in more efficient way, mapping hundreds of thousands fibers to a thread pool matched to real cores in size.

@UH16CGZC2 so something similar to what Go or Erlang does? That sounds amazing! What I was able to find was "Project Loom". Very curious when this will be available in a stable JVM release 🙂

@U8ZN5EHGU correct, in a year or two, also probably tail call recursion, since they changing how stack frames being handled

Can't wait! Also curious how this will be integrated into Clojure since Clojure still needs to support older JVM versions..

¯\(ツ)/¯

Java Fibers will be similar to Actors in Erlang where no locking is needed? I am not sure how Golang fits under the Actor model since it’s really CSP (Communicating Sequential Process) and actually relies heavily on locking/mutexes?

http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

Reading this… it seems Java Fibers are the equivalent of actors with async ability?

@UGQJZ4QNR java fibers is green threads scheduled by JVM with ability to pause and continue by saving fiber stack on heap

ahhh ok. there’s that “green threads” word again. They are virtual threads

@UGQJZ4QNR pretty much, regular Thread will become lower level of abstraction rather for continuous calculations

I am researching if Vert.x can take advantage of fibers

wow. Vert Sync allows for async non blocking calls but with a syncronous style, no callback hell. I am reading dzone website.

It says Vert Sync uses Quasar for Fibers

https://vertx.io/docs/vertx-sync/java/

it says the Fiber is blocked… but the underlieing thread is not blocked. So you get the best of both worlds. And it doesn’t turn your code into spaghetti callback hell

you’ve been yarn bombed

https://i.pinimg.com/originals/64/a7/fa/64a7fad4538494a3699cb10b2cad6d79.jpg

yeah this exactly

thanks for threading this

yeah, gotta keep the concurrency going

we are in a green thread now

its not proper multithreading unless people are majorly confused 😉

is green thread basically a more ecological way of threading then?

a deadlock occurs when two threads are waiting on eachother

huh where did the question go

Clojure can still deadlock? It just happens less often in Clojure?

Sorry, I deleted it. I didn’t want to derail Jane

well, everything can deadlock, its just that Clojure has a mitigation strategy when sharing memory between threads

I am asking because I am trying to figure out if I need lower level threading like Clojure provides. Lower level than actor model.

this may help? http://clojure-doc.org/articles/language/concurrency_and_parallelism.html

(its actually funny that you deleted the question, you kinda illustrated the problem that threaded execution can have, if you are not careful the “world” can change under your feet)

also idk what you’re using to learn Clojure, but http://shop.oreilly.com/product/0636920013754.do has a really (insert punhusky here) thorough chapter on concurrency

My conclusions, faulty as they can be, is that Clojure rules the realm of data crunching because of these lower level concurrency patterns?

I was reading that book. Clojure, Brave and True.

I installed Spacemacs because I knew VIM. And I really don’t want to go back to Jetbrains since that.

(A very famous deadlock problem: https://en.wikipedia.org/wiki/Dining_philosophers_problem )

I will try to write that dinner problem in Clojure… Right now I am comparing Elixir to Vert.x

I think I will bow out; I’m not a specialist on concurrency / threaded programming enough to compare languages and say which one is better 🙂

I am either going to put Clojure on a message bus… or use Clojure inside Vert.x

yeah, same. I have a theoretical basis because of my CS degree, but I wouldn’t know the ins and outs of the concurrency model used in various languages

Elixir sticks to the Actor Model, message passing

no shared memory, no data crunching

but Clojure can give you lower level concurrency, shared memory and also use actor model

You’ve got 3 different models in Clojure, plus anything you can steal from Java, plus lazy evaluation which is kinda generators painted over, and generators are kinda coroutines painted over if you squint 😉

yea, seems like Clojure has the most robust concurrency solutions

Anyway, I’m off to sleep b/c it’s near midnight here. Thanks for bringing this up, it reminded me I need to explore this area in Clojure more 🙂

the only reason I’d use Elixir is because it can do micro services (umbrella) without the headaches

yes, thank you @U82DUDVMH I learn a lot here

(if you’re wondering about what language to choose for a project, my advice would be: don’t look at the language, look at the libraries/ecosystem.)

Clojure/JVM rules in my opinion for that

the JVM rocks!

My new stack probably will be Vue JS, Vert.x and Clojure

seriously

ya, Internet of Things needs the JVM too

oh yeah, also this is an interesting library in development: https://github.com/reborg/parallel

Too difficult to write native code for so many different chips

and with that I’m truly off 😄 o/

night

@UGQJZ4QNR You may find this Reddit thread interesting (and the PDF it links to moreso): https://www.reddit.com/r/programming/comments/3behbh/a_comparison_of_the_jvm_and_the_erlang_beam_vm_pdf/

Ahh, reading it now. The first thought is… actor model alleviates the pausing garbage collection problem because the entire actor’s memory is freed up.

Pausing is much less of a problem with the G1 collector than some of the previous collectors -- and GC is always always improving in the JVM.

Wow, I did’t know that. I haven’t looked at Java in 5 years. This is super good.

I think 1 use case for no pausing GC is high frequency trading algorithms on the NYC exchanges

Yeah, there are some people who think that HFT and Oracle's JVM are not compatible. The makers of the Azul JVM claim that theirs is suitable for HFT.

(I was just reading a Computer World UK article about that from six years ago)

whatever you do leave some ram for off-heap memory. JVM store "the objects" in "heap", but it also needs off-heap memory

off heap memory is for other operating system work?

JVM store the "class-metadata" off-heap, also needs off-heap for the GC operation

ahhh, gotcha

so the GC can do its analysis

e.g. walking down tree structures

it does

I need to learn when the heap is used versus the stack

also JVM does JIT, so needs off-heap memory for code cache

want to know a very interesting comparison of Clojure versus Elixir data type for lists?

sure, tell me

Clojure lists use tries, but Elixir lists use linked lists

tries are fast with reads, linked lists are fast with writes

linked list dont do so well with cache-line

what is cache line?

the procesors core has a cache memory

L1, L2

oh, yes, that cache. gotcha

ok, so then Clojure would use l1, l2 better than Elixir

array usually fits in cache-block

hmm, I wonder if tries (trees) work well with cpu cache

will only know by measuring

it seems to me, Elixir is more geared towards write fast, read slow

and Clojure is geared towards read fast, share memory

mmm I think clojure is geared towards ease

I am leaning towards putting Clojure on top of Vert.x if my proof of concept shows me I can scale it across machines

you may be interested in Graal and its python implementation

but Graal is pretty … experimental

well, this would be for machine learning… not user facing

yes, but Graal is an experimental polyglot VM that allows you to run jvm languages and python intertwined. That said, it is limited in some senses. For one, it disallows some forms of reflection

so, you may end up having some difficulties because of that

and thats why I was warning, its early — but really cool — technology

Ahh ok. Java reflections. Is Java Generics based on reflections?

no, generics are really only a concept in the Java compiler. As soon as your program is compiled, they are gone

I should try a performance test with Graal versus Cython

That would be interesting indeed

To give you an idea…

Cython tree recursion was as fast as Clojure lazy eval. But I don’t know if Cython did some under the hood compile optimization.

Both Cython and Clojure took 1 second to find the 40th nth term in fibonacci.

Python took 1 minute 30 seconds