jimplush.com/...eam-from-scala-to-golang
вот вам интересная статейка
Внутря — стоны обиженных scalaz и проклятыми функциональщиками, рассказы про то как ’да я уже 7 (семь Карл) лет программирую и прочие стоны обиженых.
Интерисуют мнения, выводы да и срачь в коментах тоже.
По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.
«Недолго музыка играла, недолго фраер танцевал»
Dropbox намучился с go и отказался от него в пользу rust
www.wired.com/...
А ведь раздача файликов по сети это собственно то, ради чего go изначально и создавался
Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.
Если приводить аналогии, то Go можно сравнить с русским языком, который и в Африке русский, а Scala с китайским, где в каждой провинции свой, непонятный другим диалект.
Ну Go об’єктивніше краще скали, бо у го прикольний маскот, а у скали якісь полоски намазані. А прикольні штуки звертають більше уваги. Нажаль з окамлом це не спрацювало бо там верблюд як на пачці камела.
кохання це...
... обирати мову програмування по маскоту
Тоді просто все на свої місця стає, згадай маскота С++ :)
як я можу згадати те, чого не знаю? :)
you guys know mascot of c++?
єбать колотіть тема ще жива
скоро 9 років
У мене є чього добавити btw
Scala фактично можно називати невдавшимся експерементом, сотона отвел мене від цієї лабуди.
я зараз трохи борю локальних фанатів F# і це майже саме тій самий сорт дурки.
внезапно зараз я би сказал что Java це кращя Scala і питання можно закривати.
go схоже вирійшив повторити всі помилки і добавляє що попало заради ... я не розумію заради чого
ітератори та шаблони у го — як вам воні у текущій формі?
Синтаксис у шаблонов с итераторами — отличный, над итераторами могли бы поработать в плане перфоманса, поскольку делают аллокации памяти.
А що, F# він же мертвий, всі його фічі давно в С# перенесли, та і майкрсофт давно відмовився від багато мов одна платформа, до один C# і кросплатформа.
А що, F# він же мертвий, всі його фічі давно в С# перенесли,
F# має багато фіч яких все ще немає у с# і їх впринципі неможливо перенести через те , що функції у c# ніколи не задумувалися як базовый building block будь-якої програми і в с# асе побудовано навколо классів, поліморфних типів, делегати і рекорди це мізерно примітивні фічі щоб називати мову функціонально орієнтованою.
Стосовно одна мова -
learn.microsoft.com/...et/fundamentals/languages
hez2010.github.io/...runtimes-benchmarks-2024
На тесте с миллионом конкурентных тасков Go проиграл по памяти Java (в 2 раза), Python, Nodejs, C# и Rust (в 20 раз).
Я считаю, топик можно закрывать.
Зараз тобі пояснять, що Go — то не для хайлоада, а для мікросервісів на один-два запити в місяць. :D
package runtime const ( // The minimum size of stack used by Go code stackMin = 2048 )
Звісно, варто переходити на Rust
Дивне рішення так по тупому імплементувати славнозвісні gorotines , го треба повчитися у java з вмплементацією green тредів. Там аналогічний код, але jvm з цією задачею справився набагато краще.
Гоферы, мой вас совет, не открывайте исходники Go и живите жизнь спокойно.
Остальным заценить как выбирается размер стека в зависимости от платформы:
async-runtimes-benchmarks-2024 Test Environment:
Hardware: 13th Gen Intel® Core™ i7-13700K
OS: Debian GNU/Linux 12 (bookworm)
memory-consumption-of-async Test Environment:
Hardware: Intel® Xeon® CPU E3-1505M v6 @ 3.00GHz
OS: Ubuntu 22.04 LTS, Linux p5520 5.15.0-72-generic
Лучше посмотри на тест повнимательнее, там оба варианта C# обогнали оба варианта Rust. Как ты можешь объяснить эту зраду перед закрытием топика?
там в конце после тыканья пальцем сообщества поправили Rust и он таки быстрее. По гоу улучшений не поступало.
Да там вообще написали, что цитирую «Old post». Чтож, после внесённых корректировок ответ принимается. А «улучшать» можно сколько угодно. Раз горутины отъедают по 4К памяти на штуку, можно сократить их количество, вот таким кодом
Voicechat: Product в Deftechсереда о 19:30
Yegor Chumakov
Sergii Vashchyshchuk
Азаза Заазааз
どうも 有り難う
Нестор Иванович
Qaraimam
Artyom Krivokrisenko
Олександр Шпак
Ярослав Характерник
func main() {
numRoutines, _ := strconv.Atoi(os.Args[1])
var wg sync.WaitGroup
wg.Add(numRoutines/5)
for i := 0; i < numRoutines/5; i++ {
go func() {
defer wg.Done()
for range 5 {
select {
case <-time.After(10 * time.Second):
case <-time.After(10 * time.Second):
case <-time.After(10 * time.Second):
case <-time.After(10 * time.Second):
case <-time.After(10 * time.Second):
}
}
}()
}
wg.Wait()
}
Ну и кроме того, почему-то отсутствует тест с кодом на чистом C. Там коротин нет, но ничего, можно через ОС-треды, как обычно.
Там уже пофиксили. Но на всякий случай: C# это серьезный язык программирования, который постоянно затачивают и оптимизируют, сам язык, компилятор и стандартную библиотеку, за счет инвестиция Microsoft. Так что не совсем удивительно, что он хорошо себя показывает.
То есть так недолго прийти к очевидной истине, что всё определяется бюджетом, а всё остальное помимо бюджета — не более чем клоунада.
Т.е. у гугла нет бюджета на самый лучший язык программирования в мире?
Всё впорядке, апдейты выходят регулярно. И тест этот тоже проапдейтили, так что всё нормально.
Кстати, а вот и решение той проблемы:
github.com/...pkg/tree/main/util/gopool
как видишь, не надо никаких больших инвестиций в масштабах компании, всё просто. Как говорится, ларчик просто открывался.
Добавьте в каждый таск работу с индивидуальным сетевым подключением, чтобы было больше похоже на реальную задачу в продакшне (вроде обработки http-запросов или websocket-подключений), и затем уже сравнивайте потребление памяти на миллионе одновременно обрабатываемых сетевых подключениях. Заодно сравните сложность получившегося кода.
Не все так однозначно, всей правды мы не узнаем.
Дізнаємося, адже в попередній статті 2023 року згадувалася робота з мережею:
In this blog post, I delve into the comparison of memory consumption between asynchronous and multi-threaded programming across popular languages like Rust, Go, Java, C#, Python, Node.js and Elixir.
Some time ago I had to compare performance of a few computer programs designed to handle a large number of network connections. I saw huge differences in memory consumption of those programs, even exceeding 20x. Some programs consumed little over 100 MB, but the others reached almost 3 GB at 10k connections.
на каждый бенчмарк все равно найдется умник который возьмет fasthttp потомушта быстро и отправит 1м POST запросов по 300-500мб каждый и охренеет с того что оно выгребает гигабайты памяти
еще подозреваю что нода все равно будет иметь меньший consumption из-за использования epoll по умолчанию
Есть реальные проекты с «миллионом» конкурентных тасков? Обычно такое количество показывает явный факап в сервисе, там будет сумасшедший оверхед на переключение контекста, расход памяти это еще не самое плохое.
Вот лучше б они распараллели одинаковую задачу на 1 млн с какой-то синхронизацией, чтоб заставить переключить контекст на каждом виртуальном треде, горутине, промайс и бенчмаркнули , кто быстрее ее выполняет
Когда Go выигрывает в бенчмарках: Go стронг, мощная конкрентность, миллион параллельных подключений.
Когда Go сливает в бенчмарках:
Есть реальные проекты с «миллионом» конкурентных тасков? Обычно такое количество показывает явный факап в сервисе, там будет сумасшедший оверхед на переключение контекста, расход памяти это еще не самое плохое.
Вот лучше б они распараллели одинаковую задачу на 1 млн с какой-то синхронизацией, чтоб заставить переключить контекст на каждом виртуальном треде, горутине, промайс и бенчмаркнули , кто быстрее ее выполняет
Заметил, что cgo-вызовы выполняются дольше, чем точно такой же код на чистом Go для коротких функций. Решил я поставить вызов сишной функции для поиска символа в строке, поскольку на C это разворачивается в 1 ассемблерную команду. Вместо кода на Go, где это делается в цикле перебором всех символов в строке. В результате перфоманс значительно просел. Выяснилось, что там происходит вызов целого бутерброда из врапперов и конверсий, в результате чего быстрее будет в цикле перебрать на гоу все символы, чем вызвать таким способом 1 ассемблерную команду.
Открою вам большой секрет — в стандартной библиотеке для Go есть функция для поиска символа в строке — strings.IndexByte, и для поиска подстроки в строке — strings.Index. Обе функции максимально оптимизированы, поэтому вам вряд ли удастся написать свою функцию, которая будет работать быстрее этих стандартных функций (неважно на чем — на C, Rust или ассемблере).
Если же вам удастся написать такую функцию, то скиньте ссылку на нее в ответ на это сообщение.
Кстати, заметил ещё случайно, что в новой 1.23 версии больше не нужна функция s2b, строка преобразуется теперь в слайс без выделения памяти. А заметил я это потому, что вылетел тест, который всегда срабатывал раньше.
Aliaksandr Valialkin
юнит тест
Qaraimam
var s = "some string"
var ps = unsafe.Pointer(unsafe.StringData(s))
/*var b = []byte(s)
var pb = unsafe.Pointer(unsafe.SliceData(b))
if ps == pb {
t.Error("string pointer is equal to pointer on new allocated bytes slice")
}*/
var b = s2b(s)
var pb = unsafe.Pointer(unsafe.SliceData(b))
if ps != pb {
t.Error("string pointer is not equal to pointer on same bytes slice")
}
вот закаменченый участок как раз вылетает, поскольку адрес одинаковый. Обратное преобразование работает при этом с выделением.
целого бутерброда из врапперов и конверсий
можно юзать unsafe, с правильным подходом он работает намного шустрее то что go строки не копируются в кучу для передачи либам и наоборот
Сделал, результат как-то не впечатлил вместе с unsafe и встроенной оптимизированной функцией, выигрыш перфоманса составил всего
for x := range 5 {
for y := range 4 {
if s[x][y] == sym {
n++
}
}
}
на вот этот вот var p = unsafe.Slice((*byte)(unsafe.Pointer(&s[0][0])), 20)
n = bytes.Count(p, []byte{sym})
Это при том, что в Можно еще на Rust написать с zero cost FFI.
Поздравляю с открытием Америки (что любой FFI, особенно из AutoMM среды, дорог) через форточку.
Продолжайте наблюдение.
Go slowly converts to Scala — itnext.io/...ng-direction-7dfda8a1a620
Це щоб Scala розробникам було комфортніше переходити на Go
а вони ще є?
я небачив живих скалістов вже років 7 як
Valentin Nechayev
Aliaksandr Valialkin
for k, v := range tree.walk {
if k == "foo" {
return v
}
}
Увидел возмущения по поводу того, что код, который компилятор сгенерирует, который разрабочтик даже не увидит, сильно сложный. Увидел негодование по поводу того, что код может допустить неопределенное поведение, если вернет значение из цикла и это значение будет «дорпнуто» в тот же момент. Увидел ностальгию по «раньше было лучше».
Чего не увдиел так это того как на самом деле должен выглядеть этот код на самом лучшем языке программирования в мире чтоб десять гоубоев не слягли с сердечным приступом.
Очень хорошо, что в Go добавят итераторы. Почти что коротины в классическом виде, в Lua большинство циклов пишутся через итераторы, то есть коротины, и ничего там сложного нет, это нормально. Очень удобно для перебора коллекций. Единственное отличие, что не сделали оператор resume, чтоб коротину можно было вызывать не только из цикла, но вообще из произвольного кода. Наверное позже сделают. С коротинами возможности параллельного программирования кардинально расширятся.
насправді мені саме це не сподобалось у нових фічах го
цукор не зрозуміло навіщо, читаємость та однозначность старих версій була головною фішкою як на мене
Очередная драма в лагере гоубоев.
После добавления дженериков, Гугл захотел сделать то, что он умеет делать лучше всего — встроить spywareopt-out сбор телеметрии в тулчейн Go, собирать данные с компьютеров программистов и билд серверов без чьего-то согласия. Народ нихрена не понял, возмутился, устроил срач на 500 коментов на гитхабе. Предсказуемо, тред залочили, неугодных забанили.
Наступним кроком буде перегляд реклами перед початком білду?
Дякую за новину про телеметрію, відключу
Так вони ще її не додали, це просто обговорення про бажання додати.
От того, что Go будет передавать телеметрию в Google, мне пофиг. А вот от того, что альтернативно одаренные любители матана с функциональщиной и бесполезными абстракциями засирают библиотеки Go бессмысленными дженериками, мне плохо. Поэтому лучше бы удалили дженерики перед добавлением телеметрии.
мне плохо
Приходи к нам в Rust, мы тебя научим.
Чему, засирать бесполезными абстракциями?
Научим пользоваться дженериками чтоб вместо «ой как мне плохо, дженерики добавили», вы говорили «ой как мне заебись что дженерики добавили»
А темплейтами C++ нужно сначала разучиться пользоваться, или это только на руку?
Rust cold start is 4 times faster than Go cold start on Lambda
Вівсьоврьоті! :D Go запускається швидше навіть, ніж блок з інструкціями потрапляє в L0 кеш проца. Він ще в пам’яті починає виконуватися.
Почему Rust никогда не заменит Go — kristoff.it/...blog/why-go-and-not-rust
Тому що фанатизм безмежний. Він за межами логіки та базується виключно на емоціях.
Вообще в Go как ни крутись, но рано или поздно появляется код на C. По разным причинам, то ли нет высокопроизводительного решения на Go, то ли вообще в принципе библиотека написана на C. А это за собой тянет ещё ряд особенностей. Во-первых, падает скорость компиляции проекта, и она становится равной компиляции кода на C. Во-вторых, теряется возможность собирать проект под некоторые платформы, поскольку нет компилятора C под какие-то платформы, и вообще код на C под них не тестировался. В-третьих, сокращаются возможности для кросс-компиляции, для этого нужны танцы с бубном. Соответственно, если проект развёртывается на другой машине, требуется долгий и творческий процесс установки и настройки. Можно конечно писать всё в девконтейнере, который займёт 2,5 гига только один образ. Поэтому разворачивать на типичном ноутбуке с 16 гигами такой вариант с девконтейнером — нецелесообразно, через пару часов разработки будет дикий свопинг из-за утечки памяти со стороны докера. Ну и конечно, код на C — неуправляемый, со всеми вытекающими следствиями. С другой стороны — а где картина выглядит как-то получше? Так что, если какие-то сложности при разработке на Go и возникают — они связаны с обузой из других языков/технологий.
Скоро выходит Go 1.20 с супер-полезной фичей — profile-guided inlining. tip.golang.org/doc/go1.20 . Ещё бы дженерики выпилили — получился бы лучший релиз.
Scala уже не подаёт признаков жизни. Ее ждёт удел Algol.
Кстати, а ты ту фичу из 1.17 не юзал ещё? Я тут посмотрел, компилятор выдаёт ошибки при компиляции кода прямо из примера вот отсюда tip.golang.org/...to_array_or_array_pointer
вот код, скопировал как есть — go.dev/play/p/96nkeJU1DhO
выходит, что там фигню написали?
Там нужно выбрать версию go dev, т.к. go 1.20 ещё не вышел, и код по умолчанию запускается под go 1.19. Вот по этой ссылке работает как надо — go.dev/...lay/p/96nkeJU1DhO?v=gotip
Ну понятно, работает. В общем, там создаётся новый array, и копируются значения из слайса, а не возвращается исходный нижележащий массив.
go.dev/...lay/p/UrD7R4o3i2j?v=gotip
То есть, синтаксический сахар для функции copy. Удобная фича.
Если нужен указатель на массив из слайса, то вот такой код должен работать: go.dev/...lay/p/kL0YS5U1NXD?v=gotip
Hive switches from GoLang to Rust
The switch from GoLang to Rust
The main difference between the new Hive variant and old ones is the programming language used. The old variants were written in Go (also referred to as GoLang), while the new Hive variant is written in Rust.By switching the underlying code to Rust, Hive benefits from the following advantages that Rust has over other programming languages:
* It offers memory, data type, and thread safety
* It has deep control over low-level resources
* It has a user-friendly syntax
* It has several mechanisms for concurrency and fearless parallelism, thus enabling blazingly fast and safe file encryption
* It has a good variety of cryptographic libraries
* It’s relatively more difficult to reverse-engineer
* It has a user-friendly syntax
Если они считают, что у Rust синтаксис проще, чем у Go, то остается один вариант — у них Rust головного мозга. К сожалению, медицина здесь бессильна :(
В чем сложность синтаксиса раста?
frp is written in Golang and is kind of a long-running system-wide service that provide network access to devices behind NAT or firewalls. It’s the only widely used project after ngrok 1 was stopped.
I’ve rewritten (and redesign?) frp in Rust, and seen a large improvement in performance and memory
The outcome is surprisingly good. Only 1/5 memory is used and the throughput is like several times larger than frp. I think Rust really has advantages in system software, particularly speaking, rewriting those written in Golang in the past :)
В Go подвезли дженерики — ждем появление STL и aspect-oriented packages на Go в стиле Александреску :( Программы на Go переписывают на Rust. Значит, пора переписывать VictoriaMetrics с Go на Rust.
пора переписывать VictoriaMetrics с Go на Rust
Sign me up
Значит, пора переписывать VictoriaMetrics с Go на Rust.
Варто очікувати статті на DOU на тематику Rust? (Це перший варіант моєї реакції)
Значит, пора переписывать VictoriaMetrics с Go на Rust.
Яку ж БД мені тепер згадувати у стаття про Go? (Це другий варіант моєї реакції)
old.reddit.com/...ware_in_the_wild/hkg2h75
A lot of endpoint security solutions a.k.a. virus scanners often deletes Go binaries when they reach a certain level of complexity. Crowdstrike just deletes every single Go executable.
Потому что антивирусы — самые бесполезные программы. Они не находят новые трояны с вирусами, пока разработчики антивируса не добавят их сигнатуры в антивирусную базу (на это могут уйти годы для нишевых вирусов/троянов). Кроме заведомо устаревших баз, антивирусы способны затормозить самый последний Apple M1 Pro до уровня ЕС1840 и поломать работу нормальных программ вроде тех, что написаны на Go.
Ты не очень понимаешь как они работают, к тому же написать не детектящийся вирус/троян нужна оч высокая скиллуха, а когда она есть ты не хочешь устраивать дестрой по фану, а лучше потратить время на работу с высоким рейтом, вспомни эпоху вирусов в нулевых (если ты ее застал), было все вплоть до уничтожения железа, а сча тройны да майнеры одни, которые изи находит почти любой антивирус
Вот поэтому, чтобы продолжать есть хлеб с маслом, разработчики антивирусов начинают выкручиваться как умеют, и детектить по любой надуманной причине.
Чёт не помню у себя ложных срабатываний у антивируса за последние 10 лет точно
Так вендовый дефендер срабатывает на всех кейгенах, и даже на мю-торренте. Остальные не проверял, поскольку этот хлам не нужен, но уверен, что картина та же. И теперь будет при дальнейшей развитии мысли антивирусописателей, что если исполнимый файл без сертификата, без иконки, и прочей лабуды — значит это малваре, что же ещё.
Так вендовый дефендер срабатывает на всех кейгенах, и даже на мю-торренте.
Битдефендер, есет тоже самое.
это как программисты считают что в дотнет коре есть di... выброси заглушку и поставь настоящий антивирус
А нічого, що це шпигунське програмне забезпечення?
шпигунське програмне забезпечення
dot ru
а, вот оно что... так есть же контрмера — шапочка из фольги
а, вот оно что... так есть же контрмера — шапочка из фольги
Ну в США вирішили, що забанити касперский вийде дешевше, ніж купувати всім шапочки з фольги: www.nextgov.com/...ernment-contracts/159742
Омг, нормальных антивирусов десяток, бери любой другой
Омг, нормальных антивирусов десяток, бери любой другой
+1. Бери будь-який норм. антивірус не зв’язаний за рашкою.
П.С. Я може не зрозумів весь тред просто. )
шо там с зиллою ?
я юзаю, но шот сомнения о его качестве имеюццо )
я юзаю, но шот сомнения о его качестве имеюццо )
Я колись собі поставив Comodo, який наче в Одессі пилили. Після запуску він зупинив/відправив в карантини половину сервісів Win XP: годиник, перемикач мови, etc.
І головне не має що йому заперечити ))
Самый лучший антивирус — Ubuntu. За 15 лет ежедневного использования ни одного вируса не пропустил.
это не антивирус, а операционная система для людей, у которых нет потребности в компьютере в принципе, телефон еще хороший антивирус — попробуй, желательно, который ретро
Какие потребности в компьютере не покрываются Ubuntu?
Все что отличается от браузера и редактирования документов в каком-нибудь недоредакторе
Сложно даже вспомнить, какой редактор не имеет версии под Linux, кроме Visual Studio и Xcode
Это точно. Вот поэтому я поставил Ubuntu под WSL, всё классно, и теперь даже не вспоминаю, какой редактор не имеет версии под Linux.
А что еще, кроме браузера и редактирования исходников, нужно программисту?
Dota 2 идет отлично, CS:GO, Metro все части, большая часть игр total war.
Большинство остальных игр с танцами и бубнами. В этом плане есть прогресс благодаря Steam и Lutris (под капотом конечно Wine).
Да, нет Microsoft Office, и популярных программ для обработки фото/видео. Есть бесплалатные альтернативы, но наверное они менее мощные, но я таким не занимаюсь, мне сложно оценить. Из известных есть Davinci Resolve. Adobe нет. Есть OBS.
Вы просто из .NET, у вас предвзятое мнение, Вы завязаны на Microsoft)
Конечно для среднего пользователя Ubuntu это сложно, зато бесплатно, и как Вы отметили, браузер там есть, и основные программы или их замены (бесплатные) тоже есть.
Но конечно, стабильность и выбор программ уступает Windows, но для разработчика там все есть, кроме тех кто пишет на C#, Swift, Objective-C.
Dota 2 идет отлично, CS:GO, Metro все части, большая часть игр total war.
Большинство остальных игр с танцами и бубнами. В этом плане есть прогресс благодаря Steam и Lutris (под капотом конечно Wine).
та не верю я в такое, игры под линукс не работают, уверен что почти у каждой что-то такое: steamcommunity.com/...ns/0/2288338908678031190 просто первая ссылка нет фпс, не играбельно
Да, нет Microsoft Office, и популярных программ для обработки фото/видео. Есть бесплалатные альтернативы, но наверное они менее мощные, но я таким не занимаюсь, мне сложно оценить. Из известных есть Davinci Resolve. Adobe нет. Есть OBS.
увы, это бесплатный недософт, работа с видео/звуком тоже в глухом тупике
Вы просто из .NET, у вас предвзятое мнение, Вы завязаны на Microsoft)
уже не
Конечно для среднего пользователя Ubuntu это сложно, зато бесплатно
для среднего пользователя и виндовс бесплатно
и как Вы отметили, браузер там есть, и основные программы или их замены (бесплатные) тоже есть.
они не дотягивают до оригиналов
Но конечно, стабильность и выбор программ уступает Windows, но для разработчика там все есть, кроме тех кто пишет на C#, Swift, Objective-C.
для шарпа там все есть, но зачем добровольно пользоваться этим убожеством я не понимаю. мне понятно фрибсд и т.п., но линукс с графической оболочкой это просто на смех курам
«не верю в такое», «недософт», «зачем добровольно пользоваться этим убожеством», «на смех курам», «система для людей, у которых нет потребности в компьютере в принципе»
Все понятно) Сойдемся на том, что на линукс меньше вирусов, а на виндовсе программ больше и фпс стабильней.
полно дистрибутивов которые никогда не продавались и не подавались трюкам типа убунты с их поиском с амазона. Та и потом они его после скандала сделали опциональным. Убунта раскрутилась за счет установки в 1 клик слоупоками, хотя дебиан, от которого она форкнулась практически имел те же самые возможности
Debian — если stable, то старое, а если testing/unstable, то вечно проблемы.
Ubuntu выехала на том, что заткнула именно эту дыру.
Сейчас поддеградировала, конечно, с
сейчас поколение антивирей давно ушло вперед от тех, что были 10 лет назад. Сэмплы высылаются в облако, где снифается весь трафик и действия трояна в песочнице. Используются эмуляторы и вм, и сигнатуры это только одно из защитных свойств, хотя я никогда не одобрял антивири, и с винды ушел много лет назад
Сэмплы высылаются в облако, где снифается весь трафик и действия трояна в песочнице. Используются эмуляторы и вм, и сигнатуры это только одно из защитных свойств, хотя я никогда не одобрял антивири, и с винды ушел много лет назад
Це робили з самого початку тільки все називалось простими словами
Антивірь по факту є діркою для доступу до машини
Сігнатури — так і залишилось основним методом
Причому їх так само роблять люди після реверсу сорців
сигнатуры давно для слабаков, все серьйозные конторы имеют свои песочницы и подрядчиков или даже свой инхауз тим для анализа. Ну и конечно жестокое разделение сетей.
Honeypots — були завжди
Сігнатури — це більш-менш надійний спосіб. Всі оті «розумні» способи визначення базуються на логіці — а давайте відправимо всі executables користувача до «лабораторії»
Про мережі ви не зрозуміло для чого згадали
)) да-да, а кастомные вирусы стали чекать название машины что бы определить — запускаться или удаляться.
Уже месяц прошел с момента выхода Go 1.17, но еще никто не написал об этом :( golang.org/doc/go1.17 .
Самое крутое изменение — теперь аргументы передаются в функции через регистры процессора вместо стека. Это поднимает производительность программ на 5%, одновременно уменьшая их размер на 3%. См. golang.org/doc/go1.17#compiler . Дженерики пока что не подвезли (и это здорово!)
Шел 2021 год
Го-девелоперы, внезапно, открыли для себя __fastcall
Мир уже никогда не будет прежним
У них тотальный NIH (простите, каламбур сам получился).
В чём-то это, может, и хорошо (для всего независимая реализация, начиная с сисколлов и линковки), но такими темпами до SSA они дойдут лет через 10.
Забавно. Но, судя по типовому ассемблеру, оно не было включено ещё в совсем недавних версиях.
Генератор с SSA очень характерно отличается от генератора без SSA. При SSA нет фиксированной позиции каждой переменной в стеке, одна позиция может использоваться в разное время для разных переменных, переменные могут находиться в регистрах во время других сложных вычислений, переезжая между регистрами, вытесняясь в стек и возвращаясь, и так далее.
Если же посмотреть на типовой выхлоп в чём-то более-менее сложном (как docker), там фиксированные позиции, переменные достаются из стека на короткое время и результаты кладутся тут же обратно, между операторами состояние стека содержит все переменные в конкретных местах. Это или не SSA, или оно использовалось крайне ограниченно, даже без оптимизации одной функции в целом.
Здорово. Ещё могли бы взять
или компилировать Го через промежуточный С код (trollface)
Лучше компилировать Go через промежуточный js-код
Жалко для ARM пока что недоступно
Теперь тормознутый говнокод будет тормозить на 5% быстрее :-)
Не знаю насчет говнокода, но нормальный код на Go тоже работает на 5% быстрее при переходе с компилятора go1.16 на go1.17.
Это конечно хорошо но что насчет слаки, тимза и скайпа? Когда их починят? Кстати на линухе вамще дерьмище, иногда падают(первые два, третим уже практически не пользуюсь), просто от клик на какой-то кнопке :-)
Ни одно из этих приложений не написано на Go, так что претензии не принимаются
но эталонный говнокод на Go
Fixed.
Лайна в этой репе с момента нашей последней дискуссии меньше не стало, скорее наоборот)
ОК, ждем ваш open-source проект с идеальным кодом
Целый месяц с мыслями собирался?))
апгрейтнулся и таки да на слабенькой конячке быстрее скомпилилось и запустилось а вот скорости сравнительно передачи переменных по ссылке и по значению надо будет проверить — наверное уже будет всетаки по ссылке быстрее раз не встеке значения...
С грамматикой у тебя ппц как плохо
Фигня какая-то в модульной системе Go. При переходе с одной минорной версии на другую — всё гладко и чётко, однако рано или поздно в библиотеке появляются breaking changes, и нужен переход на новую мажорную версию. Если просто поставить в гите тег v2 какой-нибудь, то линтер выдаст, что допускается только v0 или v1, и будет дальше продолжать грузить
Разберём на пальцах. В результате в github.com/user/project будет лежать
Я думаю, что разумнее было бы просто позволить go get работать с бренчами, и тогда последняя мажорная версия извлекается по дефолтному бренчу, а предыдущие мажорные версии со всеми исправлениями можно было бы извлекать по отдельным бренчам. И что интересно, я ещё не видел ни одной библиотеки кроме yaml, где бы реализовали модульную систему на разных мажорных версиях. Только и тут есть одно но. Эту библиотеку на разных мажорных версиях реализовали до появления этой модульной системы.
Заставив себе прочитати.
Замітка форумним гоу-боям: вчіться, як треба хвалити.
А то ваші дописи та їх формулювання у цій темі — це антиреклама для Go та його екосистеми (особливо тон дописів).
Ну, хіба, насправді це і було вашою метою — тоді так, у вас вийшло.
Вышла новая версия go — 1.16 — golang.org/doc/go1.16 . Следуя древней традиции разрабртчиков scala и c++, синтаксис Go был в очередной раз расширен — golang.org/doc/go1.16#language .
Самая главная вещь, что там добавили — это стандарты на интерфейсы виртуальной файловой системы. Именно этого функционала раньше не хватало, поскольку систематизирует работу с большим количеством статических файлов, файловых систем в памяти, а также теперь можно работать с zip, iso и с прочими файловыми системами юзая стандартные интерфейсы.
Я когда читал описание, у меня было такое впечатление, будто бы авторы подсматривали код моей библиотеки github.com/schwarzlichtbezirk/wpk, поскольку не только состав интерфейсов совпадал, но и их сигнатуры мало чем отличались. Это большой плюс, что теперь этот функционал есть в стандартной либе, а код в своей я без труда уже привёл под общий стандарт.
Итак, Go получает генерики,
github.com/...51#issuecomment-776944155
В каментах открыта стена плача для гоубоев.
Сейчас Валялкин прийдет и расскажет на сколько в Го будут крутые генерики, не то что в других языках.
открыта стена плача для гоубоев
Индусятские „копи-паста-архитекты” уже выстроились стеной. :)
„I know its not a fair comparison, but I think the spirit of simplicity of Golang was born from the incredible weight of complexity that languages like C++, Java, and Scala evolved into over years of iterative/feature ‚improvements’. In my mind Golang from go from an O(N) to O(N*N) complexity overnight once this feature is released.
To my surprise I have literally not missed generics once since switching to Golang and I used to be a huge proponent of them writing all kinds of elegant Scala code. My mind was freed from the extra layers of abstraction and I could focus on solving problems... it just required a slightly different way of thinking about the modeling. Being free from unnecessary abstraction in Golang is what allows people to move so fast with it IMO.
That being said, I will continue to use Golang because there really is not a better option out there for rapid and performant development right now.”
incredible weight of complexity that languages like C++, Java, and Scala evolved into
LOL, Java як раз була задумана простішою альтернативою Плюсам — без множинного наслідування, оверлоадінга операторів і решти ускладнень. Явно зайва в цьому списку.
и всеравно народ не осилил, слишком сложно.
Дивно що вони сподіваються що golang їм допоможе — говнокодали б одразу на JavaScript :D
и всеравно народ не осилил, слишком сложно
Так могут дальше на плюсах продолжать кодить, всё равно множественное наследование там никто не использует, не нужно совершенно.
в плюсах из сложностей не токо множественное наследование.
Все, перехожу на scala
Для тих, хто дуже чекав))
A Proposal for Adding Generics to Go
blog.golang.org/generics-proposal
Не проблема. Всё ещё можно поныть из-за обработки ошибок
Уже давно есть драфт с механизмом check-handle для обработки ошибок, с его использованием код значительно упрощается.
то есть спустя 11 лет Го может все таки приведут к нормальному языку, и он будет не хуже чем джава 10 лет назад
Ну и чем он в таком случае будет хуже джавы?
А я один тут такой, которому и без Genericов живется ничего ?
У тому то й справа... Нас більшість...
Це, певно, якась політкоректність щодо прихильників.. ;)))
«Generic Lives Matter»:))
Валялкин еще
Но будет хохма, если таки добавят
Наверное на скалу перейдут после выхода Go 2 с генериками.
Дело не в дженериках а в задачах. Я понимаю что 99% гошников не сталкиваются с задачами где нужно много работать с коллекциями (или другими задачами, где дженерики бы пригодились), но каждый раз тошнить «дженерикиненужны» — уже начинает надоедать.
Наличие дженериков позволит писать больше переиспользуемых библиотек, хотя и есть риск что в руках неумелых новичков дженерики будут юзатся где-попало (но это уже не вина языка).
Если даже священный Роб П. согласился с дженериками — значит есть причина, и какой-никакой запрос.
В Go есть и другие сомнительные вещи которые есть давно из коробки, но о них почему то предпочитают молчать (например empty named returns).
Він був як заміна С, С++, а не PHP
с garbage collector ему заменой си не светило никогда
(например empty named returns)
А что там сомнительного?
есть риск что в руках неумелых новичков дженерики будут юзатся где-попало (но это уже не вина языка).
Как раз это вина языка. Сейчас любители переусложненного шаблонного кода и аспектно-ориентированного программирования сидят на C++. Как только в Go появятся дженерики, эти альтернативно одаренные люди начнут писать на Go всякие аналоги STL, boost и прочих нечитаемых и в большинстве своем бесполезных библиотек из мира C++. В итоге код на Go станет таким же трудноподдерживаемым, как и на C++ с шаблонами.
всякие аналоги STL, boost и прочих нечитаемых и в большинстве своем бесполезных библиотек из мира C++.
это есть такое лично я буквально на неделе случайно узнал что оказывается в std:: есть permutations это прямо очень нужный и важный алгоритм чтобы покласть его в _standard_ lib
Как раз это вина языка.
это хороший вопрос к.м.к. в этом месте возможно таки сильно «особенности национального си++» но да такая специфика на лицо и
любители переусложненного шаблонного кода и аспектно-ориентированного программирования
просто на лицо вот из совсем свежего было тут на доу «а давайте запилим
Боже збав! Не хочу про таке навіть й думати..))
Servo — браузерный движок от Mozilla, частично написанный на Rust — выкинули на помойку — см. www.linuxfoundation.org/...sted-at-linux-foundation . Rust сдает и без того слабые позиции, в то время как Go уверенно движется к званию самого распространенного языка программирования.
Мозила передает проекты, которые она начала, в комьюнити, так как они уже получили достаточно инерции и не нуждаются в родительской опеке.
То же самое касается самого Rust
Мозила передает проекты, которые она начала, в комьюнити
Ну то есть, сливает другими словами.
Rust чувствует себя прекрасно. На подходе уже const generics
Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються (розробник Netscape Communications Corporation, Mozilla Foundation), і Rust стане популярним коли звикнуть
Mozilla вже показала що може робити хороші проекти, JavaScript-ом й зараз активно користуються
js — это хороший проект? Что, серьёзно? Его еле из говна за уши вытянули последними стандартами.
Валялкин, где обещанное виски?
Можете отправить Новой Почтой, я зафиксирую результат на видео и выложу — и будем считать тему закрытой.
Пока его нет, главный местный адепт Go в вашем лице считается нищебродом, не способным удовлетворить копеечное обещание.
Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.
Скажите еще, что не пользовались docker’ом c kubernetes (которые написаны на Go) в 2018 году :) Так что виски от вас.
Что не пользовался, я уже год назад ответил. И повторюсь: у нас были другие средства (vagrant, virtualbox, lxc).
Это уже второй раз, когда вы публично отбрехиваетесь от собственного зафиксированного обещания. Этого достаточно, чтобы заявлять: Валялкин, вы лжец.
Такой же лжец, как и в ваших «великих достижениях» в Go и у самого этого языка.
Створив нову тему для продовження Обережно Go книжки
Может потому докер и работает через жопу что написан на го?
работает через жопу
Я думал такое — от криворукости разрабов, а оказывается во всем виноват язык. :-)
в гугле написали го. в гугле написали докер. если контора которая создает язык не может что-то на нем адекватно делать то мне кажется их изобретение гавно
в гугле написали докер.
буду знати... ))
в гугле написали докер
„Docker Inc. was founded by Solomon Hykes and Sebastien Pahl during the Y Combinator Summer 2010 startup incubator group and launched in 2011.” © en.wikipedia.org/wiki/Docker_(software
простите, а можно узнать Вашу позицию, что Вы считаете более достойной альтернативой для решения задачи контенеризации и так далее ?
Которая работала бы не «через дупу»
в гугле написали го.
откуда такая информация ? разве не dotCloud написал docker ?
и разве сейчас компания docker, она же бывший dotCloud принадлежит гуголю ?
Гугль написал k8s, а вернее его фундамент, но там другая истония
По прошествии пяти лет, Go оказался востребованным и полезным языком, а Scala так и осталась уделом душных фриков.
Просто процент компетентных специалистов на рынке не изменился.
Если не ошибаюсь, ниша Go — трудонагрузить слабокомпетентных, которых статистически, внезапно, большинство.
За живе і до сліз
Найбільш оплачуваними спеціалістами є Scala та Go-розробники у Києві — їхня зарплата становить $4000.
Цілком можливо що Golang дійсно стане мовою для швидкої розробки і будуть прирівнювати до PHP чи JavaScript.
Але зараз на Golang переходять спеціалісти із-за цікавих проектів з високим rps, переходять компетентні, а слабокомпетентні ймовірніше рідше змінюють технології з якими працюють.
Под компетентными специалистами вы понимаете мазохистов, получающих удовольствие от матановского Scala-кода с нагромождением имплиситов, бесполезных абстракций и монад, в которых невозможно разобраться? Тогда возражений нет. Продолжу работать над production кодом на Go вместо того, чтобы тратить время на попытки разобраться в матановском Scala-коде, абсолютно негодном для production.
Удачи, и много денег, обязательно держите в курсе. Просто есть те кому нравится отрасль в которой они работают. Наверно, это задевает чуства тех кто «просто делает деньги»? Вас оскорбляет чья-то компетентность и любовь к отрасли настолько, что вы профанируете их усилия стать лучше в понимании что, как, и зачем они пишут? Да, здравый смысл называется математикой, и так уж принято что у математиков есть свой язык для понятного всем общения, который неплохо бы знать.
Какую отрасль представляет Scala? Отрасль монадирующих матанщиков-теоретиков с отрицательным коммерческим потенциалом?
Вообще не понимаю о чём вы. IT вам не отрасль? CS ненужон? Scala это вообще про весь большой и критичный к валидности тырпрайз. Это просто инструмент в руках инженера, которому нужно в удобные абстракции для адекватного проектирования и планирования рисков, а не колченогие «паттерны» для оправдания переписывания всего на каждый чих. Ну или тонны дублированого бойлерплейта как в Go.
Навалом кода на Scala в финансах компаниях в Лондоне
Странно, что эти компании до сих пор не обанкротились
В twitter и в linkedin уже 1000 раз пожалели, что связались со scala — см. en.m.wikipedia.org/...mming_language)#Criticism . Вполне возможно, из-за этого они никак не могут выйти в прибыль в течение последних 10 лет.
Инженеры фанг за пределами задроченных литкодзадачь и системдизайну не так чтобы боги (в среднем).
плз, можешь детальнее прокомментировать этот коммент?
dou.ua/.../?from=fpcomments#1989882
Под компетентными специалистами вы понимаете мазохистов, получающих удовольствие от матановского Scala-кода с нагромождением имплиситов, бесполезных абстракций и монад, в которых невозможно разобраться?
из сырых окопов Скалы виднее, чем со стороны ))
А что коментировать? Высокое ФП с монадами — совершенно иная парадигма, с кучей собственных концепций, понятий, и математических законов. Чтобы в этом всем хоть чутку разобраться одного туториала прочитать будет недостаточно. Чтобы пофиксить неработающий реальный код, скопипейстить решение со стек оверфлоу не получиться.
Для народу, который с трудом осиливает базовые понятия ООП, и совершенно плавает в паттернах, оод, архитектуре и солидах — скала с фп это бетонная стена.
бетонная стена
яхту примерно так и назвали — скалА.
а стОит ли оно реально того, чтобы из неё высекать энтепрайз?
кмк, энтепрайз технологичнее лепить. Ну и рынок, похоже, к этому пришел.
а стОит ли оно реально того, чтобы из неё высекать энтепрайз?
Я работал несколько лет на ынтерпрайзе где на полном серьезе юзали скалу с фп. Как по мне применение скалы широко на ынтрепрайзе — это куча проблем, описанных как в статье так и в теме. Поиск людей, расхождение в стиле кода и синтаксиса, проблемы с билд системой и версиями компилятора. Есть и нишевые моменты, например для ФПшников, ФП — религия, и они никогда на императивный код не согласяццо, даже если он быстрее, проще и короче :-) Итд итп, что для большого интерпрайзу будет проблемой.
В некоторых компонентах где есть смысл использовать спрак или акку, или где нужно писать парсеры, компиляторы, дсли — использование скалы имеет смысл.
твитер продолжает активно нанимать людей на скалу
А что им остается делать? Кто-то же должен заниматься поддержкой говно-Scala-кода.
Алчно скалясь, за большие деньги они переписывают кровавый энтепрайз на Джаву, отбиваясь от хантеров.
Ну вот, сначала контора связалась со скалой, и потратила на это деньги, теперь будет тратить деньги на то, чтоб избавиться от скалы. Тратить будет достаточно, чтоб кто-то отбивался от хантеров.
чтоб избавиться от скалы
en.m.wikipedia.org/...mming_language)#Criticism
вероятно, да
твитер продолжает активно нанимать людей на скалу
вероятно, у них специфика продукта (и доходы) позволяют юзать ФП
Доходы twitter явно свидетельствуют о правильном выборе Scala :) Operating income за три квартала 2020 года — минус 84 миллиона долларов. finance.yahoo.com/...te/TWTR/financials?p=TWTR .
Да просто твиттер, сам по себе, нафиг никому уже не уперся. Имхо конечно, но твиттер мчится к закату.
Зараз шукають гофера в Києві на проект «конкурент Twitter», в LinkedIn активно гоферам розсилають пропозиції
Илон Маск уже уволил всех scala-программистов и заставил оставшихся программистов переписать все на Go. Так что твиттер ещё протянет с десяток лет.
Тем временем, Apache Spark (полностью) и Kafka (частично) написаны на скале :D
Использовал скалу пару лет, на Go пишу этот год, Go таки гораздо проще и легче. Но для нагрузочного тестирования Scala все годится, потому что Gatling. Хотя там, конечно, глубоко вникать не надо.
Новость мирового масштаба: самая быстрая база данных для временных рядов — VictoriaMetrics — написана на Go! Ждем появления конкурентов на Scala и Rust.
Новина хороша, але InfluxDB переписують на Rust
GitHub InfluxDB IOx on Rust (нова)
GitHub InfluxDB on Golang (існуюча)
А через рік-два можна буде написати нове порівняння Insert benchmarks with inch: InfluxDB vs VictoriaMetrics
InffluxDB IOx на Rust работает в 6 раз медленне, чем VictoriaMetrics на Go — medium.com/...toriametrics-e590f847935b
А ви швидко відреагували, вітаю з найшвидшою TSDB, плануєш додавати в статтю на вікіпедії Time series database?
Пытался добавить VictoriaMetrics в эту статью раз пять. Модераторы каждый раз удаляли мои правки со всякими объяснениями вроде «вы не привели ссылку на статью с вызывающей доверие информацией о VictoriaMetrics» :( Попробуйте добавить сами — может, у вас получится :) Если что, то вот тут можно найти статьи о VM.
Припущення що редактори мають відношення до InfluxDB або іншої БД, тому й маніпулюють
Така ситуація для Вікіпедії трапляється часто в політичних темах, в ІТ мабуть рідкість але буду вважати за прецедент
Буде ефективніше якщо створиш тему на DOU, щоб допомогли додати VictoriaMetrics до статті Time series database
Может потому что никто в мире о какой-то подделке не слышал кроме тебя?
Из моего опыта, БД становится адекватной минимум после хотя бы 3 лет юзания в настоящих продакшенах (правда этим продакшенам на это время не позавидуешь)
Согласен. Вот эти пользователи VictoriaMetrics не в счет — victoriametrics.github.io/CaseStudies.html . И вот эти тоже — github.com/...ictoriaMetrics/stargazers
А через рік-два можна буде написати нове порівняння
Желательно, чтобы бенчмарк делал не сам автор)
Так в чем проблема? Проведите свой бенчмарк и опубликуйте результаты!
будет более подходящий юзкейс — сделаю
Конкурент на Rust пока сливает по производительности в 6 раз.
Как то Intel делали сравнение OpenMP и OpenCL на их процессорах, взяли в интернет бенчмарк, получается OpenCL уделывает OpenMP в четыре раза запускалось на процессоре, а не на видеокарте или акселераторе. Начали разбираться почему? Выяснили что OpenCL код банально реализует более оптимальный алгоритм и что этот бенчмарк сравнивает не технологии — а программистов. Переделали OpenMP код под этот же алгоритм, получилось одинаково.
Не слышал о VictoriaMetrics, взял на заметку
Теперь ждем новости, что ее переписывают на Rust))
/* пошел за попкорном */
Коментар порушує правила спільноти і видалений модераторами.
Я тут посмотрел твой github.com/VictoriaMetrics/fastcache, и вот интересен вопрос. Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь? И ещё по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?
Если надо кэшировать контент файлов вместе с их MIME-типом, и что-нибудь ещё, как ты это делаешь?
Пишу функции Marshal и Unmarshal для составных типов и записываю в кэш сериализованный байт слайс.
по какому принципу удаляются записи из кэша — самые старые, или самые редко используемые, или как-то ещё?
Данные хранятся в циклическом буфере. Поэтому новые данные затирают самые старые, как только объем кэша достигает указанного лимита.
Пишу функции Marshal и Unmarshal
В принципе это логично, только в этом случае реаллоцируется лишний слайс размером как минимум с файл + данные.
Данные хранятся в циклическом буфере.
Ну понятно, просто бывают такие кейсы, что частота использования разных записей сильно отличается.
в этом случае реаллоцируется лишний слайс размером как минимум с файл + данные
Слайс можно переиспользовать при следующей сигнатуре функции:
// Marshal appends marshaled data to dst and returns the resulting byte slice. func Marshal(dst []byte) []byte
просто бывают такие кейсы, что частота использования разных записей сильно отличается
Ага. Все случаи не покроешь оптимально. Приходится оптмизировать пакет под конкретные случаи использования — в данном случае fastcache оптимизирован под использование в VictoriaMetrics. Там важны следующие требования:
Вернёмся опять-таки к кэшу :)
Вот у тебя общая идея основана на bigcache, а там в апи есть Append, которая решает вышеуказанную задачу эффективным путём. Кроме того, там есть итератор, чтоб просмотреть содержимое кэша, хотябы по ключам, а у тебя его почему-то нет. Зато есть запись каша в файл, сугубо частная задача.
Насчёт dst []byte. В случае если читать серию записей подряд в одной горутине, то такой подход вполне оправдан. Но если записи читаются из кэша по одной, тогда держать такие буфера — это неэффективное расходование памяти, которое может привести к свапу страниц в файл подкачки.
Если в fastcache чего-то нет, значит, оно не понадобилось в VictoriaMetrics. Зачем добавлять функциональность, которую ты не используешь? Ведь потом ее не выпилишь (т.к. пользователи будут недовольны) и придется заниматься ее поддержкой.
Насчет dst []byte — забыл дописать еще одно требование для кэша внутри вм — размер сохраняемых в него значений ограничен 64кб. С течением времени в некоторых местах потребовалось хранить более длинные значения, поэтому была добавлена надстройка (костыль) для этого.
Но если записи читаются из кэша по одной, тогда держать такие буфера — это неэффективное расходование памяти
Для решения этой проблемы есть sync.Pool .
У вас выходит RCU алгоритм, что хорошо например для смканировпния всего сайта. Лучше заменить на LRU/SLRU.
Так люди сейчас просто CDN подключают и там все сразу, даже голову морочить не нужно. Но в целом SLRU обычно применяют для таких кешей. В целом там какая-то билеберда, софт построен вокруг паразитного влияния сборки мусора, в Rust ее вообще нет, там хитро компилятор и сборщик следит за временем жизни объектов. Но у многих алгоритмов сборки мусора другое большое преимущество — дефрагментация памяти.
The State of Developer Ecosystem 2020
www.jetbrains.com/lp/devecosystem-2020
Цікава таблиця
«Do you plan to adopt or migrate to other languages in the next 12 months?»
Scala — аутсайдер...
Ось так вимірюється справжній рейтинг вподобань;))
удивляет котлин — в чем существенное преемущество над последними жабами чтобы на него переходить ?
Крім переходу, ще мається на увазі й опановування нових... додаткого до основного стеку...
котлин как раз не удивляет
удивляет, что кто-то еще предпочитает java
Тим, хто дуже чекав... покращення)))
The Next Step for Generics
blog.golang.org/generics-next-step
Сейчас гоубои набигут и будут рассказывать о том, что генерики в Го это лучшее, что могло быть сделано за всю историю информационных технологий
Ті, хто так висловлюватиметься — не є православним)) гофером...;))
генерики в Го это лучшее, что могло быть сделано за всю историю информационных технологий
Человечества. За всю историю человечества.
кстати в java в свое время хейтили введение стрим апи, мол это следование моде и хайповым тенденциям.
В джава ввели Stream API? Збс, надо заценить!
Продолжение той же ветки:
— I’ve never had such feedback. All devs who discover this fall crazy in love with it and don’t stop (over)using it
— Yes, that’s what it looks like AFTER we make a big change. Before, when we’re talking about making a big change, we get an army of angry villagers with pitchforks and torches, with dire predictions of „you’re going to destroy Java.” It was very much this way with lambdas.
Просто любые более менее значительные изменение вызывают батхерт у людей т.к. меняют их реальность.
Оно работало очень сильно медленнее чем императивный код и кушало память к тому-же. Потом оптимизировали в 1.8. До версии 1.5 в Java тоже Generic Type-ов не было и весь код рябел ворнингами и так было по моим ощущениям примерно до явы 1.7. Ещё с Guava вынужден признать что функциональный подход в CRUD подобных приложениях, обработке бизнес данных, работает сильно лучше императивного. В системных, десктопных и т.п. — напротив.
Оно работало очень сильно медленнее чем императивный код и кушало память к тому-же. Потом оптимизировали в 1.8.
Спасибо что освежил память. Оно в 1.8 только и появилось, до этого все гуаву и юзали о которой ты говоришь. Перечитай релизы, и посмотри на даты между ними что бы вспомнить как это долго было все.
Скорее о том что они «не нужны»
Contracts — Draft Design: July 31, 2019 (...this version of the design draft is similar to the one presented on August 27, 2018...)
Type Parameters — Draft Design: June 16, 2020
«А там или ишак помрет, или падишах...» :)
Почитал новый драфт, этот уже гораздо лучше чем предыдущий. Читается всё легко и никаких непоняток не возникает. Там отказались от контрактов, и решили реализовать через интерфейсы, что более интуитивно понятно и пересекается с уже реализованными концепциями. Заодно вместе с генериками, расширяются возможности использования интерфейсов, где можно перечислять к каким типам они применимы. Помимо функций с параметрами типов, также будут возможны параметрические типы данных, и генерики-интерфейсы.
В драфт с новой обработкой ошибок судя по всему ничего нового не вносили, но это вполне объяснимо — там и так всё идеально.
Гоубои мометом перекрасились, теперь генерики это наше все :)
Да к сожалению, авторы реализовать новый функционал обещают только летом следующего года. То есть в совокупности 3 года будут тянуть резину. Но в этом есть даже определённые плюсы: новый функционал не принимается наспех, а проходит тщательное обдумывание, обсуждение, и видно что концепт становится всё лучше и лучше. Становится всё меньше аргументации для критики.
go.googlesource.com/...2draft-type-parameters.md
Вот новая версия драфта, где концепт генериков на контрактах изменён на концепт генериков на интерфейсах. То есть, в целом этот концепт хорошо интегрируется и дополняет существующий концепт эмуляции генериков с работой на интерфейсах и утиной типизации.
это и отлично, не бездумное раздувание языка бессмысленными конструкциями, как в формошлепской ноде или пыхе, а тщательное планирование дальнейших действий)
Пока @Aliaksandr Valialkin молчит, сам подброшу: www.youtube.com/watch?v=Dq0WFigax_c ....
... whereas generics in Java are defined via erasure, in Go we use monomorphisation
думаю, він у прострації, бо у го з’явився страшний матан
Самый важный плюс Go это его читаемость и единый стиль. Когда открываешь любой проект на гитхабе написанный на голанге, его ОЧЕНЬ легко понять и вьехать что там происходит, и уже через денек можно контрибьютат. В то время как каждый проект на Scala, да и на Java, надо сидеть долго и упорно разибраться что там происходит и какой там код-стайл. Особенно в скалке, где на каждом маломальски большом проекте — свой субдиалект языка. Отсюда и продуктивность Go, программист концентрируется на задаче, а не думает как бы ему написать тот или иной кусок кода.
Если приводить аналогии, то Go можно сравнить с русским языком, который и в Африке русский, а Scala с китайским, где в каждой провинции свой, непонятный другим диалект.
Вопрос в сложности самого проекта. При достаточно сложном проекте увеличение уровня абстракции (тот самый «свой субдиалект языка») _упрощает_ концентрирование на задаче. В случае, если в языке нет механизмов для повышения уровня абстракции — то либо задача будет похоронена под мелкими деталями реализации, которые не относятся к самой предметной области. Либо эти абстракции будут таки введены, но будут выглядеть коряво (так как будут ограничены «простым» синтаксисом языка) и будут стоить каких-то затрат в рантайме (так как возможности метапрограммирования — никакие).
Ну... Это скорее зависит от сложности самого проекта. Попробуй быстро разобраться в коде Ethereum, Tendermint или Ethermint. Тут скорее вопрос в том, что обычно Go выбирают для решения более простых задач, поэтому и разбираться в них проще.
Ну на Java не скажите, обычно это или Spring Boot стандартный. Просто на Go lang пишут другого типа код. На Яве считай просто надо поднастроить фреймверк из готовых компонентов.
Тем временем Go занимает третье место среди наиболее желаемых языков программирования. Scala плетется где-то в конце второго десятка.
Якщо дивитись далі то Scala-розробники мають вищу винагороду ніж Golang-розробники
What Languages Are Associated with the Highest Salaries Worldwide?:
Вибирай що більше подобається:
Тоже что и Assembler вернее гораздо хуже. Nothing works and nobody knows why.
Это потому что нет желающих ломать мозг в типичном матановском коде, написанном на Scala. Поэтому приходится предлагать более высокую зарплату, чтобы хоть кто-то взялся за эту работу.
На 7% больше? Это может быть в рамках погрешости опроса.
Там є цікавіші порівняння:
Тут вот нода догоняет ithare.com/...golang-vs-node-js-debate -> (вентилятор)
Вброс не засчитан, поскольку то статья для девочек (hr если код пишут и строят инфраструктуру):
If programmer does nothing to exploit multi-coring in her program, both golang and Node.js are single-threaded. However, if programmer does want to go multicore, she has to use goroutines (in Golang) , or cluster module (in Node).
both golang and Node.js are single-threaded
полнейшая чушь, нода юзает вспомогательные потоки для выполнения асинхронщины
nodejs.org/...ont-block-the-event-loop
Node.js uses a small number of threads to handle many clients
Про Го то отдельная история с горутинами, смысла нет это расписывать, в оф доках все расжевано как там треды и горутины работают и тюнить это
Scala мне просто всегда не нравилась и по прежнему не нравится, очень сложный язык без каких либо существенных преимуществ перед Java, на той же платформе. А Go 10 лет назад и сегодня это разные языки, современный вполне себе не плох. Недостаток — Go в некотором смысле уж слишком прост, разработчики переусердствовали с упрощением.
А Go 10 лет назад и сегодня это разные языки
Существенная разница только лишь в том, что ввели generics версии 1.18, и модульную систему в 1.11, причём обтесали её к 1.17. В остальном кардинальных отличий нет.
Лучше бы не добавляли дженерики. Только время зря потратили, усложнив компилятор и снизив скорость компиляции. Никто в здравом уме не пользуется дженериками в Go, т к они только усложняют код, не решая никаких практических проблем. Так что 10 лет назад Go был таким же, как и сейчас.
Ви про яких саме сектантів? І тяжко зрозуміти про що ви
язык без языка
В то время, как размеры скомпилированных программ на java продолжают расти семимильными шагами (java-программисты считают нормальным иметь jar-ники в сотни мегабайт), скомпилированные программы на go в версии 1.15 будут занимать до 30% меньше места — mobile.twitter.com/...tatus/1256348714198654976 . Это еще сильнее увеличит и без того огромный разрыв (10 и более раз) между scala (java, cotlin) и go в размерах бинарников, docker-контейнеров и объеме памяти, используемой работающими программами.
есть достаточно много серьезных проектов в проде на Го делающих не только «фыр-фыр-фыр» в консоль и с потраченными тысячами часов и толстая джава там не нужна совсем со всем тем, что вы написали. Есть ниши, где от сервисов требуется скорость и простота, а не раздувание сотнями пакетов с мертвым линкующимся кодом
В итоге получая конечный native binary или докер-образ в мегабайты, не потеряв преимуществ JVM
Это как-то не православно, docker написан на Go, вам нужно замутить какое-то альтернативное решение не потеряв преимуществ JVM.
В go все работает искаропки, а в scala (java, cotlin) нужны танцы с бубном вроде тех, что вы перечислили в своем сообщении, чтобы хоть как-то работала программа.
Но вы продолжайте приходить и сравнивать golang binary, делающий в консоль фыр-фыр-фыр с JVM-based-приложением энтерпрайз-уровня, с сотнями библиотек внутри и тысячами человеко-часов разработки
Никогда не понимал, зачем тянуть стомегабайтные зависимости, если проще написать самому или скопипастить 100 строчек необходимого кода? Остальные миллионы строк кода из зависимости ведь все равно не используются.
Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?
Есть, конечно, деятели, которые из-за одного класса притащат в проект целый огромный фреймворк, но это проблема недостатка культуры разработки конкретного программиста, а не технологического стека.
Наверное, потому, что «стомегабайтные зависимости» — это нечто более сложное, чем условные 100 строчек кода?
Да, зависимости обычно более сложные, но обычно проще написать 100 строчек кода, чем тянуть зависимость. К сожалению, программисты предпочитают тянуть
Да, зависимости обычно более сложные, но обычно проще написать 100 строчек кода, чем тянуть зависимость.
когда вы работаете в одиночку.
а когда уже 3+ — то 3 реализации одного и того же, но которые получатся разными — нужно будет саппортить тем кто не в курсе что их там 3.
К сожалению, программисты предпочитают тянуть100-мб зависимость :(
правда между крайностями — писать свои лисапеды и тянуть либы из которых нужна сейчас и потом только одна функция.
тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?
тебе 100 строчек в других ЯП религия не позволяет копипастить? или это исключительно уникальная фича го-шников?
Go в отличии от других ЯП в силу концептуальных особенностей предрасполагает к постоянному копипасту. Поэтому только в Go программист вместо того чтобы тянуть
ты только мокнул го в го и написал
Бессмысленно спорить об очевидных преимуществах Go над другими архаичными языками.
одним постом. хз о чем тут спорить...
ты только мокнул го в го
Как уже неоднократно говорилось, Go — язык самодостаточный, и вполне естественно, что даже мокать Go можно в Go. Во многих других языках такой фичи нет, так что как видим, преимущества Go раскрываются с каждым шагом со всё новых сторон.
Мало кто знает, что Go настолько самодостаточен, что компилятор и рантайм Go написаны на Go — см. github.com/golang/go . Это вам не scala с java, написанные на Си.
Не було нічого, і був лише Го. І зробив Го компілятор Го і рантайм Го. І побачив Го що це добре.
В go все работает искаропки, а
что там уже reduce/filter можно сделать даже из коробки без рефлексии и бойлерплейта?
Ни разу не видел кода на Go, который бы сильно выиграл в читабельности или поддерживаемости, если бы в Go была поддержка reduce/filter.
для „hello world” можно и без reduce/filter, да
Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala, мб кроме баз данных. какие-то прокси и системные утилиты которые писались бы на С. Не понимаю к чему сравнение с scala или java.
Что и показывает ту нишу, где применение Go вполне оправдано. Но некоторые фанаты Go не унимаются и при каждом удобном случае пытаются пиарить Go как one language to rule them all.
Я, если что, недавно сам маленький http сервер делал на go, потому что функционал там примитивный, а скорость и потребление памяти важны. Так что, меня сложно отнести к хейтерам языка — скорее, я сторонник подхода «каждой задаче — свой инструмент»
потому что Go — это «bash» для написания микросервисов. ну может быть иногда и макро- :)
Я так понимаю потому Пайк и сотоварищи сопротивляются введению дженериков.
Зачем в bash’е дженерики? Ах понадобились — так значит вам нужен другой инструмент. либо вы не умеете проектировать системы как — микросервисные системы.
Первые 3 страницы, там почти ни одного потенциального продукта который мог бы быть написан на java или scala
Это еще раз наглядно показывает ущербность scala и java по сравнению с великим Go!
Так нечего сравнивать. Видимо твое го несравнимое.
Більшість гоферів дивляться та порівнюють з Rust, ще пару років тому вже був такий тренд Kyiv Go Meetup January 2018
действитель, это же какая читабельность какой-то сраный contains для массивов/слайсов писать на каждый тип и т.п.
Вот хорошая цитата про ООП в java и scala:
You wanted a banana but what you got was a gorilla holding the banana and the entire jungle
Давай, расскажи нам, как эту проблему решает «расово верное» ООП в golang?
Go предоставляет следующие инструменты для решения этой проблемы:
— Применение композиции вместо наследования. Она позволяет импортировать только ту функциональность, которая действительно нужна пользователю.
— Использованием интерфейсов с небольшим количеством методов.
— Предпочтением небольшой копипасты вместо импорта здоровенной зависимости.
как и 99.9% других языков...
Ctrl+C-Ctrl+V oriented development.
Ctrl+C-Ctrl+V oriented development.
Не согласен, development удобнее вести методом Ctrl+Intert-Shift+Insert.
Кроме Go не нужно ничего знать. Там даже в версии 1.14 добавили принудительное переключение между горутинами — см. medium.com/...s-preemption-b5194227371c . Это уменьшает максимальные задержки в garbage collector’е до 10мс, что в 20 раз лучше, чем в Java.
P.s. Средние задержки в гошном gc и так были в районе десятка микросекунд еще с древних времен, что в 1000 раз лучше, чем в java.
Кроме Go не нужно ничего знать
Амінь.
Я раніше розробляв на PHP, зараз на Go, підтверджую розробляти на Go швидше, а в скільки разів це вже індивідуально
Там даже в версии 1.14 добавили принудительное переключение между горутинами
Ага, при этом внеся так незаметненько огромный breaking change:
A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases. This means that programs that use packages like syscall or golang.org/x/sys/unix will see more slow system calls fail with EINTR errors. Those programs will have to handle those errors in some way, most likely looping to try the system call again.
EINTR — это ожидаемое возвращаемое значение для многих системных вызовов. Если программа раньше не обрабатывала EINTR, то это баг в программе, который нужно исправить. Go 1.15 выявляет этот баг, что позволяет улучшить общее качество программ в долгосрочной перспективе.
Это не баг, если с более старой версией рантайма отсутствие обработки этой ошибки не мешало программе нормально работать. Неаккуратное программирование — возможно, но не баг.
Зато подобные фортели очень наглядно показывают отношение авторов golang к обратной совместимости. Нормальные люди сделали бы эту возможность опциональной, сознательно включаемой каким-нибудь флагом при компиляции. И вот тогда уже было бы логично ожидать от разработчика, сознательно включившего этот флаг, правильной обработки EINTR везде, где только можно.
хабра давным-давно уже не аргумент, там куча коммерческого вброса и статьей в стиле «привет хаброжители сильнонепинайте за первую статью как я не смог пересесть с венды на линукс», читаю его уже наискосок, то что там пишут в большинстве случаев лучше выбросить и забыть
«привет хаброжители сильнонепинайте за первую статью как я не смог пересесть с венды на линукс»
А что, есть какая-то потребность пересаживаться с венды на линукс? Зачем?
имелось ввиду бессмысленность и низкое качество контента постов на хабре, ссылка на который здесь приводится здесь как весомый аргумент
тоже смотрел когда-то.
пару книг полистал, потусовался среди пересевших
оценил как сложный, а значит не мейнстримовый.
Scala это как
ru.wikipedia.org/wiki/Ифкуиль
см Пример грамматической конструкции
ну или «С++» для JVM
потом уже были истории с поломками совместимости
потом услышал где-то пару раз, что компании выбирают ее как способ отсева соискателей
Основной аргумент: количество проектов на GitHub с более 1000 звездочек:
Вывод очевиден — Scala мертва, учите Go.
Let`s get ready to rumble;))
Go — 1407 звезд
за 5 лет так и не обошел java и даже близко не приблизился к js
JavaScript — 5,084 repository results
Java — 2,371 repository results
кто-то тут даже коньяк на это ставил — походу темпы роста го такие же медленные, как и язык. so sad
за 5 лет так и не обошел java и даже близко не приблизился к js
Так java за 5 лет не только что не приблизилась к js, но даже наоборот только отдаляется, с сокращением объёма разработки на джаве. Если аппроксимировать эту тенденцию, Go в дальнейшем обгонит java даже без развития языка и комьюнити.
Если аппроксимировать эту тенденцию, Go в дальнейшем обгонит java даже без развития языка и комьюнити.
Чего ж ещё не обогнал?
Зато за последние 5 лет Go обогнал следующие языки программирования по количеству популярных проектов на GitHub: C++, PHP, C, ObjectiveC, Ruby, TypeScript.
Go уже обогнал Java по количеству активных популярных проектов в текущем месяце: 336 проектов на Go против 332 проекта на Java.
-В джаве есть уже лямбды, оптионал, добавили вары итд. Ейвсе еще очень далеко до всех фишек скалы, но некоторые базовые вещи можна пилить.
-В джаве, как по мне уже устоявшийся костяк набора либ, фреимворков, и альтернатив фреимворков, более мение подруженных между собою. В скале какойто полный зоопарк всего и вся, плохосовместимого, и с кучей депенденси на непонятно что.
-разные версии компилятора, плохо совместимого между собой, что в купе с предедущим пунктом доставляет.
-sbt — no comments.
-в скале можна писать кучей разных стилей, используя разные подходы и наборы фичь языка. Еслиодин проект пишеться в разных стилях — черт потом ногу сломит. Для успеха требуеться оч жосские код конвеншены, суровый ревью итд, и даже оно — не помагает :-)
-не осиляторство. Народ тут не в состоянии разобраться с парочкой простых ооп паттернов, и кричит что ооп не нужно. Но на деле фп на порядок сложнее ооп. Куда проще кричать что Го крутой языг итд.
-не осиляторство. Народ тут не в состоянии разобраться с парочкой простых ооп паттернов, и кричит что ооп не нужно. Но на деле фп на порядок сложнее ооп. Куда проще кричать что Го крутой языг итд.
Вертайся в сім’ю, в той топік. Нафіг ті фабрики і візітори, одного сінглтона досить, якщо його не обзивати сінглтоном. Інкапсуляції више криши хватає для безпенішого програмування, нафіг там наслідувати єнота від собаки з мавпою.
нафіг там наслідувати єнота від собаки з мавпою.
Ну да, каждый Гошник каждый раз велосипед изобретает, и копи-пейст юзает, мывкурсе.
Вертайся в сім’ю, в той топік.
Тут речь о другом. Лет 10 назад неосиляторы распространяли миф о том какое сложное ооп, и как фп спасет отца. Но в прадакшене они ударились головой о стену из теории категорий, и ща кричат что фп оцтой, только Го.
Причём тут ФП vs ООП, Go сочетает все подходы, а не фокусируется только на каком-то одном. Поскольку при разработке языка учтён практический опыт программирования на других языках, это результат эволюционного развития. Тем более, что разработан язык не какими-то
В языке убрали всё лишнее
ога, особо это забавляет когда приходиться писать копипастить очередной contains для массива слайса или другую подобную дичь, которая есть в любом нормально ЯП...
В нас в проекті є мікросервіс для збереження статистики, який отримує дані через gRPC, зберігає в slice-буфери та пачками по 10 000 зберігає в ClickHouse, написаний на Go і ось ці всі slice-буфери під кожну proto-структуру це copy-paste
Copy-paste для contains чи інших простих алгоритмів це прикро, але й рідко таке пишу, я б з радістю перейшов на Rust, але вже звик що на Go швидко проходять тести та build проекту
Відповідно є можливість розробляти малими ітераціями та швидким запуском тестів, і інколи робити copy-paste, що для мене переважає над довгим запуском тестів який в Rust чи C#
Причём тут ФП vs ООП, Go сочетает все подходы
В Go уже завезли каррирование без костылей? Дженерики туда тоже всё никак не завезут, кстати, а без них даже элементарные map / filter / reduce требуют извращений с кодогенерацией под каждый тип, на котором нужно реализовать эти операции.
Тут речь о другом. Лет 10 назад неосиляторы распространяли миф о том какое сложное ооп, и как фп спасет отца. Но в прадакшене они ударились головой о стену из теории категорий, и ща кричат что фп оцтой, только Го.
о дааа
моя улюблена історія, як Пол Грем наваяв Yahoo Stores на Lisp
а потім то треба було саппортити, коли їх вже не було, та й переписали то все нахрін на C++
бизнесу пофиг на осиляторов и неосиляторов, им нужен адекватный продукт за адекватные деньги.
Прошу помочь окончательно развеять мимолетное, так ни во что не вылившееся и уже ни к чему не обязывающее очарование, указав на1-3 основных аргументов почему этот ЯП «уже не торт». :)
Потому, что есть Kotlin, создатели которого, насколько я знаю вдохновлялись скалой (и вроде одна из идей котлина была сделать что-то типа «Scala для простых смертных»), который не настолько сложен, как скала (может даже проще джавы), и который похоже таки взлетел, в отличие от скалы. :-)
Правда это не означает, что скала «уже не торт», просто скала узконишевый язык, насколько я понимаю.
Тут в соседнем топике камрады накинули
blog.usejournal.com/...reads-part-2-52611217340a
Go: 732.204 total requests over 5 min, 2,439.9 r/s
Node (cluster module): 1,116,477 total requests over 5 min, 3,720.65 r/s
Node (worker threads): 1,105,513 total requests over 5 min, 3,683.90 r/s
Я считаю, топик можно закрывать.
ключевая фраза всей статьи там в самом конце:
I’d like to point out that I am not a professional benchmarker
Та ну... То треба бути «професійним» задротом, щоб комусь щось доводити... ))))
Т.е. чтоб показать, что Го не сосет у ноды нещадно, вам надо какой-то специальный эксперт по бенчмаркам? :)
Суть сравнения сводится к скорости интерпретации V8 против исполнения откомпиленного Go-кода. Что ещё там сравнивать?
После того как откомпиленный Go слился интерпретатору JavaScript, я не знаю что еще можно сравнивать :)
в инете много тестов
результат этого — нетипичный для Go vs Node.js
но что правда, у V8 очень крутой JIT, как для языка с динамической типизацией
Все просто, Node.js зміг розпізнати патерни і оптимізувати код і алгоритми, а Go як побачив так і виконав, і є відмінності в коді
Забавно, но компиляторы с функцией оптимизации придумали еще в
Go хейтер не смог даже нормальных тестов написать. Допустил ошибку в bubble sort и не выделил память под возвращаемые массивы. В итоге бенчмарк показал, что js умеет немного быстрее ресайзить массивы по сравнению с Go. Также стоит обратить внимание на экпоненциально возрастающую сложность кода в nodejs с увеличением его размеров. И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.
В проде программы на Go работают в десять раз быстрее программ на nodejs, при этом их код остается простым и понятным при любом размере программы, а количество багов в нем в 100 раз меньше, чем в nodejs программах.
И это мы еще не добрались до ахилессовой пяты nodejs — callback hell’а при работе с БД и сетью.
Да, еще есть люди, которые не раздуплились как готовить async/await в ноде, но это прийдет со временем.
Боюсь, что процент людей, способных правильно использовать async/await, примерно равен проценту людей, способных правильно использовать callback’и и писать на Rust. Т.е. он стремится к нулю, в отличие от 100% людей, которые умеют правильно использовать горутины в Go.
Так же как и процент людей, способных программировать вообще, очень низкий. Остальные идут в работать продавцами.
посмотрел код, никак не оформлен толком и сам http server неправильно заюзан, чтоб реквесты конкуррентно обрабатывать, формошлепы с ноды не осилили нормально бенчмарк написать по концепциям Го
Бачу, є люд, яким абичим помірятися... вдавляться за 10мс )))
Так між ними багато спільного, видимість на рівні пакету, вбудовані тести та автоформатування коду, передача error та panic, відсутність OOP
Кто не читал, общая суть в том, что у чуваков внезапно возникла попаболь из-за работы GC в Go. К слову, та же попоболь у них возникла бы и в любом другом языке, где есть GC, и всё равно как ни крути, от сборки мусора не избавиться. И поэтому они кардинально решили проблему с GC путём перехода на Rust. Ну а то, что там нет встроенной многопоточности — ну и что, не возвращаться же обратно на Go.
К слову, та же попоболь у них возникла бы и в любом другом языке, где есть GC,
ребята уточнили, что аллоцировали минимально и размер heap у них почти не менялся в рантайме, а в go gc такой тупой, что каждый 2 минуты сканил весь хип и вешал апишку и это нельзя было никак поменять. В других языках Gc тригерит загрузка памяти, поэтому такой проблемы бы не было.
Я тут посмотрел один сервис, которые без особой нагрузки работает ровно 2 дня, совокупное время работы GC за всю сессию составляет около 37 миллисекунд — это всё что требуется для 1460 таких сканов.
Дай угадаю — ты посмотрел это для stateless сервиса vs statefull описанный в статье. :) статью наверняка тоже внимательно не читал.
Ребята еще уточнили, что успользовали древнюю версию Go, где GC был не так хорош, но забыли уточнить, чем им не подошла последняя версия Go с намного лучшим GC. В это же время им ничто не помешало использовать bleeding edge версию Rust в проде, которая даже еще не релизнулась.
но забыли уточнить, чем им не подошла последняя версия Go с намного лучшим GC.
We tried versions 1.8, 1.9, and 1.10 without any improvement. The initial port from Go to Rust was completed in May 2019.
И судя по release notes, после 1.8 значительных изменений в gc не было.
medium.com/...6ecbd62a4b/responses/show
Якщо подивитись уважніше коментарі, то вони мова про go1.9 трьох річної давнини, баг з смітников виправили/
Если почитать внимательнее, то это события 2х летней давности, и к выходу 1.12 на rust уже почти переехали. Кроме того, учитывая
we were able to beat Go on every single performance metric.
возврашаться на go было бы весьма странно.
в ленте не могу коментить, поэтому оставлю здесь
imgur.com/a/03KQGOY
Вставлю свои 5 копеек по поводу годных языков программирования
Как по мне для сервера самый крутой выбор на сегодня «с запасом» — Kotlin, Python ну Node.JS для микросервисов
www.youtube.com/watch?v=ShX4KFvhiX0
2019 год подходит к концу, а Go стремительно летит вверх и догоняет Java по количеству звезд на гитхабе. Scala лежит на дне.
Валялкин, когда обещанное отдадите?
Или адепты «вяликого» Go на самом деле настолько нищие, что не могут одну бутылку купить?
Приходь на Go мітап, там таке питання задасте
Приходь
задасте
Щось тут не стикається.
Приходь на Go мітап
Побачу хоч одну цікаву доповідь в планах — подумаю.
Поки що шансів замало.
Самое удивительное, что у Dart почему-то получился большой рост, несмотря на то, что Google на него положила болт, и не встроила виртуальную машину в chrome. Ну а Go уже на
Достаточно вакансий, даже при том, что есть немало случаев, когда проекты вынуждены тащить чемодан без ручки в виде поддержки старых никому не нужных на сегодняшний день технологий.
Самое удивительное, что у Dart почему-то получился большой рост
тому що flutter
несмотря на то, что Google на него положила болт
Если бы гугл на него положила болт, то не было бы Dart 2 и Flutter’а, а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт.
а виртуальная машина дарта в хроме ИМХО нафиг не нужна, ибо зачем, если дарт вполне компилиться в джаваскрипт
Так смысл Дарта изначально был в виртуальной машине. А если его компилить в js, то лучше сразу просто писать на js. Или на ts.
А если его компилить в js, то лучше сразу просто писать на js.
Дейсвитейльно)) А то понаписывают разных языков, компилируемых в js — github.com/...guages-that-compile-to-JS — вместо того, чтобы сразу писать на js)
Или на ts.
Так ts тоже лишний получается, ибо «лучше сразу писать на js». :-)
github.com/...guages-that-compile-to-JS
Я в этом списке даже Go нашёл. Причём самый впечатляющий вариант — TARDISgo, компилящий golang в Haxe, а с него в js. Впрочем, с Haxe можно отомпилить ещё в C++ и php например, не только в js, а потом другими тулзами обратно в Go. И так по кругу.
Победа! Go обогнал Java в 2020 году — madnight.github.io/githut/#/stars/2020/4 . Впереди остались Python и Javascript. Про Scala уже все забыли.
Проекты на javascript лайкают любители тормозных и неудобных в использовании ангуляров с реактами, а также любители школьного поделия под названием nodejs и гигабайтных папок node_modules
js можно не сравнивать, поскольку он занимает монопольное положение на фронтэнде, из-за принятых в прошлом неоптимальных решений. Могли бы на фронтэнде принять стандарт на байткод, и писать фронтэнд на более толковых языках. Всё равно там занимаются такой фигнёй как минификация кода.
Я просканував свій жорсткий диск і бачу чітку перемогу С++. Java на другому місці, Go взагалі нема.
Акуратно підбираєш де сканувати — і маєш перемогу чого завгодно над чим завгодно.
Why Generics?
blog.golang.org/why-generics
ПС Дженерікам — бути... але це не точно..;))
My Reasons to Consider Go Coming from Java
preslav.me/...ider-go-coming-from-java
P.S. Let’s get ready to rumble)))
Next steps toward Go 2
Как скрестили PHP с Go и получили RoadRunner — blog.spiralscout.com/...meant-to-die-830de87915ee
Я знаю спеціалістів які перейшли з PHP на Go, з Python на Go, Java, Ruby, DevOps, але жодного хто перейшов з C#, такі взагалі є? (читав коментарі в цій темі по C#)
Так, моя поточна контора заснована сішарперами, які звалили на го. Тепер гошний код дуже сильно пахне сішарпом, кругом IWeirdInterfaceNamings, longVariableNames і тому подібне.
Исправить не пробовали нейминги в команде? Или код на го хороший даже если он с запахами?
Або налаштувати github.com/golangci/golangci-lint замість тисячі мітингів
Так налаштовано же. Там все по стандартам окрім кількох маленьких але досить баттертних відхилень :-)
Всі звикли, тому припікає переважно лише у мене. А кодобаза огого, щоб все міняти.
PHP на Go, з Python на Go, Java, Ruby, DevOps
вот это и есть примерно целевая аудитория
Go 2018 Survey Results
blog.golang.org/survey2018-results
Що краще — Го чи Зеленський?
Go конечно же) Ибо он няшка blog.golang.org/gopher/gopher.png :-)
Пишу вам з майбутнього.
Все що завгодно краще за Зеленського.
2% идентифицируют себя как neurodiverse, это интересно как?
Grab переходит со spark’а на go — engineering.grab.com/...ormation-product-insights . Выводы — spark никому не нужен, spark тормозит разработку, spark тормозит в продакшн, spark постоянно глючит, scala — мертва. Да здравствует Go!
After revamping the system, the elapsed time for a single event to travel from the gateway to our dashboard is about 1 minute. We also fixed the data loss issue. Finally, we significantly reduced our on-call workload by removing Spark Streaming.
Spark не нужен там , где его не используют
After completing the MVP phase development, we noticed the Spark Streaming functionality we actually used was relatively trivial.
Было бы там что-то сложней 2+2 ,а именно какой-то СЕP, boilerplate язык по типу го никто не рассматривал даже.
Лучше выяснить кому нужен язык, где надо ждать major релиза, что бы добавили функцию sort slice. Spark он собрался покорять.
Ти таким повідомленням вирішив підняти рейтинг Go? після малого падіння із-за теми Продам книги по GO
Це не тільки я вперше почув про компанію Grab?
Апну-ка я темку следующим:
Решил поискать я на гитхабе разные интересности в плане новых языков программирования (вот просто стало интересно, что новенького придумали в этом плане), и наткнулся на вот такой любопытный язык, по синтаксису и идеологии (как мне кажется) очень смахивающий на Go:
github.com/odin-lang/Odin — оффициальный репозиторий
odin.handmade.network — оффициальный сайт сего чуда, с туториалом odin.handmade.network/wiki/3329-odin_tutorial
Интересно, как оценят гоферы (и им сочувствующие), ну и анти-гоферы соответственно сие творение рук программерских)
Прочитал 2/3 тюториала, было стойкое впечатление, что это форк с Go, но потом выяснилось, что никакой не форк, поскольку нет многих ключевых вещей из Go. Прежде всего нет концепта параллельного программирования с горотинами, а вместе с этим отсутствует и смысл использования этого языка. Нет интерфейсов и утиной типизации. Нет вообще какого-либо концепта ООП. Нет GC, судя по всему память управляется только вручную. Тема замыканий и передачи контекста — проигнорирована. В целом синтаксис удобный, но проект явно сырой, чтобы на нём что-то реально делать.
Так а что страшного то в тех строчках которые приводят в той статье? Обычное же ФП без особой жути — монады и монад трансформеры, higher kinds. На самом деле в ФП гораздо больше злой дичи, чем там написано.
Всё дело в том, что есть набор людей типа:"Я знаю спринг и ООП с паттернами головного мозга, а всё остальное ересь«(те самые которые опшенел используют только для того чтобы проверить его на isEmpty, и на коллекциях вместо мапов используют циклы, траи кетчи во все поля) и начинают пилить декоракторы абстрактных фабрик бинов, а когда встречают ОФП или не дай бог ФП у них случается жуткий когнитивный диссонанс и резкое нежелание сесть и потратить некоторое количество вечеров на самообразование.
Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.
На самом деле, скала предоставляет множество плюшек для безопасности, структурирования и упрощения и повышение читаемости кода, но только если её не использовать как джаву с синтаксом скалы и не спамить всеми модными фичами(в особенности имплиситами).
Соблюдение базовых концепций (типа прочь вары и мьютабл коллекции, мапы/флатмапы/фолды вместо циклов, айзер/трай-монада для обработки ошибок вместо тысячи траев ифов и кетчей, возвращаемое значение функции вместо throw execpetion, скальные библиотеки вместо джавных(спринг, EE, и всё остальное), применение неявных(implicit parameters) только по назначению(реализация тайп-классов, пробрасывание «контекста» в функцию), жёсткая разбивка функции-преобразования над данными и собственно сами данные) делает код гораздо чище, проще, прозрачнее и короче чем джавный и традиционный ооп-шный способ писать код.
Просто скала, как и любая достаточно продвинутая технология(покопайтесь в голове чего есть в кишка спринга интересного и подводнокаменного, я думаю что его там тоже немало) требует понимания основных принципов её функционирования. Здесь есть ещё наложение того, что принципы немного отличаются от тех, которыми пользуются в Java и других ООПшных языках.
Вот и получается что люди пологают, что их привычные ООПшные принципы без никакой рихтовки годятся для применения к Скале и кричат: Ниасилил!
Вы тут перечислили кучу детских болезней, возникающих у начинающих разработчиков, особенно если они травят свой мозг программированием на scala. Ваша задача — достигнуть результата, за который платят деньги, а не заниматься реализацией всех имеющихся возможностей вне зависимости от их необходимости. Конечному потребителю нет никакого абсолютно дела до красоты в вашем понимании вашего кода. Так что бросьте заниматься ерундой, займитесь лучше программированием. На Go.
Бросьте тыкать в кнопочки и займитесь действительно нормальным нужным и полезным делом — приготовлением пиццы, например.
Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.
Ну вы знач умный. Я писал на карлючках продакшн код два года, это былого недостаточно чтобы понимать фп концепции и уметь читать код. Особенно не код вылизанного математического катс, а тот который в продакшене, и его какойто другой умник написал. Грамотный спринг значительно легче понимать.
ООП с паттернами головного мозга, а всё остальное ересь"(те самые которые опшенел используют только для того чтобы проверить его на isEmpty, и на коллекциях вместо мапов используют циклы, траи кетчи во все поля) и начинают пилить декоракторы абстрактных фабрик бинов, а когда встречают ОФП
Та булшит, нормальный народ вполне умеет в джаве стримами меп, фильтр и прочее делать. А народ который пилит декоракторы абстрактных фабрик бинов, он и на фп напилит таглесс-файнал апликативную клайсли композицию. Ток с декоракторами абстрактных фабрик бинов любой гошник за пол часа разбереться, а с таглесс-файнал апликативной клайсли композицией даже чсв Головача не хватит.
Ниасилил дочитать этот поток бреда. Теперь понятно, почему Scala пробила дно и продолжает копать вглубь в то время, как все давно пишут на Go.
Кажіть виключно за себе. Ваша маргінальна тусовка не «всі»
Scala — первый мой язык промышленного програмирования, и мне потребовалось всего месяц чтобы осилить стрелочки-карлючки и import cats.data.cokhrenoid и научится понимать базовые ФП-концепции, которых достаточно для чтения кода.
и мне потребовалось всего месяц
всего месяц
ліл
Це ж який елітизм треба мати, щоб тішитись високому порогу входу? Просто на теперішній роботі я не раз ставав свідком того, як народ з нуля за день-два починав писати адекватний Го. Звісно не зразу ж всі продвинуті фішки, але загалом без проблем.
Примітивізм мови не каже про її якість
Go 1.12 is released...
blog.golang.org/go1.12
golang.org/doc/go1.12
Здорово, теперь меньше времени осталось ждать до выхода Go 2. Ещё только 1.13 обещали выпустить.
Та я вже, навіть, не знаю, чи дуже чекаю я на Go 2.0...))))
Мене там все влаштовує для моїх потреб...
Так що спостерігаю, шоб не «покращили» ..))
Не можу не погодитись...
„Go, the Programming Language of the Cloud”
thenewstack.io/...ng-language-of-the-cloud
Признавайтесь, чей вопрос на quora про scala и go? www.quora.com/...mplex-language-like-Scala
Не признаються...
Навіщо їм такий камінгаут?! ;))
отлично сказано: „I feel like an idiot when programming in Golang ”
Все не так, як Вам хочеться бачити..;))
Цікаво, що пан/пані з Quora не скаржиться на функціонал та можливості Go... а саме на свої відчуття..)
Це певно когнітивний дисонанс: думаю, він має можливість робити те ж саме, але з меншою кількістю померлих нервових клітин..;))
И ниодного ответа от тру-скалиста.
Какой инструмент — такие и задачи.
Читати всім уважно.. ;)))
tip.golang.org/doc/go1.12
Не напружуйтесь так...
Це тільки для справжніх поціновувачів..))
ти кажеш
Читати всім уважно
а потім
Не напружуйтесь так...
нє надо так
www.netlore.ru/...b2hbe1tk0h4717ujsc3u.jpeg
«не напружуйтесь» — це зовсім не образа... це, скоріше, турбота..)))
Мабуть дженеріки з ексепшинами підвезли.
свежеизобретенных велосипедов подвалило
К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal
придется пересесть на какой-нибудь Crystal
oy gevalt!
crystal-lang.org/...d_semantics/generics.html
такі може колись до вас дійде, що дженеріки — це інструмент для спрощення життя програміста, а не культ карго «аби було»
Дженерики — зло, т.к. они усложняют понимание кода. И они реально карго культ. jmoiron.net/...n-the-go2-generics-draft
Дженерики — зло, т.к. они усложняют понимание кода.
Це правда. Але правда і те що джереніки спрощують розуміння коду, роблять його коротшим і додають ще один механізм повторного використання. Але в го чомусь вирішили обмежитися копі-пейстом.
Дженерики — зло, т.к. они усложняют понимание кода.
Це правда.
Не правда. То не вы, не ваш оппонент, не видели языков, где генерализация вшита в компилятор по умолчанию.
Всі оці невидимі мови де щось там зроблено набагато краще ніж у мовах якими справді пишуть великі і складні речі мені не дуже цікаві просто.
не видели языков, где генерализация вшита в компилятор по умолчанию
наприклад?
дійсно цікаво
Мабуть дженеріки з ексепшинами підвезли.
К счастью, не подвезли. Будем надеяться, что никогда не подвезут. Иначе придется пересесть на какой-нибудь Crystal
.
(Щоб не загубити цей діалог. xD )
Go-программистам больше всего платят — jaxenter.com/...l-dice-report-155332.html
Помню пару лет назад пейсатели на джаве сильно переживали по поводу того, что Go будет демпинговать великих энтерпрайз-разаработчиков. А сейчас как видим, нищающие джависты только и могут, что демпинговать Go-девелоперов.
Что там та Java, вон обошли PaaS и rabbit mq программистов даже — это определенно вершина мира.
Оригінал тут — marketing.dice.com/..._TechSalaryReport2019.pdf. Варто зауважити що там нічого нема про Go-програмістів. Натомість мова йде про skills серед яких golang популярний запит у роботодавців на Dice. Серед інших популярних Kafka, амазодновські БД і таке інше.
Поздно оправдываться — пора смириться и переучиваться с your_language_here на Go, а не то будет поздно.
переучиваться с your_language_here на Go
Для чого переучуватися якщо можна просто знати/вміти Go на додачу до інших скілів? Чи у гошників знання чогось за межами Го це щось нечуване?
Go опередил Elixir и Node.js — stressgrid.com/...ing_go_vs_node_vs_elixir . Scala не участвовала, т.к. очевидно, что она бы заняла последнее место.
В 2019 году программисты больше всего хотят изучать Go — zdnet3.cbsistatic.com/...019-01-29-at-11-25-51.png .
Я б написав так: «В 2019 році й надалі...» ;))
А де про саме опитування — хто, коли, де, кого?
Ага, тобто 35 тис. користувачів HackerRank заповнили форму з якої і склали ці діаграмки.
Ура! В go1.13 добавят три супер-крутые фичи! Go станет еще совершеннее, а у хейтеров большне не останется аргументов против Go!
Тобто, ти визнаєш, що поточна реалізація далека від ідеалу?
Єдність і боротьба протилежностей — ідеальна мова без недоліків та проблем недоліки та проблеми якої будуть виправлені у наступній версії.
Це зовсім не те що Java чи С++ якісь де все і так не ідеально, а нові версії та стандарти потрібні щоб зробити все ще менш ідеально.
Это збс! Добавляют дженерики и исключения. Через несколько мажорных версий дотянет до C# 2.0 по функционалу.
Ти ж розумієш що цим себе тільки підставляєш? :)
Вышел короткий нескучный драфт по Go 2.0
www.youtube.com/watch?v=U84zvGbk_CY
ждём релиза в следующем году
Классная страничка про свитчеров с разных языков программирования на Go — github.com/golang/go/wiki/FromXToGo .
Отлично, двадцать человек перешли на Гоу (ты, я так понимаю, один из них). А вот сакцес стори тех, кто переходит с Го обратно нет — ибо возвращаются втихаря, чтоб оставшиеся гоубои не заклевали предателей.
Что значит переходят с Go обратно? Те, кто туда попадает, обратно уже не возвращаются.
Возвращаются, только не оповещают об этом весь интернет.
Все мы знаем, что дельфины спасают утопающих. Однако, выясняется, это не так. Дельфины просто играют с утопающими, подталкивая их. Те, кого дельфин толкал к берегу, утверждают, что он их спас. Те же, кого дельфин толкал от берега, уже ничего не скажут.
©
Все мы знаем, что дельфины спасают утопающих. Однако, выясняется, это не так. Дельфины просто играют с утопающими, подталкивая их.
На самом деле поскольку дельфины дышат воздухом, а детёныши часто захлёбываются, у них принято толкать утопающих к поверхности. Вот и Go даёт глоток свежего воздуха в океане говнокода на всеми уже забытом scala и прочих подобных языках.
Пошкодження необоротні і надій на зцілення нема?
Go уверенно движется вверх как танк. Уже на третьем месте и скоро обгонит Java. Scala пробила дно и продолжает копать вглубь.
По-перше, на четвертому. А, по-друге, це статистика по проектах на github.
По-перше, на четвертому.
Значит, скоро будет на третьем месте.
А, по-друге, це статистика по проектах на github.
Что еще кроме github можете порекомендовать для репрезентативной статистики?
Значит, скоро будет на третьем месте.
Або на п’ятому, або залишиться на четвертому, або не скоро.
Что ... можете порекомендовать для репрезентативной статистики?
tiobe — купленный индекс. Там vb.net на первых местах.
tiobe — купленный индекс.
Ким, для чого?
Мелкомягкими)) Бейсик продвигать — очевидно же. :D
Ага, як же я забув що воно так і працює — дивишся з ранку що там на перших місцях у купленому рейтингу і починаєш переписувати усе найпопулярнішою мовою. Завжди так роблю.
tiobe — купленный индекс
нагадаю — ще рік тому він був не такий вже і куплений :)
dou.ua/...rums/topic/16012/#1145324
В этом году гугл выделил меньше денег на раскрутку Go, вот и не получилось купить первое место в tiobe индексе
Так а для чого ж там купляти місця? Може я щось роблю не так в своєму житті і мені теж треба там місце прикупити?
Как и ожидалось, Go уже на третьем месте — madnight.github.io/githut/#/stars/2020/4
Ну гітхаб то специфічна метрика — там багато хоббістських проектів і дуже мало enterprise коду, який якраз і складає левову часту IRL розробки.
Але загалом прикольно!
Go перегнав Java — абалдєть.
Що сталось в 2018, що PHP так виріс? Тобто не інші просіли, а PHP саме виріс з 4% до 7% — майже в 2 рази. Але схоже, що народ швидко просік, що PHP таки гімно і за пару місців забили на нього :).
Вони там самі посилають на індекс TIOBE, який не обмежений гітхабом і як і очікувалося місця там дещо інші — tiobe.com/tiobe-index.
Гітхаб цікавий якраз тим, що там багато хоббістських проектів. Тобто прикольно, що народ, «для себе» обирає Го, а не Яву. Тобто враховуючи, що більшість працює на Яві і постійно на ній практикуються, вони всерівно приходять додому і беруть або Го або пітон або, прости Господи, js.
Я, наприклад, знаю (однаково поверхнево) і можу використовувати кілька мов програмування: C++, Го, Яву, Пітон, C#, JS/TS. Але якщо мені теба щось швидко склепати або почати з нуля, то я не думаю, що візьмусь за Яву або C#. Якийсь МЛ буде на пітоні в jupyter ноутбуці, говносайт для розмітки даних був на пітоні на фласку (там фронтенд навіть без JS — чистий html, а бекенд навіть без баз даних читає/пише тупо csv файли), якісь змагання я досі пишу на C++, більш довгостроковий сайт був на бекенді на Го, фронтом на React’і з TypeScript’ом...
А от Яву/C# прийшлось використовувати тільки коли по роботі треба було написати FIX клієнт: для цих двох мов є афігенні бібліотеки для роботи з FIX’ом (quickfix/j, quickfix/net, quickfix/go не пропонувати — жахливо, в порівнянні з попередніми двома).
(quickfix/j, quickfix/net, quickfix/go не пропонувати — жахливо, в порівнянні з попередніми двома).
Мав на увазі, що QuickFIX/J і QuickFIX/n ок. А от QuickFIX/Go — люте гівно.
На третьому. На гітхабі. За четвертий квартал
Це типу як я самий швидкий на 5 км. На моїй вулиці. За останній місяць.
любителей goвнокодить все больше и больше
Любители говнокодить преходят со Scala на другие эзотерические языки программирования типа Rust и C++.
бутстрап гоу на чем написан?
Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?
Если посмотреть на количество доставленного кода
madnight.github.io/githut/#/pushes/2018/3 то не всё так радужно для Go
Вы привели в пример рейтинг «звёздности». Что он отражает? Хайповость технологии?
О хайпе на фоне успеха можно говорить только для созданной в последние месяцы, максимум пару лет какой-то теме. Go развивается уже десятый год, и при этом с каждым годом, как мы видим, его популярность бьёт все мыслимые и немыслимые рекорды. Поэтому здесь можно говорить не о хайпе, а об невероятном прорывном языке, о феномене не имеющем в мире никаких аналогов, имя которому только одно — Go.
Мало эпитетов, добавлю: квинтэссенция человеческой мысли, венец цифровой индустрии в котором собраны наилучшие практики со времён Ньютона, качественно новый уровень и веха грядущего миллениума, сниспосланная пресвятейшим (кто там его сделал), луч света в тёмном царстве IT ... и другие штампы.
Ничего не имею против go, но слишком «сладко».
Мало эпитетов, добавлю: квинтэссенция человеческой мысли, венец цифровой индустрии в котором собраны наилучшие практики со времён Ньютона, качественно новый уровень и веха грядущего миллениума, сниспосланная пресвятейшим (кто там его сделал), луч света в тёмном царстве IT ... и другие штампы.
Вот-вот-вот, сразу видно, вы уже постигли дзен. Прислушайтесь все к мнению гуру.
У go малое количество git push’ей, т.к. хороший код на нем получается с первого раза, в отличие от остальных языков программирования, опередивших Go в этом рейтинге.
т.к. хороший код на нем получается с первого раза
На будь-якій мові гарний код виходить з першого разу. Ви тільки його нікому не показуйте.
хороший код на нем получается с первого раза
Це доволі таки іронічно враховуючи що сам го добре ні з першого, ні з наступних разів так і не получився.
Це доволі таки іронічно враховуючи що сам го добре ні з першого, ні з наступних разів так і не получився.
Понимаете, есть вещи плохие, есть хорошие. А есть идеальные в своём совершенстве, и думаю излишне будет напоминать, что речь идёт тут о Go.
хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?
хотів уточнити: ми все ще говоримо про інструмент із назвою Go, який використовується для написання програм?
Конечно. Не об игре же Go, хотя она тоже может примазаться на фоне популярности к великой славе golang.
Мені якось goto більш досконалим здається ніж go.
Мені якось goto більш досконалим здається ніж go.
Go в два раза короче, чем goto, а краткость — сестра таланта.
краткость — сестра нашего брата ©
Всьо, переписую термінову все на го!
У go малое количество git push’ей, т.к.
никто не может довести код до состояния, когда его не стыдно пушнуть
что бы еще больше помогло го так это менее всратое комунити :) Язык то норм я на нем переодически пишу но блин
что бы еще больше помогло го так это менее всратое комунити :) Язык то норм я на нем переодически пишу но блин
Я конечно понимаю, что в силу природной скромности, вы не можете открыто и честно написать, что гордитесь комьюнити Go, поскольку и сами в него входите. Но не нужно перегибать палку в этом, мы ведь и так всё понимаем. Лучше честно и объективно написать всю правду, какой бы она ни была, что комьюнити Go самое продвинутое, самое достойное, куда входят лучшие представители хайтека.
А говорили, что никогда в жизни не перейдете со Scala на Go, что Go — никудышный язык программирования. Этот топик даже открыли, чтобы поглумиться над ниасилившими Scala. А теперь сами на Go пишете :) Epic fail!
я не говорил что не пересяду, я глумился над проблемами неосиляторов- это таки разные вещи :)
На го я пишу прототипы на выброс если чесно, продакшен код я не пишу ни на одном языке сейчас ( не знаю хвастаюсь или жалуюсь- что то посредине пожалуй).
Оба комунити имеют свои проблемы
— в скала — всратые элитисты которые пытаються прирутрить монадки куда не попадя ( не всегда к месту бгг).
— в го — всратые пионеры верящие что го лучший язык со времен каменного топора
примерно так
— в го — всратые пионеры верящие что го лучший язык со времен каменного топора
На самом деле Go появился задолго до изобретения каменного топора, и с тех пор неуклонно двигает человечество к вершинам научно-технического прогресса. Если внимательно присмотреться на наскальные рисунки первобытных людей, станет ясно, что это код прототипа Go.
а скіфські кам’яні баби — це, насправді, намагання наших предків увіковічнити Go Gopher-а!
одно плохо — скифских мужиков с огромными пиструнами не сохранилось, иначе всем было бы понятно как оно от го удлинняеться
а шо каже тьобе?
www.tiobe.com/tiobe-index
Jan 2019 Jan 2018 Change Programming Language Ratings Change
1 1 Java 16.904% +2.69%
2 2 C 13.337% +2.30%
3 4 change Python 8.294% +3.62%
4 3 change C++ 8.158% +2.55%
...
16 19 change Go 1.115% -0.45%
Rob Pike
Go 2 Draft Specifications
www.youtube.com/...continue=21&v=RIvL2ONhFBI
кстати Го обогнали почти во всех кейсов джава www.techempower.com/benchmarks
единственное исключение это plaintext — что как по мне даже не должно быть там ибо в жизни оно никому не надо.
Сильно просела на TIOBE. Нишевый язык в нише с высокой конкуренцией.
У нашей галеры позиций больше тоже нет. Back to springhebirnate.
Ну це просто у Вашій галері Scala «всьо». А в Spark-спільності й області сучасних рішень для Big Data планів міняти пріоритетну мову зі Scala на щось інше ніби нема. :-)
В больших конторах, которые были драйверами скалы, тоже от нее отказываются.
Linkedin который очень активно продвигал скалу несколько лет назад свернул все и весь новый код пишет на джаве.
Дата сайентисты с удовольствием используют pyspark
Хм.
Современный джаваскрипт это глоток свежего воздуха после java8, это имелось в виду?
У Data Science все зрозуміло: research, вибір моделей, навчання, валідація не залишають часу, щоб ще вчити складну мову програмування.
Збираюся через місяць на Spark+AI Summit Europe 2018 у Лондон. Переглянув на днях відео деяких доповідей із Spark+AI Summit 2018, який був у Сан-Франциско — шматків коду на слайдах майже нема, але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.
Я думаю, що там, де треба швидко набирати багато Big Data програмістів і вже писати код, будуть старатися використовувати Java. Як і в компаніях, які просто не можуть дозволити собі найняти досвідчених розробників з фінансових причин. В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java. Що не заперечує, що в деяких інших областях Java є кращим вибором.
але там, де вдалося знайти, є Scala. Наприклад, доповідач з Google.
И где там скала ? О том как ранить спарк на кубернейтсе (довольно полезная в своей области тема).
В інших випадках писати Big Data проект на Scala ніби має більше переваг, ніж на Java.
Рельное преимущество , это в среднем, челы которыйе знают скалу, или которые сами по себе желают выучить скалу — имеют уровень и мировозрение больше чем среднестатестический джава-индусы. Все остальное размываеться с каждой новой версией джавы.
Якщо подивитеся на відкриту web-сторінку, яка є у тому відео, то побачите ALS.scala і MovieLensALS.scala. ;-)
Так, за рахунок вищого порогу входу рівень середньостатистичного скаліста вищий, ніж середньостатистичного джавіста, і нові версії Java все більше переймають від Scala.
Позиции конешно есть, но както оно уже не так бодрячком, как было пару лет назад. С одной стороны питон в спину дышит, с другой — собственно джава. Да и сам спарки, не то чтобы безусловный лидер — конкуренции у него с головой хватает.
Spark’ом пользуются только две группы людей:
1) у кого мало данных и им пофиг, с помощью чего их обрабатывать
2) у кого мало мозгов, но много денег, чтобы тратить over $9000 на тормозное и жрущее память решение задачи на spark вместо того, чтобы решить эту задачу за $10 с помощью go + clickhouse
решить эту задачу за $10 с помощью go + clickhouse
Тепер я розумію Богдана в якого від вас підгорає! :)
Кто такой Богдан и почему у меня от него подгорает?
Вот выдержка из интересной статьи, сравнивающей производительность clickhouse vs spark:
Yandex ClickHouse is an absolute winner in this benchmark: it shows both better performance (>10x) and better compression than Apache Spark
Кто такой Богдан
автор джава-дайджестів
почему у меня от него подгорает?
не у вас від нього, а у нього—від вас.
clickhouse
Контраргумент від Фелікса:
felixit.blog/...2/clickhouse-ne-segodnia
Феликс попытался использовать кликхаес не по назначению, после чего сделал верный вывод:
Что в итоге? ClickHouse для big data, где big начинается с миллиардов строк и сотен гигабайтов. С этой планки вас начинают интересовать уже другие запросы (и они в ClickHouse отлично работают)
Ахахаха.
Только упоротые гошники на полном серьезе могут сравнивать базу данных со спарком. Еще и большую статью написать.
Так статья не от гошников, а от Percona — спецов по базам данных
Не дивно, що SQL-запити до стовпцево-орієнтованого сховища ColumnStore напряму виконуються швидше, ніж SQL-запити до Parquet чи ORC через прокладку у вигляді Spark. Що і демонструється у статті. LOL.
Можна ще було для даних, які зберігаються у ClickHouse, порівняти час виконання SQL-запитів напряму і через clickhouse spark connector у Spark. Думаю, що напряму буде все ще швидше. :-D
По-перше, ClickHouse може працювати тільки зі структурованими даними, а в реальних задачах дані можуть бути різні; Spark RDD дозволяє працювати і з неструктурованими даними.
По-друге, дані у ClickHouse спочатку треба покласти; для Spark ж вже є багато конекторів.
По-третє, у випадку потокових даних, наскільки я розумію, у ClickHouse нема можливості задавати, що коли скидається на диск, а що ще зберігається в пам’яті, а якщо робити це вручну на Go, підозрюю, що реалізація більш-менш складної логіки буде дорогою і довгою; Spark Streaming розв’язує проблему.
По-четверте, незрозуміло, як вирішувати за допомогою Go + ClickHouse задачі, які вирішують Spark ML, GraphX.
До речі, навіть Yandex вирішує деякі зі своїх задач за допомогою Spark. А чомусь не зв’язки Go + Yandex ClickHouse. ;-)
Новый рейтинг языков TIOBE Index for September 2018
Как и предполагалось, Java/C/Python впереди планеты всей и укрепляют позиции. Go предсказуемо лоснул тунца.
Не зрозуміло ніфіга, чому така шалена популярність стала в Сі? Та куди дівся Objective-C? На ньому проектів менше стали клепати?
Та куди дівся Objective-C?
Он (судя по TIOBE) за год поднялся с
ObjectiveC -> Swift
А Swift наоборот — опустился
Почему? — хз.
Не зрозуміло ніфіга, чому така шалена популярність стала в Сі?
Embedded & Automotive
Настільки? Чому раніше не було?
Да — именно так. Сейчас ломанулись пихать Андроид, Тайзен и К° во все дыры, поэтому требуется писать много системного кода, который пишется исключительно на С.
VB.NET смотрю внезапно на строчку выше сишарпа. :)
TIOBE показує рейтинг пошуків. Що вони шукають, без найменшої уяви. Так можна накрутити рейтинг зробивши щось, про що ніхто ще не здогадується.
Нічого дивного що VB.NET пішов вверх. Як на ньому нормально писати в теперішніх реаліях я не здогадуюсь, скоріше пошуки зводяться до використання LINQ.
Теперь программы на php могут быть загружены в Go — github.com/z7zmey/php-parser
Если вы имеете ввиду создание транспиллера PHP -> Golang, то мне кажется это невыполнимая задача.
Для начала нужно определиться:
— что делать с нестрогой динамической типизацией PHP?
— что делать с наследованием методов? (в Go нет класического ООП и метод родительской структуры не будет вызывать переопеределенный метод из дочерней)
Ну и главный вопрос зачем?
Если стоит выбор на чем писть Go или PHP, Go выбирают там где нужна многопоточность или большая производительность чем PHP. Транспиллер не решит эти проблемы.
Есть тип interface{}, и через reflect можно добраться до его методов. Зачем?
Например, для увеличения скорости. Ну и для облегчения портирования старых проектов.
Да про interface{} я не подумал.
Касательно рефлексии — это не лучшее решение если важна скорость.
И прежде чем думать о реализации, стоит задаться парой вопросов:
— есть ли реальная необхдимость портировать код?
— можно ли решить это более легким способом?
К примеру можно использовать github.com/deuill/go-php.
PS: Я был не прав когда сказал что это невыполнимая задача, это мега сложная задача.
Прошла инфа что один из создателей golang начал разработку нового языка на базе scheme, обещает что перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора.
один из создателей golang начал разработку нового языка на базе scheme
если это таки правда, то будет интересно глянуть его, когда зарелизят. :)
перформанс на таких же задачах будет как минимум 3x по сравнению с go — за счет более продвинутой системы потоков и ускоренного сборщика мусора
Интересные планы. Это значит, что перфоманс вместе с планировщиком потоков и сборщиком мусора будет такой же, как у C++, поскольку перфоманс самого Go примерно так и отличается.
Это про github.com/google/wuffs ? Там нет потоков и сборщика мусора
Почему Go одержал сокрушительную победу над Scala? Потому что он против бесполезных абстракций и монадирующих программистов. тут подробности
Аутсайдер виграв у іншого аутсайдера? Яка «цікава» новина...
madnight.github.io/...ut/#/pull_requests/2018/1
уже 4ое место на гитхабе, сразу после жавы — хорош аутсайдер
Внезапно на почётном 9ом — после руби madnight.github.io/githut/#/pushes/2018/1
смотря какими пиписьками меряться. Если по PR — то 4ое, хотя pushи вроде как более честно. Хотя по пушам, там вообще shell рванул вверх, вот уж не ожидали :)
То есть dry, solid (даже не в контексте ООП) это приводит к понижению поддерживаемости, а их ликвидация к повышению?
Интересно это выпускник шага или гоит...
А никто не поделится ссылка разницы Scala vs Go. Лично никогда Scala не видел и даже не сидел рядом с программистом, который на ней писал.
Ну это как добираться в Одессу на современной октавии (Go).
Или на боинге (Scala). Только на боинге также надо самому пилотировать (по книжечке выучить боинг за 21 день), самому платить за керосин, итд итп. Пока выучишь как пилотировать боинг не разбившсь на посадке, и насобираешь денег на керосин — на октавии можно весь мир проехать несколько раз. Зато на боинге можно летать...
А может Go это самопилотруемый одноместный самолет :))
самопилотруемый одноместный самолет
Ага, охренеть какой самопилутруемый qph.ec.quoracdn.net/...c72b058b85774ee804a521165
Да нормальный самолет — я же сказал, что маленький и быстрый. Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так
const (
MaxUint = ^uint(0)
MinUint = 0
MaxInt = int(MaxUint >> 1)
MinInt = -MaxInt — 1
)
Или обьявить их: golang.org/ref/spec#Numeric_types
Все равно это никак не доказывает, что Go лучше Scala или наоборот. Я так посмотрел на Scala и мне показалось, что если вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust. Вот что я могу сделать в Scala, что не могу в Go или скажем могу сделать значительно быстрее. Опять же, Scala это все-таки интепретируемый язык (хоть он и собирается в байт код), но все равно требует JVM для своего выполнения.
Scala это все-таки интепретируемый язык
А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?
вам хочется скажем дженериков или больше всякого синтаксического сахара, то есть тот же Rust.
А есть с++, зачем дебелы вообще какието новые языки пр идумуют, тот же Го, если есть с++ ??? И с дженериками и с поинтерами. Я вот тоже не понимаю. Дебилы.
Ну вот нафига вам ташить Min/Max значение всех констант если можно сделать скажем так
Да вообще непонятно зачем константы кудато тащить если компилятор под платформ все порешает, недальновидные дебыли, да и токо...
А джава тогда что ? А найдите для начала 10 отличий между пхп и джава. Иначе чего вы вообще сюда пришли ?
А VB.NET что ? А С# ? Все компилирует — там в байт-код, там MSIL и дальше уже процессится средой выполнения и компируется в машинный код. Я вас удивлю, но все в конечно счет переходит в машинный код :)) Как это все доказывает, что Go хуже или лучше Java ???
Мы уходит в дискуссию кто дурак. Предлагаю написать какие-то две программы на Go и Scala и сравнить.
Как это все доказывает, что Go хуже или лучше Java ???
Дак это вы утверждаете что жвм интерпретируеться.
Предлагаю написать какие-то две программы на Go и Scala и сравнить.
Во первых, Валиалкин уже все написал, читайте тему.
Во вторых, что вы сравнивать собрались ? Количество строк кода ? Количество открытых коннекшенов ?
Go разгромил Java, Kotlin (и, соответственно, Scala) на AWS Lambda — blog.travelex.io/...o-and-lambda-d30d95290f28 . Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda. Go, только вперед!!!!
Сервисы, написанные на Go, обходятся в 10 раз дешевле аналогичных сервисов на Java-подобных языках на AWS Lambda
Звідки такі данні? У статті нічого про вартість розробки і підтримки наче нема.
Да, про стоимость разработки и поддержки там ни слова. Зато в статье приведены графики, сравнивающие стоимость работы идентичных сервисов, написанных на Go и на Kotlin. И там Go экономнее Kotlin’а в 10 раз. Что выгоднее — платить $10k в месяц за сервис на Kotlin’е или $1k в месяц за аналогичный сервис на Go?
$10К теж ніде не бачу за наведеним лінком.
Значит, и зарплаты в $10к никогда не видать :(
Так, на зменшення зп я навряд чи погоджуся.
На aws lambda в целом компилируемые в бинарку языки себя лучше покажут, изза холодного старта
В статье написано, что Go уделал Kotlin как при холодном старте, так и при прогретом сервисе.
Учитывая, что Го плавно скатывается в небытие, прошу посоветовать, за каким очередным хайповым языком будущее?
те кому нравиться страдать идут в Rust
нічого у rust нема страждального
складненький — так...
але глупості писати не дає, слідкує і навіть поради роздає, як пофіксити
так що може люди і виростуть, буде хороша альтернатива c/c++
так що може люди і виростуть, буде хороша альтернатива c/c++
Не в этой жизни. Rust не соблюдает слишком много общепринятых двоичных стандартов, даже больше чем С++ ...
наприклад?
бо поки офіційну книжечку читаю — там такого нема
Если не изменяет память: «UNIX System V ABI» и компанию. В мире системного программирования где царит С, и куда уже какое десятиление ползет C++ это маст. Таже Ада его соблюдает и поэтому вполне альтернатива С во всех смыслах.
попробував нагуглити «rust unix system v abi», знайшов проблеми 2011 року — так, тоді могли бути проблеми, бо rust стабілізувався довго і нудно
тому все, що раніше 2016 року — зараз можна забути, поки не вийшла версія 1
а свіжі дані є? цікаво було б почитати і пощщупати
а свіжі дані є? цікаво було б почитати і пощщупати
По моей информации нет и не планируется. Раздел документации ffi, или как он там назывался, по факту это взаимно-исключающая альтернатива «UNIX System V ABI»
Кроме того, если мне не изменяет память, там была еще одна такая глобальная грабля, но тут меня подводит память
як написати однотредний сервер, або де мій select (2)
esr.ibiblio.org/?p=7294
Да всё в порядке, всё идёт своим чередом, выпущена версия 1.9.2, код разрабатывается легко, над ненужными
Уже и 1.10 на подходе. А с чем связаны очередные похороны Go ?
А вы не смотрите на рейтинги — язык нужно любить не за рейтинг, а за то, насколько вам на нем удобно программировать или нет. Вот на stackoverflow Go третий по Most Loved, Dreaded, and Wanted Languages и что ?
если на это смотреть, то я вообще не понимаю как Го привлек хоть какоето внимания, хотя я знаю — Гугл, сделал бы это кто другой никто бы и не юзал
Я просто хочу показать, что рейтинги — это всего лишь рейтинги и не более того. Go отличный язык с довольно понятной конкурентной моделью работы. Я хочу еще посмотреть на Rust — может мое мнение изменится, потому что там уже есть generic, атрибуты и все остальное, но пока для своих задача Gо довольно не плохо. Ну и вы правы — Google конечно сильный аргумент :))
после PHP он отлично заходит, от сюда и популярность в спецефических кругах
язык норм просто вовсе не серебряная пуля
Непонтяно чем пыхтеров жабаскрипт неустраивает.
так на go только выебщики идут, обычне пхпшники на жабаскрипт поперелезли уже и не жужат
Уже писали 100 раз, что пыхеры — это не целевая аудитория для Go, они проходят мимо. Там концепт кардинально другой: строгая статическая типизация, многопоточность, ну и в целом код компилируемый, который крутится постоянно. Go в основном юзают те, кто раньше писал на C++ и Пайтоне.
Все самые активные го неадекваты что я знаю-
Пехапешники
Про концепции и реали sv я в курсе, но тут на доу своя атмосфера
Я не PHP-шник. Пишу на .NET, немного на Swift. Перешел на Go после того, как посмотрел в сторону Ruby и потому Elixir. Ничего не понравилось и правильно говорит @schwarzlichtbezirk — там для PHP-никого совсем другая концепция.
А як же явасценаристи які з незрозумілих мені причин хочуть вчити Go?
Откуда вы узнали, что я раньше был пхп-разработчиком? Следите за мной?
бгг нет, с х** бы
с тобой угадал чисто по уровню рассуждений о gc( очень похожих на одного другого чувака на которого я натыкался)
При том что против го я ничего не имею, но твои усилия откровенно не помагают построить не токсичное русскоязычное go lang комунити
:D чёт с го никак не разберусь с одной стороны вечно гошники трындят про простоту языка и доступность каждому, с другой про некую элитарность и открещиваются от разработчиков свитчеров с непопулярных технологий? Этот язык вообще для программирования используется или фетиша?
Вот как раз наоборот, пыхеры юзают самую популярную для бэкэнда технологию. И популярность php получила исключительно благодаря простоте, низкому порогу вхождения, не строгой практике программирования. Разработчики Go учли весь накопленный опыт в практике программирования, и успешно совместили казалось бы совершенно несовместимые вещи, которые раньше не могли быть реализованы все в одном флаконе: простоту, эффективность и качество. В разработку на Go может войти кто угодно, и в этом плюс, и с php объединяет простота разработки. В то же время Go вобрал лучшие практики серверного программирования, и в этом есть расхождение в концепте с php.
кто раньше не осилил C++ и Пайтон
пофиксил
писали писали такие и думают дай деградирую лет на 40 до 70тых
Go разработан как раз корифеями программирования, которые создали в своё время unix и C. И является естественным развитием лучших практик программирования, даже более того, Go во многом опережает своё время. Здесь очевидно сопоставление с эволюцией в животном мире: сначала животный мир развивался в сторону увеличения массы и размеров особей, появились динозавры, тиранозавры и прочие. Это продолжалось до тех пор, пока изменения внешних факторов окружающей среды не доказало неэффективность такой стратегии. После чего появились млекопитающие, которые на первый взгляд никак не сопоставимы по силе и размерам с динозаврами, но тем не менее стоят на более высокой ступени эволюции.
Мы не курим, а несём тут свет прозрения. Роберт Пайк после того как разработал C 40 лет назад, словно как Моисей водил человечество по пустыне, пока наконец не привёл в землю обетованную, в программирование на Go.
Роберт Пайк ... разработал C 40 лет назад
Неправда.
как Моисей водил человечество по пустыне
Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом
привёл в землю обетованную, в программирование на Go
Тільки мало хто це відчув та помітив?
Крім UNIX він був співучасником чи автором таких проектів як:
— ОС Plan 9
— OC Inferno
— Мова програмування Limbo
— Мова програмування Sawzal — теж зроблена для гугла
— Графічний термінал Blit
— Текстовий редактор sam
— Текстовий редактор acme
— Співавтор UTF-8
— Співавтор двох книг з Керніганом
Это только подчёркивает долгий и тернистый путь к Go, как к венцу его творения.
Тільки мало хто це відчув та помітив?
Картины великих мастеров тоже сначала были недооценёнными.
на жабаскрипт поперелезли уже и не жужат
Я так понял пару лет назад жужали, но сейчас это не модно уже :-)
Очевидно же, что будущее за недавно вышедшим go 1.10. В нем полно новых фич, которые никого не оставят равнодушным.
Лямбды — это полуфабрикат замыканий, которые в Go есть изначально по дизайну. В тех языках, где не могут сделать полноценные замыкания, делают лямбды с большим пафосом.
То есть ламбды не появились. Дженерики хоть запилили?
Дженерики не нужны. Для особо упоротых есть github.com/ncw/gotemplate . Только почему-то дальше парочки стандартных структур (list, ring, set, heap) и алгоритмов (sort) дело не пошло. Причем необходимость list и ring высосана из пальца:
— вместо list проще и эффективнее использовать стандартный слайс
— ring используется чуть меньше, чем в одном проекте на миллион, где проще написать один раз реализацию этого ring под конкретный тип в 10 строчек.
Set тоже легко заменяется стандартной map[key]struct{}, хотя синтаксический сахарок тут уже поприятнее.
Остается лишь дженерики для heap и sort, которые необходимы лишь в небольшом проценте оптимизированных по скорости программ, где стандартные heap и sort на интерфейсах не подходят из-за накладных расходов на вызов интерфейсных функций.
Приведите примеры из настоящих программ, где еще могут понадобиться эти дженерики?
Как по мне вот так пишут упоротые люди.
schwarzlichtbezirk
Igor Prots
Włodzimierz Rożkow
Jan Haring
svikso
no name three
Mobile
Java Bee
Iliya Isd
Bot Bot
schwarzlichtbezirk
Andy W
anonymus ps
Гражданин Корейко
Yurii Kostiuk
Eugene Pisotsky
Dmitry
Denis Sedchenko
Dmitry Panfilov
Senseye
minodvesP Vasya
Yuriy Pitometsu
А Р
Gremlin
Eugene Abramchuk
Valeriy Shvets
Konstantin Strukov
Ruslan Shevchenko
Iurii Vishnevskyi
Andrii Sevastianov
Denys Poltorak
Nik Katalnikov
Lambda
Dmytro Lapshyn
Sergey Lysak
Roman Pavlyuk
Punk Floyd
Евгений Ануфриев
Dmitry Panfilov
Alexander Baranetsky
Ярослав Характерник
Yury Gavrilenko
Ivan Boyaryn
minodvesP Vasya
Иван Камышан
Yuriy Znovyak
Vlad Stelmahovsky
Ilya Trushchenko
anonymus ps
Vitaly Chernooky
aa aa
Svyatoslav Danyliv
Vadim Slizov
Valentyn Ponomarenko
Valentyn Ponomarenko
onemore
people := []struct {
Name string
Age int
}{
{"Gopher", 7},
{"Alice", 55},
{"Vera", 24},
{"Bob", 75},
}
sort.Slice(people, func(i, j int) bool { return people[i].Age < people[j].Age })
}
Нормальные делают тоже самое вот так
people.Sort(p => p.Age)Если бы у Go были генерики он бы тоже так мог.
Если очень надо, можно определить метод для слайса:
func (self *[]People) Sort() {
sort.Slice(self, func(i, j int) bool { return self[i].Age < self[j].Age })
}
и дальше вызывать вообще без параметров: people.Sort(). С чего вдруг на каждый чих должен быть встроенный метод.
Лямбды — это полуфабрикат замыканий
Вообще-то ламбда это возможность определить «анонимную функцию» с «ссыланием на неё» не по имени а по «переменной ссылке указателю» что там поддерживается текущим языком само по себе «замыкание» это уже способность захватывать такой анонимной функцией текущий контекст так что «лямбды» никак не могут быть «полуфабрикатом замыканий» потому как вполне способны существовать и функционировать без него а замыкание просто способность как передавать переменные во внутреннюю функцию не в качестве параметров так и что более важно возможность продолжения их времени жизни временем исполнения уже внутренней функции которая обратно таки может прекрасно работать сама по себе и без этого.
Но вообще интересно нарисуй псевдокод как ты видишь замыкание без лямбды?
Кака разница, как это называется? Кому-то нравится название «лямбда», кому-то «замыкание», кому-то «анонимная функция», альтернативно одаренные называют это «лАмбда». Главное, что в Go это есть.
Кака разница, как это называется?
Видимо така разница что как это таки две разные сущности и принципа и функции не?
Главное, что в Go это есть.
Ну х.з. если честно я полагаю сабжевая речь об том что
Лямбды — это полуфабрикат замыканий
Суть замыкания в работе с контекстом вызова, который сохраняется при выходе за пределы определения локальных переменных, с которыми работает функция. Лямбда контекст не сохраняет. Например, в общем случае вариант типа этого не прокатит
std::function<int()> l;
{
int a = 10;
l = [&]() { return a; };
}
int b = l();
а если?
auto a = std::make_shared<int>(10);
l = [=](){ return *a;}
В Go решение об управлении объектами GC принимает компилятор на стадии компиляции, а со стороны разработчика всё выглядит совершенно прозрачно. И таким образом, исключаются лишние возможности отстрелить себе ногу.
Дженерики и ламбды есть?
Это какие-то новые наркотики? На стенках видел только фен в телеге.
В нем полно новых фич
There are no significant changes to the language specification
вот и стагнация наметилась, Go больше не может ничего нового предложить хипстерам
А как же вот это?
the compilers have been updated to allow the index expression x[1.0 << s] where s is an untyped constant
The grammar for method expressions has been updated to relax the syntax to allow any type expression as a receiver
Также go 1.10 может:
— быстрее управляться с миллионом таймеров и/или одновременных подключений — github.com/golang/go/issues/15133
— быстрее конвертировать строки в числа — github.com/golang/go/issues/20557
быстрее конвертировать строки в числа
Серйозна заявка на перемогу... Сплю та бачу системи, які швидко конвертують строки в числа...
от якби вони конвертували їх в валюту
Валюту в строках зберігати? о_О
Оце взагалі перемога перемог!
Мы стали сеять больше ржи
топ 10 лучших языков программирования. :) Go как и Swift перспективные языки medium.com/...earn-in-2018-2d6cbc5ffc2a
а де там Go?
там навіть його назва не згадується...
C успешно эмбедидся в коде на Go, так что низкоуровневое API можно успешно писать на C в рамках Go-проекта.
C вообще много куда эмбедится
Вот именно этим и объясняется востребованность C. Врядли кто-нибудь на сегодняшний день начнёт писать с нуля полностью на чистом C какую-нибудь крупную систему. На сегодняшний день C, как и Asm, правильнее поставить в отдельную категорию.
Если на проэкте ликвидировать всех Agile-одаренных то мало какой язык сможет радикально дать фору С. 50% в лучшем случае.
Чистый С это уж слишком на любителя. Но «C с классами» (и шаблонами) ... :)
В Го все, включая С, эмбэдится очень хреново и именно это его убьет.
Ага, хайп чуть поутих, походу
’Pokémon GO’ Will Finally Invade China In 2018
Кто еще сомневается что за Go будущее??
У Go нету будущего. Go это просто удачный студентческий эксперимент. Скорее всего в будущем разделит судьбу lua.
а що не так із долею Lua?
поцікався — вона доволі популярна серед розробників ігор, на ній пишеться доволі багато внутрішньої логіки
Узкая специализация и нишевость
Тем не менее, более широкая, чем у других скриптовых языков, используемых в геймдеве, или заточенных под конкретный игровой движок. Благодаря лёгкой встраиваемости, используется везде, где нужно выносить какую-то логику в скрипты.
Недавно наткнулся ziglang.org, вполне годная альтернатива lua когда зарелизят 1.0
Кстати, основной разраб какой-то геймдев.
відкрив приклади — савсем не пахож на lua
скорше схожий на rust, але rust вже версії 1.27 і набирає обертів
Скорее продвинутый C, всё-таки основная фишка rust это вывод типов и статическая гарантия отсутствия race condition через механизмы владения. Тут этого нет, при этом создаётся впечатление, что код 1:1 можно перевести на C, только выделены наиболее часто встречающиеся шаблоны.
Альтернатива не значит схожесть синтаксисом. Я не писал игр используя луа, не знаю как он встраивается, но подозреваю что он компилируется в байткод или просто скрипты хранятся в ресурсах. CFFI в Zig примерно такое же простое, как в Go, но для Go приходится писать враперы для C++ а-ля [code]#ifdef __cplusplus[/code]. Во-вторых, Zig транслируется в С. Ну и не похож он на Rust от слова вообще, не понимаю где ты там схожесть заметил. Скорее C++ или D.
у будь-якому випадку, це не альтернатива lua
може я погано виразився, але місце lua у цій системі — це власне «високорівневе» написання скріптів — логіки, ботів, плагінів — ніхто на lua числодробілки не пише
вона з самого початку заточена на те, що її будуть встроювати у хост систему і писати байндінги для всіх API, які хочеться туди винести
один з прикладів неігрового використання lua — OpenResty
ну і, думаю, є багато інших, оскільки, по словах людей (я свого досвіду не маю), вона реально легко ембеддиться, вплоть до того, що на ній реалізовують конфіг парсери
С тоже высокоуровневый язык =) Плюсы lua я вижу в том, чтобы дать игрокам возможность писать свои плюшки, в тоже время не открывая исходники игры. Не берусь утверждать, но то ли в Доте, то ли в Сталкере, то ли еще в какой-то мега-популярной игре именно так и сделано. Но я в компьютерные игры не играю, точно не скажу.
Насчет числодробилок, на lua+C написан torch7. Выбор, имхо, странный, тот же питон вписался бы лучше, но проект взлетел и это факт.
Но вернемся к Zig, вот что пишет сам автор про мотивацию (предупреждаю я не геймдев и не обладаю знаниями в предметной области):
```
The motivation for this design philosophy is to enable users to write any manner of custom allocator strategy they find necessary, instead of forcing them or even encouraging them into a particular strategy that may not suitable for their needs. For example, Rust seems to encourage a single global allocator strategy, which is not suitable for many usecases such as OS development and high-performance game development. Zig is taking cues from Jai’s stance on allocators, since that language is being developed by a high-performance game designer for the usecase of high-performance games.
```
github.com/...-Already-CPP,-D,-and-Rust
В Rust есть unsafe, и создатели языка прямым текстом пишут, что unsafe это просто помощи системе вывода типов там, где она это сделать не может. И если возникают ошибки при работе с памятью (SEGFAULT, race condition), то они сконцентрированы в блоках unsafe.
Да, если есть много аллокаторов памяти, то часть преимуществ Rust будет сложно использовать.
А насчет embedding — lua выбирают потому что интерпретатор компилируется в бинарник размером ~300kb. При том lua тьюринг полный. Тут еще можно вспомнить про terralang.org
Go снова отличился!
Google’s DeepMind team has already advanced its AlphaGo AI to dominate Go without human input
Кто еще сомневался что за Go будущее?
Щоб Гугл не забив на нього, як він це робить зі своїми сервісами.
Куда ж забивать, если Go на четвертом месте по популярности на github после Javascript, Python и Java? Скоро догонит и перегонит Java. Что касается недоразумения в виде Javascript, то его можно игнорировать, т.к. его в основном используют люди, далекие от программирования.
На четвертому місці по кількості проектів на github. Варто створити кілька сот тисяч hello world на Basic щоб вивести його в лідери на github.
Go снова в десятке, а Scala — аутсайдер — octoverse.github.com
Go в десятке, а Scala — на 30 месте — www.tiobe.com/tiobe-index :
The Go programming language continues to rise. This month it is at an all time high and enters the top 10. This is an important landmark for the Go programming language, but it also makes you wonder what’s next. Is Go really able to join the big stars in the programming language world and leave languages such as JavaScript and Python behind? We will see. The hipster programming languages Kotlin, Elixir and Hack didn’t progress much this month. Kotlin lost 5 positions, Hack lost 6 positions and Elixir is still not in the top 50 losing also 5 positions.
Go в десятке,
пал ниже delphi в этом году, хипстеры видать набивились этим куском дерьма
Просто в этом году кто-то много заплатил в фонд тиобе, чтобы те опустили го в рейтинге, не имеющем никакого отношения к реальности
скорее ктото забашлял им меньше в этом году
На самом деле — tiobe что=то странное почти всегда показывает. Реальность совсем другая (на следующей неделе опубликую опрос по языкам c неожиданностями )
Как сделать бэкенд многопользовательской игры на Go — blog.u2i.com/...owser-game-in-go-for-fun
Прикольно. Я смотрю, там чуваки собрались, и всерьёз решили потратить время на написание этой игры.
Vitaliy Fedoriv
Alex Koshterek
Віталій Шкуренко
Vitaly Chernooky
Roman Gomoliako
No Name
Марічка
Ruslan Shevchenko
Найкращі коментарі пропустити