Kolejne spotkanie?

[(gmail)Marcin Matuszak]

Witam wszystkich. 

Mam pytanie, ile osób byłoby zainteresowanych kolejnym spotkaniem ze Scalą?

-- 

Marcin Matuszak

[Przemyslaw Pokrywka]

Cześć

Ja bym się spotkał. Jakieś propozycje formuły / tematu(ów)?

Pozdrawiam,
Przemek

-- 

Marcin Matuszak

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „WrASSE”.
 
Aby anulować subskrypcję tej grupy i przestać otrzymywać z niej wiadomości, wyślij e-maila do wroclaw-scala-enth...@googlegroups.com.
Aby zamieszczać posty w tej grupie, wyślij e-mail na adres wroclaw-scal...@googlegroups.com.
Odwiedź tę grupę na http://groups.google.com/group/wroclaw-scala-enthusiasts
Więcej opcji znajdziesz na https://groups.google.com/groups/opt_out

[wonsky]

Hej,

Ja również jestem zainteresowany.

Pozdrawiam,
Mateusz

[Rafał Sobota]

Hej,

A nie ma ktoś z Was doświadczenia zarówno w Scali jak i w Go, żeby się podzielić spostrzeżeniami?

[Przemyslaw Pokrywka]

Osobiście widziałem tylko kilka prezentacji o Go, ale z tego co z nich wyniosłem, Go i Scala mają niewiele wspólnych obszarów zastosowań.
Go stawiało sobie za cel zastąpienie C w zastosowaniach systemowych. Scala to język bardziej do aplikacji.
Pamiętam, że Go (jako język) wydało mi się znacznie uboższe w możliwości niż Scala ale nie śledzę jego rozwoju. Może ktoś miał doświadczenia lub orientuje się lepiej, to proszę o skorygowanie.

Przemek

[Rafał Sobota]

Dzięki, Przemek!

Na pewno jest uboższy, o czym pisze Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html

Mnie Go kusi żeby przenieść do niego w firmie backend aplikacji mobilnej z Node.js. Myślałem o Scala/Akka jakiś czas temu, ale zasmuciło mnie, że nie mogłem skalować Akki horyzontalnie na Amazonie. Może już to się zmieniło?

W ogóle backend aplikacji w architekturze podobnej do Twittera to dobry przypadek dla Scali? Wszystko się tam rozbija o denormalizację bazy danych podczas zapisu. Nowe rzeczy lecą do wielu koszyków zainteresowanych nimi osób, aby podczas odczytu wyciągać jak najwięcej danych z pojedynczych, dobrze zindexowanych rekordów (w moim przypadku z MongoDB).

Scala ma jakieś własne actorowe podejście do takich rzeczy? Teraz stawiam oddzielne serwery do api i oddzielne do pracy w tle sterowane przez kolejkę. Dodaję kolejne gdy są potrzebne. Nie wiedziałem za to nigdy jak zamodelować własny program w actorach. Dużo tracę?

Pozdrawiam

Rafał

[Przemyslaw Pokrywka]

Trudno mi się wypowiedzieć gdy nie znam architektury tej aplikacji (poza tym, że korzysta z Node.js). Z modelu aktorów korzystałem w wydaniu Scala Actors, z samą Akką nie miałem do czynienia poza lekturą dokumentacji i oglądaniem prezentacji. Czy dużo tracisz nie korzystając z aktorów? To zależy. Niewykluczone, że nic :)) Z moich doświadczeń model aktorów jest dobry w sytuacjach, gdy masz w aplikacji jakiś stanowy obiekt (np. sesja), który potencjalnie mógłby być zmieniany przez wiele wątków równocześnie. Aktor, dzięki zasadzie przetwarzania jednego komunikatu naraz jest w stanie zapewnić integralność tego stanu. W aplikacjach webowych raczej wiele to nie wnosi, bo zwykle w jednej chwili obsługiwany jest jeden request. Za to w przypadku, którym się zajmowałem (komunikacja USSD) miało to zastosowanie, bo do jednego użytkownika (który mógł mieć już rozpoczętą sesję USSD) komunikaty mogło potencjalnie próbować wysyłać wiele aplikacji (oraz gateway USSD).

Druga rzecz to jawna asynchroniczność i obsługa sytuacji błędnych, np. gdy zdalny obiekt wcale nie odpowiada. Nie jest to coś zastrzeżonego dla aktorów (podobnie można programować przy pomocy Futures), ale na pewno ten model to akcentuje. W ten sposób łatwiej jest pisać aplikacje, których poszczególne komponenty (aktorzy) mogą być instalowani na różnych maszynach wedle uznania.

Trzecia rzecz to mechanizm supervisorów dający rozbudowaną kontrolę nad obsługą błędów.

W wypadku Akki model aktorów nie jest chyba jednak najważniejszym powodem, dla którego ludzie wybierają tę bibliotekę. Aktorzy dla Akki są czymś w rodzaju wstrzykiwania zależności dla Springa. To jakaś baza, jednak tak Akkę jak i Springa zazwyczaj bierze się dla ich różnorakich dodatków.

Akka nie dawała skalować się horyzontalnie na Amazonie? Masz chyba raczej na myśli to, że nie ułatwiała tego zadania w jakiś konkretny sposób? Bo przecież aktorów można tam tworzyć programistycznie i samodzielnie podzielić je/ich między maszyny.

Czy backend aplikacji w architekturze podobnej to Twittera to dobry przypadek użycia dla Scali? Oczywiście to zależy od konkretnych szczegółów, ale pewnie to nader przyzwoity default :)) Na pewno szybciej go stworzyć niż w Javie (poza tym będzie się go lepiej utrzymywało i przyjemniej pisało) a chodzić będzie szybciej niż gdyby stał na JRubym. Dystansując przy okazji pod względem wydajności Rubyego, Pythona oraz Node.js.

Osobiście powiem, że model aktorów nie zrobił na mnie jakiegoś piorunującego wrażenia. Owszem, ma swoje plusy, z których skorzystaliśmy w jednym projekcie w BLStream. Natomiast ma też swoje słabsze strony jak np. brak jawnego podanego wprost interfejsu między aktorem a resztą kodu (czyli kontrolowanego przez kompilator zestawu legalnych dla aktora komunikatów) oraz utrudnione testowanie (choć byłoby ono też utrudnione w każdym innym podejściu asynchronicznym). Na oba te problemy są jakieś rozwiązania, ale warto moim zdaniem się zastanowić, czy do realizacji swoich celów nie nadadzą się lepiej najpierw prostsze, bardziej deterministyczne modele programowania?

Zresztą mówi o tym też Jonas Boner na jednej z ostatnich prezentacji ze Scala Days 2013. Radzi on zacząć od programowania funkcyjnego, dataflows, (pomijam teraz jakiś krok), sięgnąć po aktorów w momencie, gdy te środki nie wystarczają. Paul Chiusano wypowiedział się ostatnio, że dla niego aktor jest tak niskopoziomową konstrukcją, że robienie mu marketingu to jakby ktoś wychwalał CountDownLatcha z Javy 1.5 jako receptę na wszelkie bolączki.

Pozdrawiam,
Przemek

[Piotr Henrykowicz]

Hej

Cytując za: http://docs.scala-lang.org/overviews/core/actors-migration-guide.html
Starting with Scala 2.11.0, the Scala Actors library is deprecated. Already in Scala 2.10.0 the
default actor library is Akka.

Może taki trochę wyważanie drzwi, ale być może nie wszyscy wiedzą.

Pozdrawiam
Piotr

> 23 wrz 2013 20:46, "Rafał Sobota" <ravs...@gmail.com <mailto:ravs...@gmail.com>> napisał(a):
>
> Hej,
>
> A nie ma ktoś z Was doświadczenia zarówno w Scali jak i w Go, żeby się podzielić
> spostrzeżeniami?
>
>
> On Mon, Sep 23, 2013 at 9:52 AM, wonsky <dymi...@gmail.com <mailto:dymi...@gmail.com>> wrote:
>
> Hej,
>
> Ja również jestem zainteresowany.
>
> Pozdrawiam,
> Mateusz
>
> W dniu niedziela, 22 września 2013 17:39:20 UTC+2 użytkownik Marcin Matuszak napisał:
>
> Witam wszystkich.
> Mam pytanie, ile osób byłoby zainteresowanych kolejnym spotkaniem ze Scalą?
>
> --
> Marcin Matuszak
>
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „WrASSE”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać z niej wiadomości, wyślij
> e-maila do wroclaw-scala-enth...@googlegroups.com

> <mailto:wroclaw-scala-enthusiasts%2Bunsu...@googlegroups.com>.

> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres
> wroclaw-scal...@googlegroups.com

> <mailto:wroclaw-scal...@googlegroups.com>.

> Odwiedź tę grupę na http://groups.google.com/group/wroclaw-scala-enthusiasts
> Więcej opcji znajdziesz na https://groups.google.com/groups/opt_out
>
>
> --
> Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „WrASSE”.
>
> Aby anulować subskrypcję tej grupy i przestać otrzymywać z niej wiadomości, wyślij e-maila
> do wroclaw-scala-enth...@googlegroups.com

> <mailto:wroclaw-scala-enthusiasts%2Bunsu...@googlegroups.com>.

> Aby zamieszczać posty w tej grupie, wyślij e-mail na adres

> wroclaw-scal...@googlegroups.com <mailto:wroclaw-scal...@googlegroups.com>.

[Przemyslaw Pokrywka]

Jasne, nie zaszkodzi zauważyć, że od dłuższego czasu zaleca się Akkę zamiast Scala Actors, które jest teraz deprecated.

Kojarzę, że ludzie napotykali problemy z implementacją z biblioteki standardowej, mimo że akurat w systemie, w którym wykorzystaliśmy tę bibliotekę nie natknęliśmy się na nic poważniejszego.

Chciałem jedynie zaznaczyć, że sam model aktorów jest taki sam, niezależnie od biblioteki, której się użyje (jeśli ktoś chce się z nim przede wszystkim zaznajomić a nie budować coś na serio).

Pozdrawiam

Przemek

[Artur Opala]

+1

W dniu niedziela, 22 września 2013 17:39:20 UTC+2 użytkownik Marcin Matuszak napisał:

[indool]

Hej,

jestem zainteresowany :]

Co do formy ... to może jakieś mniej formalne spotkanie w którymś z klubów/kawiarni we Wro?

Pozdrawiam,
Łukasz

[Rafał Sobota]

Podoba mi się ta koncepcja.

[Tymon Tobolski]

To ja wam dorzuce kilka keywordów o których warto poczytać

- actors do not compose

- typed actors

- typed channels (blog letitcrash - w zasadzie to caly blog jest warty uwagi)

A co do spotkania - ja sie pisze :)