Видео

is it still posible to signup?

Sum types and subtyping are similar right?

Make sure to subscribe to our designated Durable Computing channel, where we talk more about Golem 💪 www.youtube.com/@DurableComputing

Nice demo, congratulations on the 1.0 launch! During the demo Daniel says that it's impossible to update the worker under certain conditions: namely when interface changes (though it seems like in the demo only the implementation was changed?). That brings a more general questions of how to evolve worker states: e.g. how to migrate the state from test2 to test22 atomically during update? And is there a shortcut for common cases, e.g. adding a new field with default value to the State class?

amazing interview indeed

Great trolling, none of these are trully a problems of Rust, those are issues with Scala.

Too good to be true?

John, here it Goes

I'm learning SCALA right now. Why does it need WASM?

Since Java got lambdas and streams, Scala does provide very few advantages. And tones of complications.

Scala is great language. Thank you for supporting

very nice detailed explanation for beginners

Its a must watch, thanks for this session

Why the fight when you can use Loom inside the ZIO or Kyo or Cats Effect one of these days !! 👍😎 ... This requires a heavy rewrite of these tools but it's possible or at least more productive than fighting 😅😇

Great video Yisrael ❤

Nice, I was waiting for next vide ;-=

It's no Clojure... I have had no end of issues with Scala and backwards compatibility. Even just simple version changes w/libraries. Not with Clojure. I like Scala, but I love Clojure.

If you have multiple instances, the STM cannot solve the transaction problem, right?

Hey John, really cool and comprehensive subject, thanks for your contributions to the Scala community and to helping improve engineers. I would have a suggestion for a topic for your open-source series, which would be open-sourcing a commercial project.

she got a glimpse into the Matrix sqeeze the people but not so much that they'll break

Difficult to follow due to the ambient room reverb. It's generally better to use a mic.

39:10 Isn't Scala.JS very much integrated in Scala?

34:10 scala-cli is probably much better than cargo

i am learn a lot from scala to understand rust

Dependency Injection Attacks [19:26] 😂🤣😂🤣

Scala value prop (for me at least): write reliable concurrent code on the JVM, easily.

This is great! I like seeing things process.

Excellent stuff, Nabil. I appreciate seeing the progression of the DSL and how it reached its awesome current state.

What you describe with "you say what you want to do" is actually a command on CQRS, as I said you can apply your Flows as an abstraction that behind the scenes use CQRS + ES (each flow step is one command that generates 1 to n events)

Some comments related with your comments on event sourcing: - you never retry events, you retry a command (and if the command fails 0 events are generated), events are always facts that happened in the past and hence there is no need to retry anything (commands are actions that produce events) - I do agree in most cases it's true using ES is accidental complexity and that is a new paradigm, but I dont agree that makes you change ALL your application. If you follow DDD it will only affect a part of your application, normally a bounded context where CQRS + ES is justified - Also you don't mention that once you have the events stored is super easy to reply them and create new views or feed other aggregates, in a super natural way compared with a traditional "store snapshot" approach with CRUD - Kafka is not a good fit for event sourcing as it doesn't have optimistic locks, I saw super good implementations using Postgres, event sourcing is NOT event streaming, it's a style of how you store your events - The example of the shopping cart is actually a good fit for event sourcing, for example when you need information for analytics it's super easy to replay all events from our users and create different views, but if you read from transactional tables you miss lot of information relevant for data science models - I actually think you can apply durable computing on top of event sourcing, they are compatible things solving different concerns, event sourcing is used to reflect business (it's linked to domain) where durable computing is about fixing non-functional issues like failures, hardware retries, etc. You can apply both together

Really enjoying this series - thank you both, Nabil and John!

Probably the most convoluted implementation of tic tac toe I've ever seen 😅

Thanks Daniel, great session!

Here he goes! 💪💪

Pragmatist here: Correct me if I am wrong but as far as I can tell Scala has the following to learn from Rust: 1) It has to learn to work with out the JVM (or any kind of run-time system). Requiring the JVM implies bloat and poor performance. That excludes use of Scala from much of the work I do. 2) It has to learn to work without a garbage collector. A garbage collector introduces unpredictability in performance. It also excludes use of Scala from much of the work I do. 3) It has to learn to run in only kilobytes of code space on micro-controllers and the like. 4) It has to learn that maths is great and all, but maths is limited. Maths does not have a solution for the many body problem, for example. As for monoids, I had them surgically removed as a child.

Scott Wlaschin - Designing with capabilities ruclips.net/video/RqlnWv6NZos/видео.html

My bald angel <3

Thank you, truth was expressed!!!!

why another parsing library?

Thanks for the nice talk 😊. I have a question: What about doing the final approach with union types? I tend to favour polymorphic variants for type errors so you don't need to create useless wrappers for each error you want to "rethrow". Is that possible in Scala 3?

What would you learn as First language for absolute Beginners? I found another functional lang called Racket.

0:17 In this talk I’m going to cover a number of topics. Here is my short plan. First, I’m going to convince you that graphs are important. Next, I’ll present to you a data structure that I’ve come up with for graphs. In the end, you’ll see how a domain can be modeled using Scala generic types. I use this approach in my current project. 0:47 So, let’s begin. Why do I think graphs are important for us? 0:57 It's pretty obvious that we rely on associations in our mental processes. And associations build a sort of a graph. Our concepts too build an interconnected graph of definitions. Wikipedia is a vivid example of it. In communication though we transform internal representation into a sequence of sounds. 1:28 These boys are testing a new communication line. The boy on the right wants to pass a message to his friend. We can’t know what he is about to say. This information is present only in his mind. 1:49 Now he articulates some words. These words come sequentially, one after the other. The relations between words are hidden. They are encoded in a form that is specific to a particular natural language. 2:10 The boy on the left knows this language. That’s why he is able to decode the message. And a network of associations lights up in his mind. 2:24 So, what is the novelty of the project, that I’m working on? The goal is to keep and to send information in the form of a graph. 2:40 Here I listed the features of the project. 2:43 As I’ve shown you, the format is native to human mind. We sometimes borrow inventions of the nature, and it brings new, often unexpected, opportunities. In this project, we explore what we can get. 3:03 A crucial decision was to represent all connections explicitly. There is no need to reconstruct them on receiving a message. A machine can compare it to the graph it has already accumulated. 3:21 Multiple channels of perception get recorded in one go. Relations between their parts provide meaning to each channel over its bounds. It can solve the problem of naming one thing different names. 3:40 It is expected that the amount of data will grow gradually. Fresh data will emerge at a number of unrelated locations. And with time passing these scattered databases will begin contacting each other. There is no centralized board of experts creating an ontology that should be useful for everyone. 4:12 You would agree, the denser the connections between pieces of data the more value it gives us. Possible applications range from creating a new variety of sites on the Internet to robotics. 4:30 To illustrate what a multimodal graph is, I took textual modality and visual modality. 4:40 In this slide you encounter some text about a cat and a picture of this cat. In your mind you associate the letters in the word “cat” to the collection of pixels in the center of the image. In the multimodal graph below we find the word as a red vertex in a yellow pyramid. The collection of pixels is the vertex in a green pyramid. An explicit red edge connects both vertices. 5:23 What does a multimodal graph look like? As an example, let’s take the textual modality. This modality keeps connections between letters, words and phrases. 5:42 At the top, we have the root vertex of the binary layer. Its first edge means zero. Its second edge means one. The root vertex is the starting point when writing any word. Binary character codes spring off the root vertex. This layer of a graph is idempotent. Character codes don’t get duplicated. 6:07 At the bottom of the slide, we have a type vertex. All word clusters get connected to it. The type vertex helps when a vertex ID needs to be converted back into a string. IDs not connected here are not words and must not be processed. 6:18 I have drawn a blue line around clusters that represent the letter c. Its ASCII code is ninety-nine. In binary form it’s one, one. Then three zeros. And again one, one at the end. A binary cluster usually consists of two vertices. Zero is encoded by following the edge of the first vertex. One is encoded by following the edge of the second vertex. 6:54 This time, the blue line goes around the letter “a”. You might have noticed that the final digits zero and one are close to the root vertex. This arrangement of digits removes the need to reverse them on reading 7:13 The last letter of the word “cat” is “t”. Please have a look at the cluster located at the bottom. It still belongs to the binary layer of the graph. But it has three vertices instead of two. It’s because the cluster lies at the border of the binary layer. It needs an extra vertex to build a connection to the adjacent layer. 7:45 Here we are on the other side of the border that separates the two layers of the graph. This area is inhabited by words that consist of a single letter. 8:00 We climb the pyramid one level up and discover here words that have two letters. These words reference the simplest words we saw on the level below them. This way, we traverse actual letter combinations that were present in the texts that we cared to put into the graph. Comparing the pyramids enables detection of similar words. 8:22 One level up in the pyramid of words, we encounter words with three letters. It is not shown in the picture, but the cluster must actually have four vertices instead of three. An additional vertex is needed in order to build a connection to the layer of phrases. 8:44 Let's move on from this example to the operations that can be performed with multimodal graphs. 8:53 Multimodal graphs can be added. It is easy to do because they possess one special vertex where the process must start. The graph on the left gets missing vertices and edges from the graph on the right. But this doesn’t have be the end of the addition process, because new generalizing vertices may become apparent. 9:22 Multimodal graphs may be searched with a query. Overlapping vertices in the query and the original data produce a result. The algorithm for obtaining a result can get quite complex if it involves generalizations. 9:44 We have concluded the section on the significance of graphs. In the next section, we will discuss the relationship between graphs and linked lists. 9:58 Let’s compare drawing a graph and building a list. In the beginning, both sides are blank. We put the first vertex on the dark surface. It is also at the head of the list. We draw another vertex near the first one. It is at the head of the list now. We connect A and B with a directed edge. Into the list we put a record of it. Let’s add one more vertex to this graph. And one more edge. So, drawing graphs is inherently a sequential process. A list suits best for describing it.

11:00 A graph should not only be created. It should also provide all vertices that are connected to a particular one that is of interest. And these edges are certain to be scattered in all possible places of a graph. Linked lists are notoriously not good for the task. A mutable array would be much faster, as it is most close to hardware. But because of its mutability it cannot be used within concurrent functional frameworks. What could be a solution? 11:41 One possible solution is to embed the list into a tree of vectors. It has all the good properties. Reads and updates by index are effectively constant time. This structure can increase or drop in size. It is immutable and can be put into concurrent frameworks. For example, into the Ref of ZIO. 12:10 Let’s now have a close look at the graph elements. 12:16 Let’s start with the vertices. Vertices of a graph are often called dots or nodes. As you see, a vertex has 6 parts. 12:31 On the left side you see two arrows. They point to the vertex and represent references from other elements of a graph. 12:42 The first part of a vertex contains its own address. It shows that next 5 parts belong to a vertex, and not to an edge. The address of this part serves as the identifier of a vertex for all client code. 13:01 The second part of a vertex references its neighbor within a cluster. Vertices of a cluster build a ring. 13:13 These two parts of a vertex count incoming and outgoing connections. These numbers are useful when checking if two vertices are already connected. 13:27 The last two parts of a vertex lead to incoming and outgoing edges. Each kind of edges forms a doubly linked list. 13:42 Now, let’s turn to edges. 13:46 An edge connects one source vertex to one target vertex. An edge is simultaneously present in two lists of edges. An edge has 6 parts. It’s as many as in a vertex. 14:03 Again, you see two arrows on the left. All references to an edge go to its first part. 14:11 The first three parts of an edge relate to its source vertex. 14:17 The last three parts of an edge relate to its target vertex. Traversing this list of edges one collects all sources leading to a target. 14:32 As I’ve already mentioned, vertices and edges occupy equal space in memory. They both consist of six parts. We can put them into a sequence like this. 14:50 The sequence can be split into six ones. Please note that the addresses have changed. 15:00 Each of the six sequences is an address store. It is called so because it keeps its own addresses as values. It is embedded into its own tree of vectors. A cursor tracks the next position that is available. 15:27 Let’s look at the operations that an address store offers. The append operation starts at the address zero. This address is reserved for metadata. It’s the only place with no restrictions. Any number can be written here. 15:50 Next, the cursor moves to the address one. This time we can’t write a number that is greater than the address. 16:00 When the cursor moves further, we have a broader choice of values. At address two, we can write zero, one or two. 16:10 This process can continue on and on. 16:14 Let’s now have a look at the update operation. Suppose we want to replace the value that is kept at the address one. We can place here zero, one or two. 16:30 Finally, we’ve come to the delete operation. The deleted element of an address store gets replaced with the last one. 16:41 The code implementing deletions is most intricate. It is roughly two thirds of the code base. 16:55 We have finished the section about the data structure and arrived at modeling it with Scala generic types. 17:05 I have devised a way of organizing Scala code. It is unusual but it has its merits. What is normally called a class occupies a whole directory. Class fields reside in a dedicated file. Each method has its own file too. 17:30 Every class of a business-domain is a generic type. Its type parameters define the field types. Here we’ve got a database entry. It contains some content. And it can be found on some path within a certain address store. 17:57 All methods are implemented as type classes. A concrete implementation is summoned at the call site. 18:06 The IsLoop method checks if an entry contains its own address. It is a class type with one function “f”. 18:18 Below it we find an implementation as a given. Methods of the content and the path are summoned from their respective companion objects. 18:34 One final ingredient is needed to make abstract types concrete. It’s a factory. It has lots of methods that create business objects of a domain. 18:46 Here we have one of such methods. It creates instances of type Content. The arrow shows how the type parameter is translated into a concrete type. 19:00 Such peculiar design allows writing tests a bit differently. 19:06 If a class is required in a test, it gets declared with just one line. Here we declare the class ContentStub. 19:17 And here we add a method to it by creating a given instance. An entry under test will call this method when it checks if there is a loop. 19:30 Now, that you’ve seen some code, I’d like to emphasize two advantages of this approach. 19:38 Test stubs are easy to create. No reflection is needed. You depend less on a testing library. 19:47 Another advantage is call-site driven development. It means a shift in focus when writing code. You do not create things that can perform certain actions. Instead, you discover actions that things you to have at hand must perform. 20:10 Finally we arrive at the end of the presentation. I believe that multimodal graphs will be used extensively in the future. And I hope that you can see the benefits besides those that I have mentioned.

Amazing work Erik, thank you for pushing the boundaries and making all Kafka clients better ❤

Amazon work Alex, I was on the edge of my seat till the very end

Nice talk. I agree wiht scala-js. We use it for everything in the frontend. And it is soo useful and no context switching between backend and frontend.

I guess it will be F# then😮

These are well made slides, very interesting talk

I have never seen that much tech in 1 talk ! AI, webassembly, frontend backend, java, haskell, Rust! Inspiring, and out of words! Really useful!