@devops_ru

Страница 1913 из 4568
Alexey
30.12.2016
12:59:52
а зачем вам гвидо?
потому что весь ранний код написан на Python и его тут не меньше чем кода нового

Nikolay
30.12.2016
12:59:55
Ее знает больше человек, проще найти разработчиков

here1am
30.12.2016
13:00:40
дак это ж не галера

Alexey
30.12.2016
13:00:59
А как же Java?
Яву я оставил в LinkedIn'е — пускай дальше ебутся со своими -XX-oh-dear-god-please-make-that-shit-work

Google
here1am
30.12.2016
13:01:45
с такими аргументами надо предлагать пхп и жс

Alexey
30.12.2016
13:01:50
Ее знает больше человек, проще найти разработчиков
хочешь ли ты тех разработчиков которыъ просто найти? я думаю на php найти разрабов ещё проще

а как ты оцениваешь время разработки на Go и Rust'е относительно времени разработки на питоне? насколько оно больше? (с учётом всего, всех тестов и прочего)
Хуй знает, я на расте не писал почти. Могу сказать что большие проекты на языке с компилятором писать сильно проще, так как тестов нужно меньше и рефакторить проще

Nikolay
30.12.2016
13:05:01
Яву я оставил в LinkedIn'е — пускай дальше ебутся со своими -XX-oh-dear-god-please-make-that-shit-work
Ну, только мозголомные switches - это слабый аргумент при выборе платформы

С теми же iptables живем

Alexander
30.12.2016
13:07:43
не является ли переход на Go просто погоней за модным трендом?

Nikolay
30.12.2016
13:07:49
хочешь ли ты тех разработчиков которыъ просто найти? я думаю на php найти разрабов ещё проще
Стоимость/время поиска специалиста на Rust выше, чем для Java (имхо)

Alexey
30.12.2016
13:08:09
Ну, только мозголомные switches - это слабый аргумент при выборе платформы
зависит. в любом языке с GC будет очень много так называемой "accidental complexity", где ты пишешь горы кода лишь бы GC был счастлив. У нас целая инфраструктура там была которая делала GC счистливым.

Google
Alexander
30.12.2016
13:09:14
не является ли переход на Go просто погоней за модным трендом?
ну если язык действительно хорош, пишется все быстро и нормально, и он отвечает поставленным задачам - то ответ нет )

Alexander
30.12.2016
13:09:50
просто я пишу на Python'е и я не понимаю, почему кто-то хочет перейти с него на Go) Python такой няшка

дело в скорости выполнения программы? или в чём-то ещё?

Alexey
30.12.2016
13:10:03
мне интересно вот это решение перехода с питона на го, насколько оно оправдано?
Go, для любой задачи в больше чем 1к строк лучше. Даже С++ с правильным набором либ (e.g. boost/proxygen/folly) сильно лучше Python. Это ровно как Python сильно лучше bash для скриптов больше 100 строк

Alexander
30.12.2016
13:10:40
просто я пишу на Python'е и я не понимаю, почему кто-то хочет перейти с него на Go) Python такой няшка
писал на всем кроме питона, и по моему ощущению - пишется быстрее, удобнее и правильнее

Старый
30.12.2016
13:11:34
про perl забыли

Nikolay
30.12.2016
13:11:44
как и для php, но это не повод писать на php
Применимо к любому нишевому языку как платформе: если стоимость разработчика для Rust (его поиск) сравнима с Java + устраняет ненужный код и работает быстрее, то выбор вполне ясен

Vladimir
30.12.2016
13:11:48
про perl забыли
на перле можно писать код только в двух случаях

если ты хочешь поиздеваться над окружающими

Alexey
30.12.2016
13:11:57
дело в скорости выполнения программы? или в чём-то ещё?
каждая строчка кода на питоне — это бомба которая взовётся при refactoring'е. И рефакторинг сделаешь не ты, а интерн из соседнего отдела, а разьебёт продакшн у тебя.

Vladimir
30.12.2016
13:11:59
и если у тебя легаси на нем

Старый
30.12.2016
13:12:10
на перле можно писать код только в двух случаях
у меня знакомый java кодер начинал с перла с триколоре

Vladimir
30.12.2016
13:12:31
у меня знакомый java кодер начинал с перла с триколоре
это никак не противоречит моим утверждениям выше

а на Go получится обеспечить такое же время разработки как и на Python'е?
наличие компилятора сильно помогает избежать странных вещей при отладке

Alexander
30.12.2016
13:13:08
а что Гвидо думает про Go?

Vladimir
30.12.2016
13:13:10
на проектах больше 1к строк я б сказал быстрее

Alexey
30.12.2016
13:13:16
а на Go получится обеспечить такое же время разработки как и на Python'е?
В долгосрочной перспективе скорость разработки на Go/C++ МНОГО выше скорости разработки на Python, как бы парадоксально это не звучало

Google
Vladimir
30.12.2016
13:13:27
правильно, пишите все на С
на Си в современном мире тоже не надо писать ничего кроме кода под ATmega

Vladimir
30.12.2016
13:13:53
драйвера на php и ruby
на плюсах или расте том же можно

Старый
30.12.2016
13:14:06
драйвера лучше на С и асме

Nikolay
30.12.2016
13:14:07
Vladimir
30.12.2016
13:14:12
драйвера на сях пишут потому что ядра ОС написаны на сях

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

Старый
30.12.2016
13:14:56
во времена создания линукс уже был с++

Vladimir
30.12.2016
13:15:05
стандарт плюсов - 1998 год

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

точнее плюсы были по своему развитию хуже чем сейчас раст

Vladimir
30.12.2016
13:17:41
@erzent фишка кстати еще в том, что если взять разумное подмножество плюсов, то даже на ATmega код будет компактнее, читаемее и идентичен по скорости

Alexey
30.12.2016
13:18:37
Vladimir
30.12.2016
13:18:57
во времена создания линукс уже был с++
поэтому в общем начиная проект с нуля сейчас объективно нет причин выбрать си вместо плюсов

Alexey
30.12.2016
13:19:02
но аннотировать миллионы строк кода на Питоне - то ещё веселье

Alexander
30.12.2016
13:19:44
Alexey
30.12.2016
13:20:29
но type-less это не единственная проблема Питона, есть ещё GIL, отсутствие async/await в 2.7, отсутствие packaging'а нормального итд итп

Sergey
30.12.2016
13:21:12
>отсутствие async/await в 2.7 ну а Гвидо вам зачем?

Google
Alexander
30.12.2016
13:21:14
ну, c 2.7 постепенно уйдут, сейчас уже 3.6 зарелизился на днях) отсутствие packaging'а вроде пофиксили через wheels

Alexey
30.12.2016
13:21:51
но Python с mypy сможет потягаться с Go же?
тоесть тебе нужно: 1) mypy чтобы безопасно 2) pypy чтобы быстро 3) 3.5+ чтобы асинхронно 4) хуй знает что чтобы без GIL 5) хуй знает что чтобы без GC

и вот мы опять возвращаемся к accidental complexity

лучше уже java

>отсутствие async/await в 2.7 ну а Гвидо вам зачем?
Гвидо ни для какой компании ни за какие деньги не сделает 2.8

Alexander
30.12.2016
13:24:03
да, мне вот 4 и 5 пункты интересны

Admin
ERROR: S client not available

Alexey
30.12.2016
13:25:05
ну и без GC можно жить - вон ребята из Wargaming его отключают. но можно и дрочить в пресядку, но может всётаки не стоит себя мучать?

here1am
30.12.2016
13:26:33
а, я не очень внимателен

Alexander
30.12.2016
13:27:01
Alexey
30.12.2016
13:28:05
Alexander
30.12.2016
13:28:19
4 пробела))

Vladimir
30.12.2016
13:28:25
они через новый интеловый Transaction Memory Extension хотят сделать вариант интерпрератора без GIL

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

Alexander
30.12.2016
13:29:00
https://www.python.org/dev/peps/pep-0008/#indentation же

Google
Alexander
30.12.2016
13:29:27
я не соблюдаю только правило про 79 символов в строке, всё остальное ок)

Vladimir
30.12.2016
13:29:31
http://doc.pypy.org/en/latest/stm.html

Alexey
30.12.2016
13:29:46
https://www.python.org/dev/peps/pep-0008/#indentation же
а может https://google.github.io/styleguide/pyguide.html ?

Vladimir
30.12.2016
13:29:50
@SaveTheRbtz а, у них аппаратного tsx пока не поддерживается, понятно почему медленее

Alexander
30.12.2016
13:30:22
а может https://google.github.io/styleguide/pyguide.html ?
ты уже троллил этим Гвидо? ?

Alexey
30.12.2016
13:30:44
@SaveTheRbtz а, у них аппаратного tsx пока не поддерживается, понятно почему медленее
да, там движуха идёт, но когда закончат хз нужно ли оно уже будет людям?

Alexander
30.12.2016
13:32:10
ты уже троллил этим Гвидо? ?
там тоже про 4 пробела, но вот символов в строке там разрешается иметь 80, а не 79

Alexey
30.12.2016
13:35:09
а отступы у тебя 4 пробела или 2? или 8? а может табы?
это был троллинг на тему python vs gofmt

Alexander
30.12.2016
13:51:59
то есть у нас есть программист, который на 100% знает весь микросервис и такие ситуации исключены

here1am
30.12.2016
13:53:39
а не возникнет той же проблемы, что и с микроядрами?

Alexey
30.12.2016
13:53:47
перевод всего на микросервисы ведь решит проблему?
нет, ведь всё ещё есть библиотеки как внутренние так и внешние

Alexander
30.12.2016
13:54:20
то есть у нас несколько маленьких команд, каждая команда отвечает за свои микросервисы, всё взаимодействие через API

Alexey
30.12.2016
13:54:23
если выделить каждую библиотеку в наносервис то будет медленно что пиздец

опятьже accidental complexity

Alexey
30.12.2016
13:55:11
а в каких ситуациях вам gc мешает в текущей версии golang?
попробуй написать на golang сторадж или поиск

Daniel
30.12.2016
13:55:17
бляяя

хуерадж или хуеиск

Страница 1913 из 4568