Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Has anyone fully embraced an event-driven architecture?

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 173 posts

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#161

Post by dmos62 »

malandrew wrote: post #155
dmos62 wrote: post #59

Earlier quoted context omitted.

I'm not very familiar with concurrency at a lower level, so I can't comment on your complaints. What Clojurescript provides is considerably better abstractions that in turn get you correct implementations with much less incidental complexity or hassle.

Not sure why my sincere question about the state of browser execution environment got downvoted, but the general concerns I raised in my first comment weren't about incidental complexity or hassle. They matter and it's great that clojurescript helps with those two. The concern I voiced was about maintaining realtime performance of a responsive user interface. The key issue is that you have a single event loop that al…

> The key issue is that you have a single event loop that all visual and human interactions need to be handled by because that's the only thread that can interact with the DOM.

Isn't that normal? A single event/drawing loop. Would there be an advantage to two threads drawing? Sounds pretty novel.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#162

Post by lloydatkinson »

navd wrote: post #138
stonemetal12 wrote: post #121

Earlier quoted context omitted.

It isn't an alternative, it is a necessary part of understanding the system. You get an event and you have no idea where it came from. That is great from a composability stand point, anything can become an event emitter. On the other hand if that event comes in with bad data, you have no way to correct the issue because you have no idea where the event came from. The more event sources become disassociated from the e…

Thank you for saying the things I didn't think I needed to elaborate on :-)

Your phrasing indicates you positioned it as a replacement/alternative.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#163

Post by CyberDildonics »

bullen wrote: post #86

Yes, I made my own open-source event driven platform: http://github.com/tinspin (rupy is the foundation and fuse is an example implementation tested with 350.000 users and 5 years uptime) The learnings where 2-fold: 1) You need async-to-async capable db clients so that you use 4 threads (potentially on separate cores) for each browser server database roundtrip. Since most databases don't have async capable clients I…

> 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory).

Where did you get the idea that you need a VM and GC to do this? You literally only need a pointer to memory. These boil down almost directly to instructions on a CPU. You literally just atomically load and store to a pointer.

https://en.cppreference.com/w/cpp/atomic/atomic

Java isn't fast, your CPU is fast and the best thing any VM or GC can do is get out of the way.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#164

Post by evanrich »

linseed_213 wrote: post #143
kieranmaine wrote: post #133

Earlier quoted context omitted.

Thanks for the reply. We're using a schema registry but we generally have our schemas spread across multiple repos depending on who owns the topic. I was wondering if they centralized all their schemas under a single repo. I'd like to do this, but I wanted to get some other opinions on the subject.

Evan can correct me if I'm wrong, but I believe it was one centralized service with all the schemas. You could view older versions and make new versions via the UI. It was pretty user-friendly and managing schemas was straight forward. Haven't done anything similar since so no comparison point, but I thought it was fantastic and improved data quality a ton.

This is correct yeah

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#165

Post by bullen »

CyberDildonics wrote: post #163
bullen wrote: post #86

Yes, I made my own open-source event driven platform: http://github.com/tinspin (rupy is the foundation and fuse is an example implementation tested with 350.000 users and 5 years uptime) The learnings where 2-fold: 1) You need async-to-async capable db clients so that you use 4 threads (potentially on separate cores) for each browser server database roundtrip. Since most databases don't have async capable clients I…

> 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory). Where did you get the idea that you need a VM and GC to do this? You literally only need a pointer to memory. These boil down almost directly to instructions on a CPU. You literally just atomically load and store to a pointer. https://en.c…

I would have written rupy in C with atomic pointers and .so/.dll hot-deploy if I had done it now, but:

All concurrent complex datatypes leak memory with C/C++, I don't know why; but if you read the quotes you'll see others try to explain it: https://github.com/tinspin/rupy/wiki

The VM is good for more things than concurrency, like no seg. fault crashes, which is very good to have on a server.

Have you built anything like a 5 year uptime 1000+ concurrent users server with hot-patching every day?

Have you even tried Java?

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#166

Post by CyberDildonics »

bullen wrote: post #165
CyberDildonics wrote: post #163

Earlier quoted context omitted.

> 2) You should use a VM + GC language so that you can use atomic shared memory between cores, that way any core can handle any request efficiently (and access other users memory). Where did you get the idea that you need a VM and GC to do this? You literally only need a pointer to memory. These boil down almost directly to instructions on a CPU. You literally just atomically load and store to a pointer. https://en.c…

I would have written rupy in C with atomic pointers and .so/.dll hot-deploy if I had done it now, but: All concurrent complex datatypes leak memory with C/C++, I don't know why; but if you read the quotes you'll see others try to explain it: https://github.com/tinspin/rupy/wiki The VM is good for more things than concurrency, like no seg. fault crashes, which is very good to have on a server. Have you built anything…

None of this reply even has anything to do with what I asked, which was why you think you need a VM and garbage collection to run specific CPU instructions.

> All concurrent complex datatypes leak memory with C/C++

That's completely ridiculous and shows that you have a very fundamental misunderstanding of how these things work. They are wrappers around functions that do the atomic operations.

https://en.cppreference.com/w/cpp/atomic/atomic_store

Feel free to show me the memory leak you were talking about.

https://godbolt.org/

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#167

Post by ThinkBeat »

narag wrote: post #114
jfoutz wrote: post #41

You're not going to like the answer, but I think it captures some of what you're getting at. Windows 95. Old style gui programming meant sitting in a loop, waiting for the next event, then handling it. You type a letter, there's a case switch, and the next character is rendered on the screen. Being able to copy a file and type at the same time was a big deal. You'd experience the dead letter queue when you moved a wi…

Windows 95. Old style gui programming meant sitting in a loop, waiting for the next event, then handling it. The GUI worked in a single thread, but your whole program didn't need to do that. Being able to copy a file and type at the same time was a big deal. That's not correct. You just needed to create a separate thread for the file operation. For some programmers that was a big deal indeed, the same could be said f…

I am not sure about Windows95, but the MSDOS legacy is single threaded, so you did not have the luxury of having the abstraction represented for you by the operating system.

Some people wrote very inventive software to get around it.

In Windows there is a fundamental concept of the message loop.

The message loop is an obligatory section of code in every program that uses a graphical user interface under Microsoft Windows.

Windows programs that have a GUI are event-driven.

Note that WindowsNT is fully multithreaded, but there is a thread sitting there listening to the event loop still. (of course other threads can do other things).

https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Wind...

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#168

Post by narag »

relaxing wrote: post #140
narag wrote: post #114

Earlier quoted context omitted.

Windows 95. Old style gui programming meant sitting in a loop, waiting for the next event, then handling it. The GUI worked in a single thread, but your whole program didn't need to do that. Being able to copy a file and type at the same time was a big deal. That's not correct. You just needed to create a separate thread for the file operation. For some programmers that was a big deal indeed, the same could be said f…

OP is talking about what you could do using the built in Windows utilities, not what is possible if you write your own file copy-and-note taking utility (which some people did, like Borland Sidekick.)

I guess what you call "built in Windows utilities" is making a call to the GUI shell. It's actually a very complex inter-process communication that happened to be a one-liner from VB and showed that fancy flying folders animation. Not very flexible though.

Writing "my own" code for file copy was not really so low-level, it's what most people understood as programming at the time. Locating the file, opening it, using a descriptor and a loop to copy blocks through a buffer, closing the file, managing errors... that kind of thing.

If you wanted to do the file operation in the background and keep using the GUI for input, you did need to create a separate thread. But that wasn't some black art feat, you just read a book or searched Altavista for a snippet, if in a hurry.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#169

Post by narag »

ThinkBeat wrote: post #167
narag wrote: post #114

Earlier quoted context omitted.

Windows 95. Old style gui programming meant sitting in a loop, waiting for the next event, then handling it. The GUI worked in a single thread, but your whole program didn't need to do that. Being able to copy a file and type at the same time was a big deal. That's not correct. You just needed to create a separate thread for the file operation. For some programmers that was a big deal indeed, the same could be said f…

I am not sure about Windows95, but the MSDOS legacy is single threaded, so you did not have the luxury of having the abstraction represented for you by the operating system. Some people wrote very inventive software to get around it. In Windows there is a fundamental concept of the message loop. The message loop is an obligatory section of code in every program that uses a graphical user interface under Microsoft Win…

I am not sure about Windows95...

I am because I did a few multithreaded programs with it, including what the OP called "a big deal".

Not sure what's your point though.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#170

Post by bullen »

CyberDildonics wrote: post #166
bullen wrote: post #165

Earlier quoted context omitted.

I would have written rupy in C with atomic pointers and .so/.dll hot-deploy if I had done it now, but: All concurrent complex datatypes leak memory with C/C++, I don't know why; but if you read the quotes you'll see others try to explain it: https://github.com/tinspin/rupy/wiki The VM is good for more things than concurrency, like no seg. fault crashes, which is very good to have on a server. Have you built anything…

None of this reply even has anything to do with what I asked, which was why you think you need a VM and garbage collection to run specific CPU instructions. > All concurrent complex datatypes leak memory with C/C++ That's completely ridiculous and shows that you have a very fundamental misunderstanding of how these things work. They are wrappers around functions that do the atomic operations. https://en.cppreference.…

All concurrent maps f.ex.

It's like you're argumenting in a void, have you ever made anything?

Please show some code you have written or stop replying to my comments.

Post reply on HN