поковырял go, посмотрел видио, посмотрел HH.
язык не сложный (как мне показалось) по сравнению с Java, C#, особенно для 1с ника так как ООП там в примитивном виде, входит вполне неплохо, единственное предметку надо изучить с которой он работает.
Денег нормально предлагают + рынок международный.
Кто что об этом думает? Рассматривали подобные варианты? Какие подводные камни нашли?

(613) ага, узкоглазый транс с сюрпризом ))) мой знакомый сбежал, когда он/она ему предложила "бом-бом" сделать в Тайланде

Есть подозрение что некоторые 1Сники воспринимают переход из 1С в другие ЯП (особенно если микросервисы) как смену пола ))

(625)+ или ориентации

(621) ну хз. меня ничто так не перегружало как бокс. оказалось слишком интеллектуальное занятие для тупого 1сника) я долго не успевал перестраиваться - шагаешь с левой бьешь с правой, назад одноименными руками и это нужно быстро перестраиваться, делая разные упражнения в определенно порядке. Грядки я копал с детства, можно сказать я вырос на грядках летом и в библиотеке зимой, но так умственно я напрягался только на боксе)))

(623) ну мне помогает. существенную разницу вижу до и после.
(625) потому что мозг теряет нейропластичность. От однотипных задач мозг ржавеет. Даже в франче, когда у тебя десятки клиентов  с разными задачами, их можно обобщить к нескольким задачам. А когда предлагают что то новое, тут нужно напрягаться. а напрягаться нечем - все ржавое внутри) И вот сидит такой ведущий программист 1с обмазанный сертификатами и регалиями, а ему предлагают почувствовать себя опять тупым на уровне начинающего. Так что это хуже чем сменить пол)

(627) попробуй научиться ездить на уницикле ))
или танцевать сложные танцы

(629)+ https://www.youtube.com/watch?v=ltJ6Qf1ixyk ))

(629) вот на танцы думаю начать ходить с женой)

(631) с чьей?

(632) со своей, естественно

(630) по таким трассам и на обычном велике мозг освежится и отдохнет как надо

(548) ну как навязанные, просто еще абстракции, по сути фреймворк

(635) это типичный ORM

(636) в Golang вернулись по сути к истокам и ORM почти не юзают
там основное это sql в структуры и наоборот

(637) у нас юзался Gorm, но мы его выпилили и перешли на plain sql, ну с хелпером для генерации SQL.
как в 1С почти, только добавился полноценный CRUD, ушли быстрые элементы отборов, приходится велосипедить.

(612) Удары по голове тоже развивают нейропластичность. Может от этого ты почувствовал перезагрузку?

(638) мне больше всего зашел sqlx

(636) одно другому не противоречит

раз такая пьянка, расскажите знатоки иностранных языков. хочу себе сделать личный проект по управлению компом с телефона - использовать телефон как мышь и клавиатуру. В дальнейшем с возможностью получения изображения с экрана пк. Комп на винде, телефон на андроиде.  Я так понимаю клиент писать на джава/котлин под андроид. а что юзать под сервер на винду? и вообще в какую сторону копать?)

(642) уже давно есть

(643) я в курсе) и даже пользуюсь такой) но вопрос был не в этом)

(310) да восстанавливается много... вызовы апи конечно придется по справочникам/хэлпам искать долгое время но ничего нерешаемого при желании

(642) задачка довольно задротная. Под винду лучше взять язык от MS, C# или VC++ возможно VB прокатит.

(0) Go хороший вариант для перехода с 1с. Синтаксис простой, но после языков с большим количеством синтаксического сахара, го кажется очень скучным и рутинным, а если не использовать либы, то еще и сильно медленным в плане разработки. Возможно станет веселее после того как выкатят дженерики.

вместо дженериков есть кодогенерация. да и можно ещё указывать interface{}, потом делать кастинг типа, это похоже на java.lang.Object приводишь к нужному типу. дженерики вроде уже подтвердили кстати.

А как вообще типизированные коллекции без женериков возможны?

(649)
CMyType coll = new CMyType[]

))

Точнее
CMyType *coll = new CMyType[]

(649) Динамически проверять в момент выполнения. На 1С это

ТаблицаПериодов = Новый ТаблицаЗначений;
ТаблицаПериодов.Колонки.Добавить("НомерСтроки",    Новый ОписаниеТипов("Число"));

и да буду белой вороной по выбору

(648) Как по мне - это костыли и слабая безопасность, многие на джаву ругались за null поинтеры в рантайме, так GO из за слабой системы типизации нет функциональных преобразования типа map, filter для коллекций, нет option и довольно часто проблемы лезут в рантайме когда в других языках такое отловил бы компилятор. Лично у меня - это только расстраивает )
(649) В Go дженерики не добавили, но для Map что-то прикрутили похожее на дженерики, а set как коллекцию вообще забыли добавить )

(652) Это замедяет работу приложения и усложняет выявление проблем. Так как проблема выявленная в рантайме, всегда "дороже" чем проблема выявленная на этапе компиляции

(654) Согласен. Более того скорость работы с типизированными коллекциями характерно больше
https://blog.sikuda.ru/?p=3188

(655) Сори. наоборот. Со слабой типизацией Python3 27 сек, PHP7 19 сек
Java с оптимизацией меньше секунды

(656) Вроде бы все верно было написано. Про ПХП мало чего знаю, а питон тупит так как он интепретируемый. Если в питоне использовать pandas или numpy то будет на много быстрее. JVM для перф тестов лучше указывать флаг -server тогда JVM раньше начнет компилировать, а не интерпритировать куски кода.

(657) >pandas или numpy

это которые типа как ВК для 1С на C++ да?

(658) Имел в виду математические пайтон либы, можно сказать класика в плане анализа данных. Написаны скорее всего на C/C++ может их кто-то в ВК для 1с завернул, но я не в курсе

(659) это и подразумевал что они на C++ написаны и поэтому шустрые
а вот java, C# и тем более Go/Rust они таких извратов не требуют, можно нормально писать и шустро будет

(660)+ хрень этот Питон короче

Шурик уже сел учить что-нибудь?

(647) мне наоборот после java зашел golang, типизация не такая сильная как в java. вы наверное не копались в проектах, которые писали любители лямбд.
Map<String, Dickie> dickies =
futures
.stream()
.map(f -> {
    try {
        return f.get();
    } catch (Exception e) {
        logger.error("Error executing this shiet", e);
        return (List<Proxy>) (List) Lists.newArrayList();
    }
    })
.flatMap(List::stream)
.collect(Collectors.toMap(p -> p.getUrl(), p -> p, (p1, p2) -> p1));
и так весь проект.
идеология Go - если что-то можно сделать одним способом, то пусть программеры так и делают, а не придумывают велосипеды.
в джавке 1 тред - 1 или 2 мб, в голанге - 8 кб.
в джавке надо хикари фигачить, а в голанге в database/sql уже есть готовый пул.
в джавке блокирующая очередь, а в голанге - каналы.
да, классов нету, нету эксепшнов, нету интерфейсов.
но имхо, иногда для задачи они и не нужны.
kiss, yagni и вот это вот все.
вы наверное не сидели на проектах одного из банков, в котором есть пейсатели огромных классов с 4 extends и 3 implements (видел краем глаза у перейдуна знакомого).

(658) Какая разница что там под капотом. Для задач аналитики и ДС - это крутой инструмент. Под остальные вышеперечисленные языки прийдется больше писать руками и в итоге код и работать будет не сильно быстрее и на разработку уйдет очень много времени.
ЗЫ. Меня подтипывает когда го пытаются придвинуть к расту ) Это как палка копалка и наточенная лопата с алмазным напылением )

(653) в джавке тоже бывают null pointer exception, как и в голанге, который также можно в рантайме словить, если не везде натыкать Optional.of

(653) сет - map[interface{}]bool, как в 1С прямо :)
дженерики уже одобрены и появятся в мажорном обновлении, но это неточно.

(663) эээ зачем эксепшены если есть проверки на err ?

если некто написал кривую падучую прогу то гнать его ссаными тряпками
если проверить все входные параметры то никаких эксепшенов нафик не надо

лично я против добавления в Go и эксепшенов и дженериков если често

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

(667) дык я о том же. экспепшны в го есть - это паники, недавно 1 ган.. нехороший человек воткнул панику в сторонней либе, пришлось кусок логики к себе перетаскивать, а то им видите ли некогда.

(667) то в одном месте все ратуют за то что 'наконец писанины ненужной стало меньше', то на каждый чих надо писать портянки if err=

(663) Каждому свое. Если говорить о JVM языках, то мой выбор Scala. По этому подобный кусок кода глазу приятнее циклов и пересоздания коллекций, но на скале он бы выглядил на много лакончинее.
Было бы что-то в духе

futures.map(Try(Await.result(f, Duration.Inf)))

(670) +я еще молчу про то что надо через все цепочки вызовов err эти протягивать
вот например есть метод который получает данные с сайта, и оброботчик 400 и 500 ошибок...и ты блин внутри вызываешь еще десяток ф-ций...и из каждой должен внучную возвращать err до самой первой или писать обработчики...километры обвязки хз зачем, вместо того чтобы сказать raise Error500 если чтото критичное

и самый первый try его обработает...а не десяток вложенных

(670) + согласен, что бы не проверять err после каждого вызова. Меня это дико бесит в го

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

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

(674) тебе кто мешает написать func для проверки на ошибки?

(677)+ это явно лучше чем трайкачить оборачивая все вызовы и один хрен как то обрабатывать ошибки

(671) на скале приятнее выглядит. согласен
(672) а в джавке не надо throws над методами писать?
кидайте панику, тот же raise 500, а потом ее в recover.
если уж очень хочется.
(675) вы почему-то забываете о unchecked exceptions. те же профуканные err.
и go не даст вам неполучить error если она есть в сигнатуре метода.
если уж коллега явно написал
res, _ := makeSomeShit(), где makeSomeShit (int, error).
то понятно кому git blame делать.
(678) в go есть opentrace и тот же ягерь для отслеживания всяких каскадных ошибок.
тут надо норм инфраструктуру пилить, особенно если у вас микросервисы и вот это вот все.

(679) <кидайте панику, тот же raise 500, а потом ее в recover.
если уж очень хочется. >
а это хороший стиль в го паникой таким образом пользоваться?

(680) нет, нехороший.
но что void blablabla() throws millionsOfExceptions над каждым методом в цепочке, что if err != nil
все равно многабукаф писать, поэтому не вижу разницы.

(681)  throws millionsOfExceptions -- это ты в сигнатуре пишешь

а в if err внутри кода

забавно читать бизнеслогику когда у тебя каддая вторая строчка if err

(681) то есть кучи exceptions в сигнатуре вас не пугают?
и вы видимо в методах прокидываете exception до JVM, а не ловите их.
ясно, понятно.
(683) я тоже так могу:
забавно читать бизнеслогику когда у тебя каддая вторая строчка try {} catch {} finally

(678)(684) смысл эксепшенов, что и можно хоть в одном месте все ловить и стектрейс всеравно точно укажет на место возникновения ошибки
(680) Самому можно бросать панику, но все либы в любом случае 20-30% текста уделить строкам if err != nil {return err} Экспешн, что тоже самое только такая строка как бы написана не явно.

(684) <то есть кучи exceptions в сигнатуре вас не пугают?>
1) они не мешают
2) лишнее упоминание исключения в сигнатуре - не лишнее, это еще камень в сторону го от меня - неявная типизация интерфейсов.... interface kettle() { void turn_on() } interface nuclear_bomb() { void turn_on() }

перепутал присвоение ф-ции к интерфейсу - сами виноват, ГЛАЗАМИ СЛЕДИТЬ НАДО

(685) хз, мне норм. я не вижу разницы между throws в каждой сигнатуре метода (еще и при наличии runtime exceptions, которые unchecked) и error в сигнатуре функции.
ошибки надо обрабатывать, в любом языке. что в 1С, что в Java, что в Golang.
не помню где это было написано, но типа овердофига логики в программах - это как раз логика обработки всевозможных ошибок.

(686)  + а в яве такого не получится

(686) кто ж вас заставляет такие интерфейсы писать?
и вообще
type turnable interface {
turnOn()
}
а далее
type kettle interface {
turnable
}
зачем такое делать? интерфейс описывает действие, а объект его реализует вроде как. тут в проектировании ошибка.
такую же дичь можно и в джавке написать:

interface Turnable{
void turnOn();
}

public class Kettle implements Turnable {}
public class NuclearBomb implements Turnable {}

(686) зачем ГЛАЗАМИ СЛЕДИТЬ, если можно натравить линтер?
https://golangci-lint.run/

(684) >забавно читать бизнеслогику когда у тебя каддая вторая строчка try {} catch {} finally

"дык что там упадет если вся прока в try ... catch"©

(690) как ты линтером определишь что правильный метод вызываешь через интерфейс kettle?

типа

IKettle kettle;
IBomb bomb;

kettle = new bomb()

kettle.turn_on()

в яве так не получится, в го...дазапросто..чё лишние слова писать...интерфесы то одинаковые!

(692) не определишь, но зачем делать такие интерфейсы?
тут выбирать уже надо, чем вам хочется - свободы, но больше ответственности.
либо меньше ответственности, но куча проверок на этапе компиляции.
я бы выбирал от задачи, наличия фреймворков под задачу и удобства ЯП.
(694) если бы коллега писал такие интерфейсы, его бы запороли на код ревью :)

(695) < но зачем делать такие интерфейсы? >
нельзя полагаться на добросовестность программистов, фраза 'а вы так не делайте' не работает
в крупном проекте полюбому ктото в код нас*ет, даже ты сам если аврал
<если бы коллега писал такие интерфейсы, его бы запороли на код ревью :)>
ревью разные бывают, бывает что их вообще не бывает

вот у меня ща на проекте уже 4й человек меняется коллега...я в одну рожу код пишу..сам себе ревью

(696) кто-то должен ревьювить, это уже организаторские проблемы, то что вы описываете.
в условиях аврала, нехватки ресурсов и в джава код и в 1С код можно нагадить.

(697) < кто-то должен ревьювить, это уже организаторские проблемы,>
организационные проблемы - не оправдание тому чтобы в код гадить
а если компилятор и линтер помогают этого не делать - это плюс
а вот когда компилятор не помогает (злобный взгляд в сторону питона) то это плохо

когда проект очень большой, в одну голову сложно всё запомнить где у тебя kettle и где bomb

(687) "не помню где это было написано, но типа овердофига логики в программах - это как раз логика обработки всевозможных ошибок."- вот кстати да. бесит в 1с это то что приходится постоянно прописывать кучу обходов мелких ошибок. Вот прикольно придумали галочку "Проверять заполнение". Если бы сделали еще такой себе объект с конструктором проверки на ошибки. клацнул, галочки проставил, поля посвязывал  и все. а не писать кучу говно кода

(699) хз, у нас таких проблем нет. мб мы неправильно интерфейсы пишем или проект не такой большой )))

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

(701) ну тут дело привычки, в питоне вообще строгой типизации нет и все живут както, даже без mypy всяких

(703) +каждый раз выкатываешь релиз и смотришь в логи...ничё там в рантайме не падает ли... ;) забавно...бывает забудешь про яву и думаешь что это нормально

(704) ушел бы в яву, если бы не банки. у них там поехавшие безопасники.

(705) я работал в банковском процессинге, после их ИБ начинаешь реально понимать КАК в реальности должно работать ИБ
Очень скучаю потем временам...принимал там участие на подготовку инфраструктуры под pci-dss
оч полезно ИТшникам понимать для чего это надо и как работает

На любом современном языке можно успешно строить приложения, остальное вкусовщина. А смотреть на новые ЯП полезно для проф развития и мозга (может новые извилины завяжутся)
Го придумали, что бы студенты быстренько начинали вояли код, из минусов большинство фреймворков довольно скудные и все строят свой велосипед.
У джавы высокий порог входа, высокая конкуренция с опытными инженерами, много легаси проектов, но до сих пор считаю джаву одним из лучших языков для создания интерпрайз приложений.
Скала для ценителей, так как в начале прийдеться пострадать что бы вьехать в философию, а со временем скорость разработки на скале становиться очень высокой, так как все замороченные конструкции становяться понятными, но многогранность языка не позволяет преварить работу в рутину.

Скала, Джава и Пайтон хорошо подходят для работы с бигдатой благодоря экосистеме вокруг этих языков.
Лично я сильно загорелся идеей покодить на расте когда почитал о этом ЯП, раст воспринимаю как скалу для хайлоада или систем требующий быстрого отклика. Месяца назад мне в компании нашли задачу под это дело и чем больше понимаю концепцию тем интереснее. Так как их система упрвления памятью круто придумана, но ни на что не похожа

Уже перешел. Доход в номинале выше (хотя рубль уже не тот чем когда уходил), по покупательной способности примерно такой же, может чуть выше. Для провинции норм, учитывая что работаю именно в провинции хоть и косвенно на Москву. Обратно рассматривать не собираюсь, намного комфортнее, занимаюсь именно программированием а не вытиранием жоп бухам на фиксе. Хотя и на 1с тоже можно разрабатывать. Но php удаленно достаточно востребован, без работы сложно остаться

(709) ну да, у вас в Алтайском крае только удаленно работать, нищий край.

(710) зато мы в экономику края бабло приносим из вне) да половина айтишников местных кого знаю так работает

(707) не сказал бы что на го мало фреймворков или они все слабые. пока не нашел селениум нормальный на голанге.
очень странно, но у нас в го работают чуваки которые достигли мидловых позиций на своих языках. много джавистов кстати.
вы уже пишете на скала? или рассуждаете просто, работая на 1С большую часть времени?
смотрел у ИТ бороды разговор с растером, так и не понял, что конкретно чувак пишет на расте.
(709) если приходится бухам подтирать сопли, то нету линии тех поддержки, это больно. я из-за этого начал писать нетиповые.

(712) Ничего и рядом нет уровня Spring, Hibernate, Spark, Hadoop на счет очередей слышал про Nuts, но сомневаюсь, что дотянет до кафки.
Последнюю строку на 1с мне повезло написать 6.5лет назад и прктически сразу нашел работу по Джаве. На Скале пишу почти 5 лет, допиливал Apache Spark под крупного заказчика.

(712) На Го писал 5мес, но совсем не зашло - не мое. Раст после го как бальзам на душу ) По этому моя стратегия критичные к производительности приложения писать на расте, а не сильно критичные на  скале, а приложения в которых нет ограничений по производительности вообще не писать )

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

(713) а с чего это с кафкой нельзя работать? мы используем sarama.
спринга, хадупа и спарка нету? ну да, голанг он про lightweight приложеньки и все такое.
естественно, как я говорил выше, ЯП - инструмент под задачу.
крутой у вас опыт, поздравляю с успешным переходом во взрослое программирование, расскажите как свичнулись.
(714) раст пока редкий ЯП, у нас взяли голанг, потому что он проще и спецов по нему проще найти. про скалу знаю только то, что это Java для ML.
(715) по той же причине, по которой тут ругают утиную типизацию.
взрослые дядьки на стековерфлоу говорят, что не уследишь за тем, что могут передать какой-то функции, а значит она может повести себя непредсказуемее, чем при статической типизации. у метода ясный контракт и типа это лучше.

(716) в смысле не уследишь? это шо, базар в Хмельницком или Львове где могут обвесить обсчитать? Это программирование, если тебе передают не то, значит бьете по рукам такого быдлоговнокодера

(717) есть человеческий фактор. а тут на этапе компиляции не даст такому кодеру что-то испортить.
кстати, первая ссылка в гугле
https://hackernoon.com/statically-typed-vs-dynamically-typed-languages-e4778e1ca55

У плохого кодера есть миллион способов нас..ть в проект. И типизация в большинстве случаев не спасает

(718) у нас в церковно приходской английскому не учили)
"есть человеческий фактор. а тут на этапе компиляции не даст такому кодеру что-то испортить." то есть джава сеньйоры по факту переживают что они на столько глупые что при динамической типизации они затулят не тот тип данных? и все? жесть
(719) +100500

(720) в тру программировании без пендосского никуда. если что спасает google translate plugin.
не только не тот тип данных, что ж переведу плюсы статической типизации за вас:

1. Лучшее завершение кода.
2. Лучшая производительность. Ограничения типа предоставляют больше возможностей компилятору для оптимизации.
3. Вы можете получить подсказки и документацию внутри своей IDE во время написания кода. Это снижает вероятность неправильных предположений о поведении конкретных функций / методов.
4. Легче исследовать код. Для любой переменной или функции вы можете легко перейти к определению ее класса, не выходя из среды IDE, не зная ничего о структуре каталогов проекта. И наоборот, для любого определения класса или функции вы можете легко и однозначно увидеть место, где этот класс или функция используется в вашем коде, и перейти к нему, не выходя из среды IDE.
5. Проще работать с реляционными базами данных и другими системами, которые также полагаются на статические типы - это помогает быстрее обнаруживать несоответствия типов во время компиляции.
6. Снижается вероятность некоторых ошибок. Например, в языках с динамической типизацией, если вы не будете осторожны с очисткой пользовательского ввода, вы можете в конечном итоге делать странные штуки - при попытке добавить число 8 к строке "10", вы получите строку "108" вместо ожидаемого числа 18.

Перехожу на Python по нескольким причинам
1) в 1с нет интересных новых проектов. Либо доработка-мелочевка, либо бухг-тупой, то есть консалтинг. А я люблю кодить.
2) Доход снижается. В абсолютных цифрах - без изменений с 2019 года, а относительно цен на товары - снизился существенно
3) Английский простаивает, а это нехорошо
4) Возможности аналитики и визуализации данных open source решений на голову выше 1С.
5) Не хочу зависеть от экономический ситуации в РФ. Я- человек мира.
6) Много интересных людей и идей в мире тру-программирования.
В заключение: путь сложен, труден, приходится совмещать и жертвовать общением с детьми и сном.

(722) а почему не на golang?