👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Scala выпиливается усиленными темпами из всех продакшнов. Это мертвый язык, на который не стоит тратить ни секунды времени.

— Знаете, почему у LinkedIn много лет такой тормозной, глючный и неудобный сайт? Потому что они надолго увязли в Scala и до сих пор не могут оправиться — www.quora.com/...-Scala/answer/Kevin-Scott
— Twitter отказывается от Scala — www.quora.com/...tter-getting-rid-of-Scala
— movio.co/...blog/migrate-Scala-to-Go
— jimplush.com/...eam-from-scala-to-golang
— uberblo.gs/...nd-why-it-beats-scala/jvm

Привет Саша. Ты предлагаешь использовать гоу? А на сколько он зрелый в плане фрейворков различных под веб? В проде не страшно ранить?

А на сколько он зрелый в плане фрейворков различных под веб?
Фреймворков под веб на go полно, но я с ними не работал — пока было достаточно стандартной библиотеки. Думаю, среди них найдутся несколько достойных.
Для шаблонов рекомендую использовать quicktemplate — аналог mako templates в python.
В проде не страшно ранить?
Страшно, но оно работает :) Причем перед сервисами на go нет никаких nginx’ов с apache’ами и haproxy — сервисы обрабатывают http и https запросы напрямую из интернета. Сейчас через них проходит 2 миллиона запросов в секунду от 8 миллионов одновременных подключений. Пока серьезных проблем не возникало.

опять сезонное обострение
причем сразу в трех топиках))

Готовлюсь к выходу go 1.8 — github.com/...wiki/Go-1.8-Release-Party . Там много новых фишек. Правда, до сих пор нет generic’ов, монад, pattern matching’а, type traits, implicit’ов, inheritance и exception’ов. Наверное, добавят в следующей версии.
Ждем адептов scala на нашем шабаше 25 февраля в Одессе vmes.vertamedia.com .

Правда, до сих пор нет generic’ов, монад, pattern matching’а, type traits, implicit’ов, inheritance и exception’ов.
то есть до сих пор нет того, без чего современный язык — просто паскаль со скобочками?))
единственное до сих пор +/- ide это плагин для idea, который мягко говоря сыроват еще))
зы. ради интереса полгода назад переписал самую нагруженную часть рабочего оптимизационного алгоритма на го — разница вышла не в его пользу в сравнении с шарпом причем почти в 2 раза
а объем кода стал в 1,5 раза больше
не, я ж не гофер, поэтому возможно допустил какие-то неоптимальные решения
но т.к. нормального профайлера нет и пока не предвидится — то и использовать его в проде стремно
то есть до сих пор нет того, без чего современный язык — просто паскаль со скобочками?

github с вами не согласен насчет того, какой язык современнее:
— Scala — 60 популярных репозиториев
— Go — 378 популярных репозиториев

И с каждым днем разрыв между Go и Scala растет семимильными шагами — достаточно проверить эти ссылки через пару месяцев.

но т.к. нормального профайлера нет и пока не предвидится — то и использовать его в проде стремно
Что вы имеете ввиду под «нормальным профайлером»?

Профилировщик в go встроен в runtime и может собирать профили в любой момент прямо в продакшн, никак не влияя на производительность программы. Профилирование по CPU, памяти и блокировкам поддерживается из коробки — https://blog.golang.org/profiling-go-programs .

между Go и Scala
скала тут причем
я вообще про шарп писал для сравнения
Что вы имеете ввиду под «нормальным профайлером»?
нормальный профайлер в первую очередь подразумевает наличие некой качественной ide

а) таковой нет
б) удобство просмотра результатов и сравнение результатов несольких сессий (только не надо мне говорить щито это делается парочкой грепов по текстовым файлам)
в) очень прикольно, когда срабатывает принцип Гейзенберга — профалер требует модификации наблюдаемой сущности)))
по итогу — нишевый инструмент без намека на универсальность
за последние годы ничего не изменилось
особенно прикольно будет посмотреть на лица гоферов, когда гуглята закроют лавочку
а они это делают крайне часто, особенно в последнее время))

Понятно. Для вас нормальный профайлер — это тот что с красивым gui и рюшечками. Для нас — тот, что помогает эффективно выявлять узкие места в продакшн под реальной нагрузкой, не снижая производительность программы.

вообще-то нормальный профайлер делать и то и другое (собственно профайлинг и вменяемая визуализация)
вам же приходится обходиться в лучшем половиной возможностей
ну что ж — дело армянских комсомольцев живет и поныне))

Извините, но чесно говоря, вы уже подзадолбали. Евангелизм это явно не ваше.
Если до того времени как я увидел, ваши посты, у меня было желание посмотреть в сторону го, то сейчас этот язык вызывает только одно отвращение, благодаря вашим стараниям и хайпа в интернете.

— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается. В отличии от го, где экосистема еще только растет + да и не стоит умалчивать про проблемы с пакетными менеджерами.
— Замеры в интернете, который показывают пинг-понг между горутинами и особенно хайп вокруг gc, просто уже задолбал. Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы. А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью
— Ссылки которые вы скинули с quora, вы их вообще открывали ? Linkedin успешно держить нагрузку на scala, при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.

Вам не приходило в голову, что для каждой задачи свой инструмент. Да ограничений и привязка, только к одному языку, в эпоху микросервисов, это довольно узколобо.

Извините если слишком агресивно, но было бы здорово если бы пересмотрели свои взгляды на продвижение go на dou.
Варианты:
— создать топик «Новости Go»
— еженедельный или месячный дайджест про Go

Картиночки для вброса:
pbs.twimg.com/...C3M9ThVWAAAo3VV.jpg:large
pbs.twimg.com/...C3M9ThVXAAAV7jE.jpg:large

у меня уже несколько раз было ощущение, что этот хлопец на самом деле ненавидит го, потому и пропагандирует его так, что вызывает обратный эффект
может его заставляют?))

этот хлопец на самом деле ненавидит го, потому и пропагандирует его так
от любви до ненависти один шаг © =))
— Вам не казалось что мерят популярность языка, первая версия которого вышла в 2003 году, по количеству написаних библиотек, довольно тупо. Так как большинство уже давно написано, и развивается.
java, php, python и javascript появились раньше scala, но это не сказывается на росте количества популярных репозиториев на github.
Вам не кажется что те цифры что вы называете, в продакшене будут немного поумеренней, из-за наличия все таки полезной работы.
У нас в продакшне один физический сервер обрабатывает 200к http запросов в секунду от миллиона одновременных http keep-alive подключений в штатном режиме и достигает 300к запросов в секунду в пиках. Полезная работа — валидация входящих запросов, сбор и параллельная отправка статистики в несколько различных сервисов для последующей обработки/хранения.
А чудо-gc, вызывает только одну улыбку, да бы любой человек понимающий немного о gc, знаем что ничего не дается бесплатно, если есть перевес в сторону коротких задержек, значит будет ограничение в пропускной способностью
1. Короткие задержки намного важнее пропускной способности.
2. Лишние выделения памяти в go легко идентифицировать и устранить с помощью встроенного профилировщика.
3. Go нагружает gc намного меньше по сравнению с java за счет передачи параметров по значению, возможности встраивания значений друг в друга и хранению значений на стэке. Благодаря этому никто не замечает сниженную пропускную способность gc.
Linkedin успешно держить нагрузку на scala
Производительность — не самое важное в коммерческой разработке (хотя доже на этом поле go уделывает scala’у как ребенка). Намного важнее readability, extensibility и maintainability кода. Вот с этим у LinkedIn явные проблемы. Скорее всего, scala сыграла в этом не последнюю роль. Иначе зачем они решили не использовать scala для нового кода и перевести все проекты на scala в режим maintenance?
при этом один из инструментов kafka вообще уникальный среди всех существующий брокеров, и он написан на scala.
Что в kafka такого уникального?
Вам не приходило в голову, что для каждой задачи свой инструмент. Да ограничений и привязка, только к одному языку, в эпоху микросервисов, это довольно узколобо
Согласен, что для каждой задачи есть наиболее подходящий язык программирования. Даже scala годится для каких-нибудь теоретических матановых задач. Но использовать scala в продакшн — это мазохизм для программистов и самоубийство для компании.
У нас в продакшне один физический сервер обрабатывает 200к http запросов
От никогда не понимал людей которые пишут подобные высеры.
Что бл значит «физический сервер»? Пеньтиум3 с 256 МБ ОЗУ?
«обрабатывает 200к http запросов». Каких именно запросов? Статическая страничка? Инкремент счетчика? Расчет среднего возраста всех пользователей ФБ?
---
Вы бл инженер или маркетолог-самоучка?

Сервер 40-ядерный с 64Гб ОЗУ и 10Гбит сетью. Загрузка процессоров не превышает 50% в пиках. Потребление памяти — до 20Гб. Загрузка внешнего канала сети по каждому из серверов — до 2Гбит/с входящего трафа и менее 1Гбит/с исходящего.

Запросы — различные события, связанные с показом рекламы. По каждому событию собирается до 40 различных параметров. Собранные данные отправляются в различные сервисы для последующей обработки, хранения и использования.

на нашем шабаше 25 февраля в Одессе
хех) вот я подумал — может таки пойти... знать бы только бесплатный шабаш будет или не, и какие именно мастер-клавссы там будут.

Вход бесплатный. Это go 1.8 release party, так что планирую рассказывать только про новые фичи этой версии.

Чем больше вижу подобных блог постов, тем больше убеждаюсь, что в нынышем «высоком айти» много безмозглых кретинов (без относительно спора о конкретных фич языков).

Согласен — зачем выбирать вначале scala, если затем ее не можешь асилить?

Какая то фигня, по поводу того, что твиттер собирается отказаться от скала. С того же гитхаба: 40 репозиториев на скале против одгно на го. И то, по ощущению попробовали один проект 2-3 года назад, поняли, какое это ГОвно, и забросили.

Линкедин как юзал jvm стэк, так и будет в ближайшее время (5 и более лет) его юзать. А на ГО (вно ???) как то особо никто не собирается переходить.

Про ынтерпрайзы я вообще молчу, там никому даже в мыслях не приходит перейти с .net/jvm на го или еще на какую-либо экзотику.

А высказывания со всяких там квор и т.п. — с таким же успехом могли бы ссылаться на свои посты с доу.

Какая то фигня, по поводу того, что твиттер собирается отказаться от скала.
Твиттеру тяжело отказываться от scala, т.к. в этой компании работает половина всех практикующих scala-программистов в мире. Они сильно вляпались в scala. Но им придется пройти очищение, т.к. даже VP of Platform Engineering в Twitter, Raffi Krikorian, позволил себе сказать такое о своем печально известном решении перевести Twitter на Scala:
What I would have done differently four years ago is use Java and not used Scala as part of this rewrite
Линкедин как юзал jvm стэк, так и будет в ближайшее время (5 и более лет) его юзать.
jvm стэк это не только scala, от которой они отказываются в пользу plain old java.
Про ынтерпрайзы я вообще молчу, там никому даже в мыслях не приходит перейти с .net/jvm на го или еще на какую-либо экзотику.
Go, в отличие от scala, подходит для кровавого ынтырпрайза по некоторым критериям:

— низкий порог входа
— масштабируемость на команды из тысяч программистов

К сожалению, Go не подходит по главному критерию ынтырпрайза — возможность неограниченного распила бюджетов с помощью многоуровневого наследования абстрактных фабрик визиторов синглтонов и senior solution архитекторов/консультантов.

То же можно сказать и про Гугл, которая не откажется от Go по естественным причинам, также как и Майкрософт не откажется от виндовс (хотя половина её сотрудников мечтают перейти на линукс:)))

Go используется в чуть более, чем 9000 компаний. Так что, если в руководство Гугл просочится Go-хейтер и уволит всю команду разработчиков Go во главе с Пайком, Фицпатриком и Коксом, то их быстро приютят компании типа Cloudflare, и спокойно продолжат развитие Go.

Так ГО уже ж «развили» почти до конца — скоро в нем появяться generics и check/handle(try ... catch). чем не c++ теперь

check/handle уже есть — blog.golang.org/defer-panic-and-recover

Дженерики не нужны. В следующей версии го появятся намного более крутые вещи:

1. #20706 General Unicode identifiers based on Unicode TR31: This addresses an important issue for Go programmers using non-Western alphabets and should have little if any impact on anyone else. There are normalization questions which we need to answer and where community feedback will be important, but after that the implementation path is well understood. Note that identifier export rules will not be affected by this.

2. #19308, #28493 Binary integer literals and support for_ in number literals: These are relatively minor changes that seem hugely popular among many programmers. They may not quite reach the threshold of solving an „important issue” (hexadecimal numbers have worked well so far) but they bring Go up to par with most other languages in this respect and relieve a pain point for some programmers. They have minimal impact on others who don’t care about binary integer literals or number formatting, and the implementation is well understood.

3. #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.

Дженерики не нужны.

Да, я вот тоже так считаю, но Роб Пайк похоже не согласен с нами. И решил добавить в язык и generic и exception handling по аналогии с try catch
go.googlesource.com/...​master/design/go2draft.md
Вообщем ждем скорого падения популярности языка.

Надеюсь, Роб Пайк не даст превратить изящный Go во франкенштейна C++

handle/check существенно упростит обработку ошибок, если примут этот драфт
go.googlesource.com/...​rror-handling-overview.md
Можно будет избавиться от многочисленных проверок типа if err != nil { ... } с одинаковым кодом на случай ошибки, и при этом механизм обработки ошибок останется прежним. В общем, предложения очень толковые.

Драфт ухудшает читабельность кода. Появляется неявная передача err с неясным потоком исполнения. Уж лучше оставить явный, но немного многословный

if err != nil {...}

. Те, кто не любит его, могут эмулировать магию из этого драфта с помощью сомнительного кода:

func sum() (int, error) {
  // magic shit for `if err != nil { ... }` haters 
  defer func() {
      if err := recover(); err != nil {
          return 0, err
      }
  }()
  check := func(err error) {
    if err != nil {
        panic(err)
    }
  }

  // actual code
  x, err := foo()
  check(err)
  y, err := bar()
  check(err)
  return x+y, nil
}

Ничего не ухудшает, код вполне очевиден. К тому же вышеприведённый пример можно упростить по стандарту Go 2, что не выйдет с помощью этой «эмуляции»:

func sum() (s int, err error) {
// actual code
return check foo() + check bar(), nil
}

По количеству вакансий на hh.ru Golang — 361, Scala — 455. И там и там мало, но у go меньше. Так что пока не вижу смысла на go переходить.

Просто вакансии по Scala висят годами — никто больше не хочет вляпываться в этот матан. А вакансии по Go закрываются за полчаса, т.к. Go может выучить любой школьник за полдня.
Вот настоящий рейтинг Go vs Scala — Go в 10 раз популярнее, чем Scala.

У нас на Scala ивент система, все таки Актеры прекрасно для этого подходят (можно скейлить по нагрузке).

Еще есть небольшой проект для домашнего Hadoop мониторинга на Play с Scala.

С следующего спринта будем мучать Spark с Scala (интересный уровень абстракции они предоставляют, надо пробовать :) ) в дополнению к уже существующему Hadoop с Java.

Так же где то ниже писали что не могут найти людей под Play — лично знаю человека который полтора года сидит на плейном проекте в Киеве.

ИМХО любой функциональный язык хорош для души программиста. Советую попробовать функциональную парадигму, не понравится, можно вернутся в итеративное программирование :)

Из реальных больших проектов что знаю: у Netflix весь видео стрим на скале; у twitter, foursquare и coursera — бекенд.

Язык развивается Typesafe фигачит и Akka фигачит :)

блин только заметил что это пост из 2012го. Кто ж его апнул 0_о

месяца полтора на качественный самостоятельный въезд в тему
для качественного самостоятельного везда года 1,5 потребуется

Интересно, в Днепре ктото занимается разработкой на скале?

А есть ли люди реально работавшие с Play? Мы начали искать программистов с реальным Scala опытом и похоже их на Украине почти нет :) А если еще в требования добавить Play так пока вообще 0 :) Я начинаю опасаться что рынок Скала программистов на Украине пока не сформировался. Надеюсь что это изменится.

Плей с полноценной поддержкой скалы вышел 4 месяца назад, до этого скала подключалась к плею костылем, поэтому ваша ситуация не удивительна

Не 0: у меня сейчас второй проект на play и предыдущий play — проект сейчас подхватился, уже наверное можно сказать, что нормально. Learning curve в play гораздо лучше чем lift, так что думаю можно просто искать тех кто работал с чем-то rails-подобным,

Людей пока мало, да.

а откуда дикая спешка?

ну так заказчика тоже нужно воспитывать. Такая спешка она везде будет.

А вы пробовали искать человека с джава опытом, но интересующегося скалой? Или вам только 10-лет опыта подавай ?

Так происходит, Вадим, из за некоторой косности украинских компаний. Надо чтоб по новейшему фреймворку который вышел вчера было 5 лет опыта, как минимум. А если человек ещё и сам осваивал язык, то увы — всё печально.

Надеюсь что возьмусь за скалу через пару лет вместе с прошариванием функционального программирования как такового.

То есть .. никогда :)

Понравился, закончил, ждемс нового курса от Одерски.

www.coursera.org/...course/reactive
Уже можно записаться. Начнется в ноябре

Записался уже давно :) в скайп конфе по скала курсу уже давно проанонсировали

В тему Scala:
18 сентября на Coursera стартует курс Functional Programming Principles in Scala.
www.coursera.org/course/progfun

Я б не отказался участвовать в Scala проекте

Если есть желание — постучись в скайп

А ктоб отказался ? (ну с учетом сохранения ЗП ;-) )

Использовали Scala в достаточно крупных Enterprise-Web-проектах (Lift + Squeryl). Были довольны возможностями языка и выбранными framework’ами. Желания возвращаться на Java (опыт Enterprise Java ~5 лет, Scala — 1,5 года) нет никакого. З.п. в конторе была не ниже рыночных у Java-девелоперов. Сейчас с товарищем запускаю стартап. Выбрал Scala + Lift. Play, имхо, сыроват.

P.S. речь о Москве.

Ну можно просто начать отдельные части присать на scala — оно будет с работать out-of-the box. Для веба поверх сервлетов можно scalatrа прикрутить

Пару строк в pom файле, и у тебя в проекте уже скала.

Смотря для чего. Чтобы повысить з.п. явно не стоит, лучше спринг, хибернейт, вебсервисы и тонкости настройки баз данных. Короче троублшутинг. Скорее наоборот, если в проекте будет скала тебе будут пытаться продать вакансию как опупенно интересную и захотят платить меньше рыночной з.п(интересно же)

Для расширения кругозора стоит однозначно

Кстати, в последнем опросе зарплат можно выбрать scala как технологию и посмотреть что там с зарплатами.

Посмотрел. Аж три анкеты получилось: у одного товарища 2500, у другого 3300, у третьего 3500. Не сказал бы, что много за знание явно фриковского языка

Я думаю, на текущий момент это все относится к ненавистной тобой теме об «интерестных технологиях». Если будут платить хотябы так же как за жабу — то будет уже не плохо.

Если будут платить хотябы так же как за жабу — то будет уже не плохо

Не плохо чем? Какая разница на чём писать?

Зачем тебе тратить время на изучение скалы, если за нее не будут платить больше?

Зачем предпринимателю платить больше за скалу ?

Зачем тебе тратить время на изучение скалы, если за нее не будут платить больше?

Для расширения кругозора, см. выше

Зачем предпринимателю платить больше за скалу ?

Инструмент хорошо подходит для решения определённых задач, людей знающих этот инструмент мало. Хочу профит от правильного применения инструмента -> ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.

Правда, как я уже говорил, пытаются компенсировать бОльшую сумму з.п. сказочками о интересных проектах.

Для расширения кругозора, см. выше

Расширять кругозор это одно, а нормально учить все тонкости яп — это другое.

Инструмент хорошо подходит для решения определённых задач, людей знающих этот инструмент мало. Хочу профит от правильного применения инструмента -> ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.

Каких задач ? примеры ?

Каких задач ? примеры ?

Наверно таких:

ищу людей его знающих -> людей мало -> плачу больше, чтоб найти.

Зачем предпринимателю платить больше за скалу ?

А он платит не за скалу, а за результат. Если со скалой результат будет лучше, то и платить надо больше.

Вот тут интересней всего, будет ли результат со скалой реально лучше? Хотя бы по простому критерию — скорость написания кода. затем устойчивость кода, расширяемость и удобство сопровождения.

ИМХО, нет (по скорости написания не категоричне нет).

Но есть люди которые считают что да. Видел успешное применение на небольших проектах в которых нет сверхактивного изменения бизнес-логики.

Опять же таки — примеры. Ибо, изходя из недостатков перечесленных мною же ниже — результат для нормальных проэктов будет хуже :-)

Ибо, изходя из недостатков перечесленных мною же ниже — результат для нормальных проэктов будет хуже

Ну я тебе уже намекал что большая часть твоих недостатков высосана из пальца.

А вот и нифига, за результат платят сдельщикам: сделай работу — получишь оговоренную сумму. В этом случае я уже партнёр и цена на мою работу возрастает многократно.

а как обстоят дела с Clojure?

У кложура статус «эзотерический». Он вообще нежилец.

у нас в Мюнхене пишут на нем, есть проекты. Так что от рынка зависит и области применения

Судя по всему, за два года ничего не поменялось )

Стоит. В реальных проектах применяется и довольно активно. Навскидку — scala проекты в Украине наблюдались в strikead, gradsoft, daxx, adstream, skelia, luxsoft, и, кажется, кусочком в global-е. Это только из тех кто светился. Детали можно спросить в google group scala-ua (и вобще community: scala-lang.org.ua, www.facebook.com/...56373621041781 )

сейчас основная активность в FB группе:www.facebook.com/...roups/scala.ua

С сайтом — его делал @folone сто лет назад, при этом используя сайт-генератор на haskell-е, как он уехал из Украины так сайт и перестал обновляться. Сесть и разобраться что там и переделать ни у кого руки не доходят (хотя раз вспомнили — может быстрее дойдут)

сто лет назад, при этом используя сайт-генератор на haskell-е, как он уехал из Украины так сайт и перестал обновляться.
Кстати, типичная судьба проектов на скале, хаскеле, и т.п.

Правильнее юзать плей, на лифт даже его создатель вроде как забил.

Думаю что смысла нет скрещивать бегемота с носорогом.

Это довольно таки другой стек. Например спринговые конфигурации ИМХО запросто покрываются implicit объявлениями. Для MVC — в скале свои фреймворки и т.п.

То есть я к тому что — не всегда стоит нести свои привычки в новое окружение.

Сыроват — есть немного. Тормознут — скорее наоборот.

Основная тема почему плей называют тормознутым это то что там шаблоны долго компилятся, но их можно поменять на груви шаблоны вроде.

Плей 2 наоборот задумывался как суперпроизводительный фреймворк, но особых подтверждений этому пока что не сильно видно на горизонте.

Скалу можно прекрассно юзать как better java для начала, выведение типов, лямбды, хорошо спроектированая библиотека колекций и некоторые другие батарейки сделают код намного чище.

То есть они могут алгоритм обработки данных построить в виде функций с функциональными конструкциями. Я честно сказать в аутсорсе мало видел таких ребят:) Есть конечно, но там где я работал их было мало. По своему опыту, мне доводилось видеть код написанный императивно, просто в виде алгоритма, некоего конечного автомата на джава, и код в функциональном стиле, написанный с помощью Google Guava.

Кстати подумалось что это все еще зависит от вида задачи, если задача связана с манипуляцией всякими коллекшнами, фильтрацией, агрегацией и т.д. коллекций, то да, функциональный подход рулит, если там какие то другие алгоритмы, или вообще бизнес логика для yet another crm/erp/ecomerce то выигрыш уже не так заметен, а то и превращается в проигрыш

Отзывы противоречивы. С одной стороны черезчур академично. С другой взят на вооружение некоторыми consultancy как competitive advantage. Вполне может и не взлететь как мейнстрим. Зубрить прямо сейчас может и не стоит, но если легко дается — покопаться не повредит. Поработать точно тоже.

AdStream постил здесь вакансии для какого то проекта на скала. Правда у них судя по всему там адский салат из bleeding edge технологий: mongodb, node.js, lift, scala опять же, я бы с опаской с таким салатом работать бы согласился.

Not that we needed all that for the trip, but once you get locked into a serious drug collection, the tendency is to push it as far as you can.

― Hunter S. Thompson, Fear and Loathing in Las Vegas: A Savage Journey to the Heart of the American Dream

я бы с опаской с таким салатом работать бы согласился.

а я бы — без.

Ну не все еще доросли до осознания ответственности за результат работы.

то есть один язык, один сервер приложений, одна БД — to rule them all — это и есть признак зрелости?

Проблема не в одном или двух языках, проблема в том что товарищи экстремалы взяли все самое сырое что есть на рынке.

mongodb сырое? scala & node.js тоже не очень новички и имеют сложившуюся репутацию.

По сравнению с mysql, posgres, ms sql server еще далеко не венец rock solid технологий. Тоже самое про скала, node.js(известен хоть один сакт на нем?) уж не говоря про лифт.

между rock solid и raw есть достаточно много еще этапов. Что есть сакт?

ох йо как то это черезчур неконсервативно. Чисто на резюме поработать — на месте владельца проекта мне бы было страшно

ну если люди знают что делают, то у них наверное будет большой competitive advantage. А если нет — то и более консервативный подход может не помочь.

угу, наверно. Я такие вещи пока готовить не умею от сюда и осторожность.

Ну вобще-то mongodb это по распостранению аналог mysql сегодня. То есть mongodb/Lift (сейчас ближе к mongodb/play) — это что-то вроде LAMP-а.

у вобще-то mongodb это по распостранению аналог mysql сегодня
Интересно откуда ты такое взял. www.indeed.com/...ysql,mongodb&l=

как всегда, у каждого такой свой мирок, который экстраполируют на всех остальных.

Мой хороший знакомый работает с этим языком, могу дать скайп в личку, если надо.

Хоть язык и интересный, но из того что писал Поллак, и другие умные дяди — скал а очень далека от реального использования.

Прикол даже не в сложности как таковой.
Вот вам короткий наброс почему я бы не выбрал скала для «нормального проэкту»:
-Несовместимость разных версий на уровне языка и компилятора.
-Несовместимость библиотек откомпилированных разными версиями языка.
-Поколения различных коллекций несовместимых друг с другом.
-Поддержка дслизации из коробки, когда есть варианты как синтаксически по разному написать один и тотже код.
-Интрисикты (или как там они прально называются).
-Мозговыносящая система типов.
-Комбинация из предедущих 4-х пунтков — читать уже написанный код местами тяжело. Очень тяжело читать быдлокод.
-Очень длинный и неровный лернинг курв.

Это ты всего в интернетах начитался, если бы попробовал, понял бы что вышеописанное проблемами не является

я то какраз пробывал. Для небольших прожектиков написанных самому, для себя — действительно это все во многом не проблема. При бОльших проэктах с командами, думаю, это все будет проблемою, если и не сразу то потом. Хотя норот вон нодежс пилит и в ус не дует.

реальных проектов — это типа встроенная поддержка xml в языке? использование streaming xml parser? xml bindings?

Я не понял ваш норкоманский вопрос.

-Несовместимость разных версий на уровне языка и компилятора.
-Несовместимость библиотек откомпилированных разными версиями языка.
Раньше не обращал внимания

-Поколения различных коллекций несовместимых друг с другом.
А вот это уже очень не смешно

-Поддержка дслизации из коробки, когда есть варианты как синтаксически по разному написать один и тотже код.
А пример можно?

-Интрисикты (или как там они прально называются).
<.blockquote>
?????
-Мозговыносящая система типов.
-Комбинация из предедущих 4-х пунтков — читать уже написанный код местами тяжело. Очень тяжело читать быдлокод.
-Очень длинный и неровный лернинг курв.
Ну как бы когда в коде куча +T -T <: => и регулярки ну наверняка не читабельно

Підписатись на коментарі