.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Go vs node.js: Uber case

В продолжение темы Go vs {your_favorite_language} предлагаю обсудить переход с node.js на Go в Uber — eng.uber.com/go-geofence .

Основные моменты:

* High developer productivity. Go typically takes just a few days for a C++, Java or Node.js developer to learn, and the code is easy to maintain. (Thanks to static typing, no more guessing and unpleasant surprises).

* High performance in throughput and latency.

* Super reliable. This service has had 99.99% uptime since inception.

LinkedIn

Лучшие комментарии пропустить

Я, таки, открыл оригинальную статью на сайте Uber и вчитался в детали. Оказывается сервис, который у них работал сначала на Node.js, а потом на Go, занимался решением задачи Point in polygon (принадлежность точки многоугольнику). Это хорошо изученная задача с несколькими вариантами решения и готовыми реализациями. Самое главное, задача эта чисто математическая и требует большого количества вычислений с числами с плавающей запятой. Ясно, что любой компилирумый статически типизируемый язык справится с ней быстрее, чем скриптовый. Тут не нужны массивы произвольной длины с произвольными типами элементов, тут нужен new double[N];
Конечно, помимо определения принадлежности точки многоугольнику сервис должен разбирать запрос, загружать географические данные из базы и формировать ответ. Но в любом случае, Node.js — это плохой выбор для решения математической задачи.

Жалко, что никто не напишет статью «Как мы запилили самый крупный интернет магазин в мире без использования базвордов и хипстерских фреймворков, меняющихся каждый месяц»

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

Є така штука, як «систематична помилка тих, хто вижив». Це коли увага звертається лише на одну сторону проблеми, повністю ігноруючі всі інші. Типу, ми чуємо історії лише тих, кого дельфіни винесли на берег, бо всіх інших вони тягнули в море.
Ви кажете, що одна компанія перейшла на го. Але що робить з десятками тисяч інших, які не перейшли?

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Есть вопрос по синтаксису Go. Как писать инициализацию полей по имени в анонимных структурах? Допустим есть: type A struct {field int}; type B struct {A}; var b = B{field: 5} вот инициализация b почему-то не катит, хотя можно писать b.field = 5.

и чем этот трэш отличается от scalaz?:)

Очевидно же! Ибо это не го!

При чем тут scalaz? В Scala это будет типа
case class A(field: int); case class B(a: A) val b = B(A(1))
Практически один в один

При чем тут scalaz?
при том что генерирует столь же мутную хрень как и :
var b = B{A: A{field: 5}}
а вот это:
case class A(field: int); case class B(a: A) val b = B(A(1))
читается гораздо проще

Scalaz это же попытка сделать из скалы хаскель. Там код будет выглядеть где-то так
 (some(3) |@| some(4)) { _ * _ }

т.е. эквивалентно по кошмарности

B{A: A{field: 5}}
что и требовалось доказать))

А в С++ можно написать
 cout << "Hello " << mystr << ".\n";
ужас ужас непонятно ниче.
Ваш рендомный пример скалаз кода не имеет никакого отношения к вопросу.

нашел еще одну победу го, заказ на апворк вроде как для реализации бизнес логики
www.upwork.com/...obs/_~01146bec7818952f90

Я апворк на факт наличия Го-заказов мониторю последние месяца 4 (просто ради любопытства + отслеживание трендов). Появляются периодически, к слову. Для достаточно разных задач.

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

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

я не гофер — без понятия, оно мне не интересно, просто попалось случайно

Всем гоферам и ихним хейтерам посвящается:

www.youtube.com/watch?v=IJlqVKNx3qQ — «Зачем придумали Go и что нам с этим делать»

Тем временем Google Alpha Go обыграл южнокорейского чемпиона по Го. У кого-то еще есть сомнения в том, что за Go будущее?

www.zdnet.com/...ion-in-landmark-ai-match

Google Alpha Go
оно на Go написано? или не? просто интересно)

просто а вдруг оно написано, к примеру, на скале?))) ну типа помните ж недавний срач Go vs. Scala?)

Какая разница, на чем AI написан

Вот именно, какая разница? Го стронг!

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

Поддерживаю, хотя и сам пишу на Go.

да он просто поехавший, пусть жжот мне уже давно просто нравиться смотреть

BTW www.amazon.com/...l-Computing/dp/0134190440 внезапно один бородатый хипстер по имени Brian Kernighan (ну Вы поняли©) даже книжку написал про Go... купить что ли на полку к «The C Programming Language» :)

Там еще есть:
— любитель ярких пиджаков Rob Pike
— бородач Ken Thompson
— оптимизатор Java HotSpot и V8 javascript engine Robert Griesemer

Я смотрю на технологии как «Происхождени видов» Чарльза Дарвина. Они все появлялись и пропадали, цикл ускоряется с каждым годом, технологии играют свою роль, когда появляются более успешные — они заменяют старые. Вот и все. Призыв оценивать технологии прежде чем их использовать не работает потому что 1) Нормально оценить можно только после того, как ты что-то стоящее сделаешь. 2) Если ты не сделаешь что-то быстро сейчас тебя обойдут конкуренты, поэтому люди идут на риск используя новые технологии.

nickcraver.com/...rchitecture-2016-edition
вот пример нормального проектирование системы, ниче не переписывают

Переписывали, и много — на RSDN есть обсуждение. Ввели по сравнению с голым сервером и SQL сзади кучу промежуточных слоёв — кэшей и тому подобного. Меняли слой доступа к БД (вводили dapper, убирали dapper...)

Я, таки, открыл оригинальную статью на сайте Uber и вчитался в детали. Оказывается сервис, который у них работал сначала на Node.js, а потом на Go, занимался решением задачи Point in polygon (принадлежность точки многоугольнику). Это хорошо изученная задача с несколькими вариантами решения и готовыми реализациями. Самое главное, задача эта чисто математическая и требует большого количества вычислений с числами с плавающей запятой. Ясно, что любой компилирумый статически типизируемый язык справится с ней быстрее, чем скриптовый. Тут не нужны массивы произвольной длины с произвольными типами элементов, тут нужен new double[N];
Конечно, помимо определения принадлежности точки многоугольнику сервис должен разбирать запрос, загружать географические данные из базы и формировать ответ. Но в любом случае, Node.js — это плохой выбор для решения математической задачи.

в любом случае, Node.js — это плохой выбор для решения математической задачи

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

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

Отличный доклад по поводу всяких новомодных языков\технологий www.youtube.com/watch?v=3wyd6J3yjcs

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

Мне одному кажется, что адепты Go слегка сумасшедшие? Не сильно в плохом смысле.

Микроавтобус vs Mers Vito.

Є така штука, як «систематична помилка тих, хто вижив». Це коли увага звертається лише на одну сторону проблеми, повністю ігноруючі всі інші. Типу, ми чуємо історії лише тих, кого дельфіни винесли на берег, бо всіх інших вони тягнули в море.
Ви кажете, що одна компанія перейшла на го. Але що робить з десятками тисяч інших, які не перейшли?

Ви кажете, що одна компанія перейшла на го. Але що робить з десятками тисяч інших, які не перейшли?

Немного подождать — и большинство компаний, связанных с highload’ом, перейдут на Go. Топовые компании уже перешли или активно переходят — google, facebook, yandex, cloudflare, dropbox, uber, booking. За ними начинают подтягиваться компании помельче. Вот тут неполный список компаний, использующих Go — github.com/golang/go/wiki/GoUsers . С пруфлинками.

Немного подождать — и большинство компаний, связанных с highload’ом, перейдут на Go.
а если они внезапно перейдут на что-то другое?)))

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

Вот на днях выложили еще один: github.com/IBM-Swift/Kitura
Это будет как с JSON парсерами. Но конкуренция, как известно, есть хорошо.

Немного подождать
Если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага. :)
Топовые компании уже перешли или активно переходят

Ага, особенно «пруф» букинга понравился, по которому Go упоминается один раз в предложении «For instance, its client-side code is JavaScript and it has some memory-intensive code written in Go or in C» :)

Це поки що лише ваші мрії.
Навіть маловідомі мови типу хаскеля або кложури можуть похвалитись саксесс сторіями переходу та списками компаній clojure.org/community/companies wiki.haskell.org/Haskell_in_industry
Але це не значить, що скобочки та монади скоро захоплять світ. Як би мені того не хотілось.

Жалко, что никто не напишет статью «Как мы запилили самый крупный интернет магазин в мире без использования базвордов и хипстерских фреймворков, меняющихся каждый месяц»

или вот
highscalability.com/...building-and-scaling.html
длинный список технологий, но go там нет, впрочем как и node.js

Угу, и что-то я там не вижу

В 20XX году вышла новая технологая A и мы переписали весь сервис на нее, потому что офигенно, простой язык, асинхронный, может держать миллион одновременных подключений. А в 20XY вышла технология B, и мы опять переписали сервис, потому что офигенно, простой язык, асинхронный, может держать миллион одновременных подключений.

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

В 20XX году вышла новая технологая A и мы переписали весь сервис на нее, потому что офигенно, простой язык, асинхронный, может держать миллион одновременных подключений.

Слово «асинхронный» здесь лишнее. В Go нафиг не нужна асинхронность, т.к. проще написать многопоточный синхронный код вместо запутанного асинхронного с кучей калбэков, event loop’ов и state machines. Тем более, что потоки в гоу почти бесплатные — хоть миллион создай — тормозить не будут.

мы уже видели как они тормозить не будут, сливают синхронному C# в десятки раз, асинхронному — в несколько раз.

Забавно, что кому-то нужен пруф такого, казалось бы, фундаментального факта
github.com/atemerev/skynet

Странно, из этой ссылки не видно преимущества в десятки раз, скорость выполнения сравнимая весьма.

Результаты бенчмарка оформлены немножко по дибильному.
Нужно скачать и запустить у себя.

На моем компе:

Go: 916ms

.NET:
Sync sec: 52ms
Async sec: 414ms
TPL sec: 170ms

на рахунок «callback hell», на скільки мені відомо, є проміси та генератори.

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

Ну и что? В дотнете есть тред пул с тасками такими же простыми в java — strams api, которые в разы быстрее твоих гороутинов согласно бенчмарка в соседнем треде и эти языки не теснят js, это конкурентное примущество никак не в нише js.

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

Все фанаты многопотчности учатся писать высокоэффективный wait-free код, а вы предлагаете на 4х ядрах устроить постоянный контекст свитч между 1к процессов с постоянными кеш мисами и блокировками?

Корутини (і горутини як частковий випадок) на то й називаються lightweight, що менеджаться без особливих затрат часу/памяті. Це не треди системи.
Якщо якась блочиться, чекаючи наприклад на результат на каналі, то просто виключається з загального циклу, поки в канал хтось не напише. Це коштує копійки :-)

«без особых затрат времени» — это в 17 раз медленнее?

Та ні, звідки ви взяли?

на бенчмарке гоу слил синхронному C# в 17 с лишним раз

dou.ua/...orums/topic/16606/#874800

В бенчмарку міряється, скільки коштує конкурентність в мовах. __синхронний__ сі тут ніяким боком не стоїть.
Я теж можу на тредах запилять такий бенчмарк, а потім казать, що однопоточність рулить, дивіться скільки багатопоточний варіант жере пам’яті та взагалі повільний.
Го повільніший за таскпул, бо останній лише емулює конкурентність, а го витрачає час на створення повноцінного контексту для горутини.
І повільніший за tpl, бо він тут ніяким боком не стоїть. Конкурентність — це не паралелізм.

TPL использует Thread pool по умолчанию для выполнения всех задач в отдельном Worker. О какой эмуляции в данном случае речь и чем «полноценный» Goroutine контекст отличается от контекста отдельного воркера в .NET?

Корутина — це такий собі нанотред з власним стеком, якій скед’юлиться рантаймом.
Тред пул — це по суті купа потоків, що по черзі виконують функції. Підходить лише для коротких операцій без локів на іо та інші таски. Якщо явно анотувать місця з локами, наприклад з використанням yield (як в жс( вийде примітивний аналог конкурентної мови.

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

Это почему-то у всех гоубоев так — не могут отличить кода Scala от Java но упорно утверждают, что код на Go лаконичней, не знают что в .NET IO неблокирующий но при этом утверждают, что из-за этого Goрутины лучше тред пула.

Я не кажу, що код на го лаконічніше.
Але гошний рантайм об*єктивно кращій за тред-пул, бо тред-пул навіть з асінками є частинним випадком тої штуки, на що здатен рантайм. Як в плані можливостей, так і лаконічності коду.

Если ты не видишь тред пула, это еще не значит что его нет.;)

В тому то й сіль, що там від всієї внутрішньої кухні з евентлупом та тредпулами абсолютна абстракція.

В бенчмарку міряється, скільки коштує конкурентність в мовах. __синхронний__ сі тут ніяким боком не стоїть.
Ну вообще-то, если мы говорим, что мы запилили очень эффективную дешевую конкурентность, то логично сравнить ее с кодом, в котором нет конкурентности, чтоб показать, насколько оно на самом деле эфективно. И результаты показывают, что оно, нифига не эфективно, и, если у нас есть CPU-intensive задача, где надо перемолоть много данных, то запускать миллион корутинов тупо, эфективнее разбить эти данные на несколько кусков, перемолоть их на разных ядрах и потом собрать все в месте.

Где это могло бы пригодиться, это в классической задаче с про миллион одновременных подключений, где нет борьбы за CPU и есть ожидание результатов IO. Запустить миллион классических потоков не получится и C# отсосет, но достаточно просто включить мозг и написать тот же код с TPL и async/await.
И, как показывают результаты бенчмарка, тут гоу опять отсасывает у C#.

Да не можна бенчмаркать конкурентність для випадку, коли вона відсутня в принципі.
Суть її — мать можливість спавнить 100500 нанотредів, які працюють квазіодночасно. Все. Чим займаються треди — висять на іовейтах чи матриці множать, пофіг, головне щоб вони один одному не заважали.

и async/await
О боже, два рази на хелловорлд бенчмарку! Відсос так відсос!

Напишите требования для нормального правильного бенчмарка и покажите код на гоу. Если будет время, я напишу то же самое на C#.

Не ломайте идеалы го программистов, будьте снисходительнее

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

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

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

Ну вот зачем так извращаться когда можно тупо в цикле на 4-ех потоках (по количеству ядер) все перемножить и это будет намного быстрее? TPL в .net эффективно это делает.

Это все-равно, что сказать: «А на мою машину можно поставить 5-ое колесо, а на твою нельзя, твоя машина отстой».

Це було до того, що тредпул (виправте якщо я помиляюсь) не вміє в preemprive scheduling, і там треба пам’ятать про цю специфіку. Горутина може бути взагалі не в курсі, працює паралельно з тисячою інших, або всього навсього одна.

Тредпул це самий примітивний механізм, тупо щоб по-швидкому асинхронно запустити просту, обчислювальну операцію.

В .NET є продвинутіші механізми, як та ж Task Parallel Library, яка має інтеграцію з LINQ, яка, грубо говорячи, приймає на вхід данні і молотить їх з допомогою переданої функції з максимальним використанням всіх ядер процессора, і повір мені, робить воно це ефективніше ніж універсальний планувальник го-рутин який симулює «квазіпаралелізм». Так що в плані «множення матриць» чи інших цифро-молотилок, не думаю що го буде мати перевагу, по крайній мірі не за рахунок го-рутин.

На рахунок IO операцій тоже не все очевидно, так як в .NET юзає IO Completion Ports.

Так що не факт що го-рутини ефективніші. Легше їх розуміти і простіше використовувати — в багатьох випадках так. Хоча у .NET є така штука як async/await яка все спрощує.

TPL — рішення для паралельних тасок, а як щодо конкурентних?
Адже поряд з множенням матриць може ще крутитись купа горутин, що виконують іншу логіку.

Нормально все. Щось порахувати — TPL, якась дрібниця — тредпул або таск з async/await, ломишся в базу чи в інтернет — неблокуючий виклик типу:

var customers = await dbcontext.Customers.Select(c => c.Name).ToArrayAsync();

foreach (var name in customers)
{
   Console.WriteLine(customer);
}

І поміть, ніяких свістоплясок з каналами.

Прикол конкурентних мов, що ви забуваєте про осі ці асінки-евейти та пули. Все хендлиться рантаймом, а ви пишете лінійний код, наче це лише один процес в системі. Типу

users = queryToDb() //lock
processedUsers = processWithIoWait(users) //shit, another lock
anotherThing = fetchSomeShitFromMQ() //oh shi

Я все починил

users = await queryToDb() //lock
processedUsers = processWithIoWait(users) //shit, another lock
anotherThing = await fetchSomeShitFromMQ() //oh shi

Нащо ви їх пишете? У вас рантайм настільки тупий, що залочиться на іо-виклиці?

Между прочем async await дает лучшее понимание что происходит

Вони існують лише як костилі для рантайму, що оперує тредами. Щоб знать, що треба передать керування і куди повернуть. Це елегантні, непогані, але все ж костиліки.
Для мов на корутинах вам пофіг. Пишите лінійний синхронний код, а система вже сама організує event loop.

Для мов на корутинах вам пофіг. Пишите лінійний синхронний код, а система вже сама організує event loop.
Это офигенно, но увы, работает медленнее, чем “костыльные” языки.

По-перше, всього-навсього в два рази.
По-друге, як я вже писав, го витрачає час на створення контексту нанотреду. Корутини не заточені чисто на маленькі таски. Їх там може роками крутитись тисяча штук, обмінюючись повідомленнями та слухаючи мережу. Користуючи щось типу моделі акторів, наприклад.

То есть разница в 2 раза, это не ощутимо?

Там основну роль відіграє по суті час запуску / завершення горутини. Він і без того достатньо малий. Різниця буде проявлятись, якщо у вас буде задача, що потребує люто спавнить-вбивать стоп’ятсот горутин за секунду. Але такого на практиці й близько не буває.

для новой и революционной технологии нет)

Корутини не заточені чисто на маленькі таски. Їх там може роками крутитись тисяча штук, обмінюючись повідомленнями та слухаючи мережу. Користуючи щось типу моделі акторів, наприклад.

В реализациях Акторов есть такая штука как распределенность и отказойстойчивость. Как Goroutines “заточенные на масштабные задачи которые крутяться годами” в одном процессе решает соотвествующие проблемы?

В го просто реалізується дерево супервайзорів, щоб ловить еррори / паніки горутин та перезапускать їх. Самі корутини тупо висять на каналі/кількох каналах, приймають-надсилают повідомлення та роблять щось собі.
Розподіленості як в акка нема, бо актори тут пишуться лише в якості «паттерну», і лише де треба (чувак про акку може взагалі не в курсі). Сама архітектура взаємодії побудована на більш фундаментальному CSP.

Нічого воно райнтайму не указує, просто будує ланцюжок ассинхронних операцій які мають виконуватися одна за одною. Для рантайма все просто — виконав одну, поставив на поток наступну. Що може бути простіше?

З іншої сторони є рантайм який менеджить тисячі, навіть мілліони (якщо я не помиляюся), горутин, рантайм, який має слідкувати яка горутина повисла на IO операції, рантайм, який має симулювати «квазіпараллелізм».

Цікаво, що ефективніше? Звісно якщо купа операцій має виконуватися параллельно, рантайм .net-а це організує через переключення контексту, але там це не в таких масштабах як в го.

Перевага горутин в тому, що вони позволяють писати простий лінійний код. Але це перевага перед джавою, а не C#-пом з його async/await.

Ну, у го є концептуальна перевага, що він взагалі абстрагує від системних тредів та локів. Ну і там скед’юлер розумніший, може сам перекинуть керування, навіть якщо рутина не повисла на лоці. Наприклад, якщо вона перемножала матриці.
Однак я й не сперечаюсь, що на сішарпі можна легко писать асинхронщину :-)

У вас рантайм настільки тупий, що залочиться на іо-виклиці?
таки да

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

ось так?

var users = await queryToDbAsync();
var processedUsers = await processWithIoWaitAsync(users);
var anotherThing = await fetchSomeShitFromMQAsync();

Тред пул для коротких операций коих большинство — решение более удачное чем goroutine с такой архитектурой и быстрее в разны. В Long running операциях просто создаеться поток для них вне тред пула и считать выгоду в милиссекундах на «часовых операциях» от создания легковестного потока и отсуствия context switching вообще звучит как полная ересь. Такое впечатление, что гоубоям дали инструмент что-то среднее между тем тем и тем, написали что у нас есть то то и то по сравнению с платформами, что юзают потоки где этого нету, а толком выгоду от этого всего на продакшин задачах обьяснить не сумели.

У вас є сервак, куди ломляться тисяча користувачів за секунду. Будете кожного з них в тредпул посилать, щоб залокався на першому ж зверненні в базу? Будете створювать по повноцінному треду на кожного — воно ж загнеться нафіг :-)
Якщо ж користувать корутини — так, працюватимуть лише чотири ядра. Але якщо одна з горутин зависне очікуючи відповідь бд, її місце моментально займе інша, і так далі. Процесор тут ніколи не буде простоювать.

Будете кожного з них в тредпул посилать, щоб залокався на першому ж зверненні в базу?
:faсepalm:
слышали когда-то о неблокирующем I\O?

Це там де вермішель з колбеків? :-)

student = await (context.Students.Where(s => s.StudentID == 1).FirstOrDefaultAsync<Student>());

І що? Де тут неблокуюче іо?

Это и есть код, который в конечном счете выполняет SQL запрос на БД и получает результат в неблокирующем режиме.

Подброшу немного дров в эту тему. Тредпул представляет собой совокупность ОС-потоков, в которых стоит ожидание события на порту завершения, когда событие возникает, его ловит первый попавшийся свободный поток, и дальше выполняет код обработки этого события. Событий может быть немного: чтение, запись, открытие, закрытие. Количество этих потоков создаётся пропорционально количеству ядер процессора(ов).

Программа на Go и так сама по себе может рассматриваться как этот тредпул. Весь вопрос в том, как происходит синхронизация данных, и где синхронизация между потоками будет эффективнее, там будет выше производительность. Самая эффективная синхронизация — это та, где её вообще нет по причине отсутсвия данных с обшим доступом :) Синхронизация делается обычно через критические секции, или через mutex, что одно и то же по сути. В идеале доступ к общим данным должен быть через атомарные операции, практически лочить приходится большие блоки кода. Потому что если лочить множество мелких кусков кода, то значительно вырастают шансы на deadlock, которые в дебагере не отловить, и повышается стоимость разработки именно ЭФФЕКТИВНОГО кода. В Go синхронизация между потоками ОС спрятана под ковром компилятора, и именно этот дизайн многопоточности может упростить жизнь.

Кажу ще раз, почитайте що таке IO Completion Ports: msdn.microsoft.com/...op/aa365198(v=vs.85).aspx

Костилі, що уродують код. Нормальна асинхронність з’явиться в сьомій версії. І то там чомусь треба маркувать асинхронні функції.

Читайте книгу Алена Карра «Лёгкий способ бросить писать книги».

еще один пример того что люди не в состоянии сделать техническую оценку проекта, и понять какую технологию юзать

Вы хотите сказать, что они ошиблись, выбрав Go вместо node.js?
Пора менять слово Developer на Architect в вашем профиле.

если люди вначале выбирают ноду, а потом го — то они явно чето недогоняют, при чем на уровне архитектуры.

я не говорю что го не подходит, более того, я не говорю что нода им не подходит.

но, очевидно только одно, они явно провтыкали в архитектурном плане.
ибо node.js и go не могут рассматриватся как альтернативы, ввиду того что они кардинально разные

кстати в оригинальном холиваре scala vs go, таже проблема была описана, люди спустя какое-то время выкупили что они юзают скалу не всегда там где надо, в виду чего и возникли траблы

node.js и go не могут рассматриватся как альтернативы
У них даже сейчас есть и нода и го вместе. У них сотни микросервисов, на всевозможных языках. Так что все может работать и вместе.

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

просто там было описание конкретного микросервиса

а возможно даже человек вообще без опыта работы с Go, зато уже может сравнивать его с другими технологиями :)

Я тут немного влезу. Могу сказать что может и ошибка. Был на докладе Uber. У них вообще очень богатая история смены технологий. За время существования они поменяли не одну базу данных/язык/фреймворк причем часто весьма неудачно. Вообще у них весма большой бардак в техническом плане, они сами это не отрицают.

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

Почему наконец-то? Они и так использовали и используют NodeJS, Python, Go, Java. Речь просто об одном микросервисе, который определяет тебя в рамках города (судя из статьи). Это не значит, что они все будут переносить на Go. Думаю, что в компаниях таких масштабов уже нельзя поменять технологию X на технологию Y.
Причем, насколько я понял, они еще и поменяли алгоритм определения вместе с переездом этого сервиса на Go.

Это не значит, что они все будут переносить на Go

Сомневаюсь. Зачем тогда им набирать go-программистов?

While historically Uber has been mostly a Node.js and Python shop, the Go language is becoming the language of choice for building many of Uber Engineering’s new services. There is a lot of momentum behind Go at Uber, so if you’re passionate about Go as an expert or a beginner, we are hiring Go developers

Тут я уже не скажу зачем они их набирают. В конце концов они и сейчас его используют. Вообще у них тех спецов около 2к, я не знаю сколько там разработчиков на Go или другом языке. Просто я себе не представляю такую массовую миграцию на новую технологию. Хотя бы представить сколько на это уйдет времени и денег. Какие-то узлы, которые сейчас не справляются, конечно можно переписать.

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