Ещё какая правда. Года 3 назад у нас работал, приходил с диким перегаром. На action script программировал

2-3 в неделю не менее 1,5л пива

раз в неделю по 2-3 это не пьющий? ну и на неделе пару бутылок

февраль и май

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

Ну мы не просто флешку делаем. Там несколько огромных по функционалу программ, прям реально. Во всяком случае для action script

В таком случае получается: // Immutable pointer to mutable object var immut2mut const *Object = &Object{} immut2mut = &Object{} // violation! immut2mut.Field = 42 // fine immut2mut.Mutation() // fine /*--------*/ // Mutable pointer to immutable object var mut2immut * const Object = &Object{} mut2immut = &Object{} // fine mut2immut.Field = 42 // violation! mut2immut.Mutation() // violation! /*--------*/ var immut2immut const * const Object = &Object{} immut2immut = &Object{} // violation! immut2immut.Field = 42 // violation! immut2immut.Mutation() // violation! тоже самое касается контейнеров: // Immutable slice of immutable objects var immut2immut const [] * const Object immut2immut = append(immut2immut, Object{}) // violation! immut2immut[0] = Object{} // violation! p1 := immut2immut[0] p1.Mutation() // violation! /*--------*/ // Mutable slice of immutable objects var mut2immut [] * const Object mut2immut = append(mut2immut, Object{}) // fine mut2immut[0] = Object{} // fine p2 := mut2immut[0] p2.Mutation() // violation! /*--------*/ // Immutable slice of mutable objects var immut2mut const [] *Object immut2mut = append(immut2mut, Object{}) // violation! immut2mut[0] = Object{} // violation! p2 := immut2mut[0] p2.Mutation() // fine /*--------*/ // Mutable slice of mutable objects var mut2mut [] *Object mut2mut = append(mut2mut, Object{}) // fine mut2mut[0] = Object{} // fine p2 := mut2mut[0] p2.Mutation() // fine

Action script 3 вполне себе джава. Но с плеером увы не сложилось. А сам язык вполне себе. Но увы, флеш умер.

Action script 3 вполне себе джава. Но с плеером увы не сложилось. А сам язык вполне себе. Но увы, флеш умер.

Умер, да. Но выбора нет 😒 нам важно работать на всех платформах, у джавы проблемы с iOS

берешь такой и пишешь под каждую платформу свой апп

иначе только хелловорлды

берешь такой и пишешь под каждую платформу свой апп

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

мне есть что сказать. но чот лень. в следующий раз разведу об этом.

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

Что за люди такие, что один и тот же баг сделали на разных языках и платформах? Клоны что ли?

Баг в кодогенераторе.

баг на сервере, из-за которого приходится править клиенты

Ну тогда пусть в кодогенераторе фиксят

Что за люди такие, что один и тот же баг сделали на разных языках и платформах? Клоны что ли?

Я ж написал, что пошутил

Забавное из комментов: Наполовину офтоп, но раз уж речь зашла о го и оптимизациях, недавно разработчики решили выпилить ассемблерные версии алгоритма шифрования RC4 (ибо алгоритм слабый, а поддерживать ассемблер не хочется). После бенчмарков оказалось, что нынче код на го быстрее того ассемблера, что использовался в пакете. На треть.

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

ну выстави GOMAXPROCS больше

Так я и не ограничиваюсь

можно развернуть эту мысль?

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

логических ядер.

И я могу выставить больше?

но по факту, если нужны приоритеты - это только разные процессы

Подскажите хорошее решение. Есть расчеты, запускаемые раз в минуту, день и т.д. влияющие на записи в базе. Не хочу запускать их в основном приложении, чтобы не занимать треды. И возможно хотелось бы некоторые расчеты собрать в кучу, а некоторые, из-за своей толстоты, отдельно. То есть у меня должно быть запущено условно три процесса – основное приложение, которое я сбилжу и запущу, скорее всего в контейнере; жирный процесс; куча мелких процессов. Как лучше организовать второе и третье архитектурно и программно?

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

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

runtime.Gosched() в помощь

Спасибо, сейчас ознакомлюсь

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

https://play.golang.org/p/5fiE8v4VqfC с задачей справился

https://play.golang.org/p/lYQo-iGx2E Изменить программу, чтобы с 1 до 9 печатала) Вот задача

но не весь. частично он мне скорее всего пригодится. и вот такие вещи как const серьёзно усложнят рефакторинг.

https://youtu.be/B5xYBrxVSiE вот интересно на самом деле, что бы получилось, если бы мы взяли compile-time security из Rust и runtime из Go и чисто гипотетически совместили это в одном языке

С совмещением есть очень большие проблемы — концепции владения и заимствования не вписываются в GC.

из-за которого у нас по 100мс стоп зе ворлд

из-за которого у нас по 100мс стоп зе ворлд

мы тут нашли баг в сборщике гошном