Real life Scala feedback from Yammer
"Right now at Yammer we're moving our basic infrastructure stack over to Java"
"Scala, as a language, has some profoundly interesting ideas in it. That's one of the things which attracted me to it in the first place. But it's also a very complex language. The number of concepts I had to explain to new members of our team for even the simplest usage of a collection was surprising: implicit parameters, builder typeclasses, "operator overloahttp://www.blogger.com/img/blank.gifding", return type inference, etc. etc. Then the particulars: what's a Traversable vs. a TraversableOnce? GenTraversable? Iterable? IterableLike? Should they be choosing the most general type for parameters, and if so what was that? What was a =:= and where could they get one from?"
"In addition to the concepts and specific implementations that Scala introduces, there is also a cultural layer of what it means to write idiomatic Scala."
"In hindsight, I definitely underestimated both the difficulty and importance of learning (and teaching) Scala."
"Contrast this with the default for the JVM ecosystem: if new hires write Java, they're productive as soon as we can get them a keyboard."
"Despite the fact that we're moving away from Scala, I still think it's one of the most interesting, innovative, and exciting languages I've used ..."
Показаны сообщения с ярлыком scala. Показать все сообщения
Показаны сообщения с ярлыком scala. Показать все сообщения
среда, 7 декабря 2011 г.
вторник, 6 декабря 2011 г.
[Book]: Actors in Scala
Actors in Scala
Table of contents:
Contents viii
List of Figures x
List of Listings xi
Preface xiii
1. Concurrency Everywhere 15 (download free sample chapter PDF)
2. Messages All the Way Up 25
3. Scala's Language Support for Actors 41
4. Actor Chat 42
5. Event-Based Programming 52
6. Exception Handling, Actor Termination and Shutdown 65
7. Customizing Actor Execution 80
8. Remote Actors 95
9. Using Scala Actors with Java APIs 96
10. Distributed and Parallel Computing with Scala Actors 97
Bibliography 98
About the Authors 100
Index 101
Table of contents:
Contents viii
List of Figures x
List of Listings xi
Preface xiii
1. Concurrency Everywhere 15 (download free sample chapter PDF)
2. Messages All the Way Up 25
3. Scala's Language Support for Actors 41
4. Actor Chat 42
5. Event-Based Programming 52
6. Exception Handling, Actor Termination and Shutdown 65
7. Customizing Actor Execution 80
8. Remote Actors 95
9. Using Scala Actors with Java APIs 96
10. Distributed and Parallel Computing with Scala Actors 97
Bibliography 98
About the Authors 100
Index 101
среда, 16 ноября 2011 г.
Top 10 Reasons Java Programs Envy Scala
"Top 10 Reasons Java Programs Envy Scala"
Черт побери!
Это действительно те вещи, которых мне не хватает в java по несколько раз в день ...
P.S. Для пользования презентацией надо интенсивно использовать zoom in/zoom out.
Черт побери!
Это действительно те вещи, которых мне не хватает в java по несколько раз в день ...
P.S. Для пользования презентацией надо интенсивно использовать zoom in/zoom out.
пятница, 10 декабря 2010 г.
STM in Scala
Scala 2.9, возможно, будет включать STM.
Reference implementation основана на CCSTM.
P.S. CCSTM: A Library-Based STM for Scala
Reference implementation основана на CCSTM.
P.S. CCSTM: A Library-Based STM for Scala
понедельник, 20 сентября 2010 г.
вторник, 19 января 2010 г.
Event-Based Programming without Inversion of Control
"Event-Based Programming without Inversion of Control" from Philipp Haller, Martin Odersky(He designed the Scala programming language and Generic Java).
"...
Most programming models support event-driven programming only through inversion of control. Instead of calling blocking operations (e.g. for obtaining user input), a program merely registers its interest to be resumed on certain events (e.g. an event signaling a pressed button, or changed contents of a text eld). In the process, event handlers are installed in the execution environment which are called when certain events occur. The program never calls these event handlers itself. Instead, the execution environment dispatches events to the installed handlers. Thus, control over the execution of program logic is.
Virtually all approaches based on inversion of control su er from the following two problems: First, the interactive logic of a program is fragmented across multiple event handlers (or classes, as in the state design pattern [13]). Second, control ow among handlers is expressed implicitly through manipulation of shared state [10].
..."
"...
Most programming models support event-driven programming only through inversion of control. Instead of calling blocking operations (e.g. for obtaining user input), a program merely registers its interest to be resumed on certain events (e.g. an event signaling a pressed button, or changed contents of a text eld). In the process, event handlers are installed in the execution environment which are called when certain events occur. The program never calls these event handlers itself. Instead, the execution environment dispatches events to the installed handlers. Thus, control over the execution of program logic is
Virtually all approaches based on inversion of control su er from the following two problems: First, the interactive logic of a program is fragmented across multiple event handlers (or classes, as in the state design pattern [13]). Second, control ow among handlers is expressed implicitly through manipulation of shared state [10].
..."
четверг, 17 декабря 2009 г.
Весенний семестр
Господа, предварительные планы на весенний семестр включают материалы по:
1) Transactional Memory (на примере dstm2);
2) Actor-based concurrency model (на примере Scala).
---
Для TM и Actor будем рассматривать те реализации, которые привязаны к Java/JVM. Что бы полученный опыт легко можно было использовать при разработке j2ee-приложений.
P.S. Это к тому, что сейчас этих материалов прибавится на блоге :)
1) Transactional Memory (на примере dstm2);
2) Actor-based concurrency model (на примере Scala).
---
Для TM и Actor будем рассматривать те реализации, которые привязаны к Java/JVM. Что бы полученный опыт легко можно было использовать при разработке j2ee-приложений.
P.S. Это к тому, что сейчас этих материалов прибавится на блоге :)
вторник, 1 декабря 2009 г.
Множество материала по Scala
На главном сайте Scala обнаружено множество материала - вот. Включая даже, скажем, PhD Thesis.
суббота, 12 сентября 2009 г.
Twitter on Scala
Поверх JVM может работать множество языков. Не только Java, но и Fortress, X10, Groovy, Clojure, Scala, Jython, JRuby, etc. С недавних пор наиболее критичные части сервиса Twitter стали переписывать на Scala. Одна из причин - в JVM лучше чем в Ruby реализована работа с потоками и использование памяти. [http://www.artima.com/scalazine/articles/twitter_on_scala.html]
"One of the things that I’ve found throughout my career is the need to have long-lived processes. And Ruby, like many scripting languages, has trouble being an environment for long lived processes. But the JVM is very good at that, because it’s been optimized for that over the last ten years. So Scala provides a basis for writing long-lived servers, and that’s primarily what we use it for at Twitter right now."
"Also, Ruby doesn’t really have good thread support yet. It’s getting better, but when we were writing these servers, green threads were the only thing available. Green threads don't use the actual operating system’s kernel threads. They sort of emulate threads by periodically stopping what they are doing and checking whether another “thread” wants to run. So Ruby is emulating threads within a single core or a processor. We wanted to run on multi-core servers that don’t have an infinite amount of memory. And if you don’t have good threading support, you really need multiple processes. And because Ruby’s garbage collector is not quite as good as Java’s, each process uses up a lot of memory. We can’t really run very many Ruby daemon processes on a single machine without consuming large amounts of memory. Whereas with running things on the JVM we can run many threads in the same heap, and let that one process take all the machine’s memory for its playground."
Scala - это actor-based language, но в ряде случаев разработчики предпоситают старые добрые блокировки Java.
"But for other parts we’ve just gone back to a traditional Java threading model. The engineer working on that, John Kalucki, just found it was a little bit easier to test, a bit more predictable. The nice thing was, it took minutes to switch code that was actor based over to something thread based. It was a couple of search and replaces. So it’s not so bad if actors fail you for whatever reason."
"I ran into the same thing in Kestrel, the queueing system. I started off with an actor for every single queue. I found that the work is so fine grained there that it was actually better at that tiny level to just use Java locks. Actors work great for having client connections, where there’s a bit of work overhead to what the actor is doing, and the code for handling client requests is very simple and straightforward."
"One of the things that I’ve found throughout my career is the need to have long-lived processes. And Ruby, like many scripting languages, has trouble being an environment for long lived processes. But the JVM is very good at that, because it’s been optimized for that over the last ten years. So Scala provides a basis for writing long-lived servers, and that’s primarily what we use it for at Twitter right now."
"Also, Ruby doesn’t really have good thread support yet. It’s getting better, but when we were writing these servers, green threads were the only thing available. Green threads don't use the actual operating system’s kernel threads. They sort of emulate threads by periodically stopping what they are doing and checking whether another “thread” wants to run. So Ruby is emulating threads within a single core or a processor. We wanted to run on multi-core servers that don’t have an infinite amount of memory. And if you don’t have good threading support, you really need multiple processes. And because Ruby’s garbage collector is not quite as good as Java’s, each process uses up a lot of memory. We can’t really run very many Ruby daemon processes on a single machine without consuming large amounts of memory. Whereas with running things on the JVM we can run many threads in the same heap, and let that one process take all the machine’s memory for its playground."
Scala - это actor-based language, но в ряде случаев разработчики предпоситают старые добрые блокировки Java.
"But for other parts we’ve just gone back to a traditional Java threading model. The engineer working on that, John Kalucki, just found it was a little bit easier to test, a bit more predictable. The nice thing was, it took minutes to switch code that was actor based over to something thread based. It was a couple of search and replaces. So it’s not so bad if actors fail you for whatever reason."
"I ran into the same thing in Kestrel, the queueing system. I started off with an actor for every single queue. I found that the work is so fine grained there that it was actually better at that tiny level to just use Java locks. Actors work great for having client connections, where there’s a bit of work overhead to what the actor is doing, and the code for handling client requests is very simple and straightforward."
Подписаться на:
Сообщения (Atom)