Goatee - текстовый редактор, на gtk2, на go.

То есть, если РКН заблокирует GitHub в очередной раз, чтобы дети не делали суицид, то этот редактор не соберётся?

Просто скажи что не осилил обход

Вы не понимаете что просто расписываетесь в собственной некомпетентности? На самом деле в современном C++ очень сложно выстрелить себе в ногу. А в go достаточно забыть defer.

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

И это от некомпетентности. Отладка нужна для тех кто не понимает что пишет (чтобы под отладчиком разбираться как на деле работает написанный ими же (!) код), и тех кто пишет небезопасно, из-за чего случаются сегфолты. Я gdb в руки брал последний раз в середине 90-х. А так-то в go нет ничего что было бы проще gdb.

Некоторые сложные вещи всё же приходится отлаживать.

встроенным пакетным менеджером

Который ничего не умеет?

Два чая. Привет мир llvm на rust собирается одной командой. И быстро. На go во первых нужно всё руками поставить, а во вторых нужно пару минуть ждать сборку, поедающую полтора гигабайта.

Да ну.

Сказать-то было хоть что-то или этот пук и был оргазмом?

Более того, ему не нужно каждый раз err проверять по возврату из функции.

Сколько у тебя будет собираться данный код? https://felixangell.com/blog/an-introduction-to-llvm-in-go

Вот по этому и имеем программы под андроид 30+ Мб.

Поэтому я и ставлю на «красное»

Какой код? Который там в конце под заголовком «Full Code» приведен?

Да, в самом низу. Заодно скажи сколько оперативки нужно.

Что этот милипиздрический пример должен показать? Почему бы сразу HelloWorld не проверить?

Доооолгооооо

Повторю вопрос: сказать-то было хоть что-то?

сколько... БОЛИ, от простого текстового редактора на go, интересно а что будет если я вам web-браузер на go притащу?

сколько... БОЛИ

Это вы про свою боль? Оно и понятно, даже простой текстовый редактор на go — это уже испытание.

а что будет если я вам web-браузер на go притащу?

Вы не выживете после такого эксперимента.

интересно а что будет если я вам web-браузер на go притащу?

Это будет мега-срач на тему GO vs Rust. Один такой топик затмит сразу все срачи на тему Java vs C#.

А по сабжу, автор вы молодец. По ходу вы один из не многих кто предпочитает работать, а не болтать

Я жду когда ты попытаешься это дело собрать. Тогда можно будет поговорить.

Я жду когда ты попытаешься это дело собрать.

Хотелось бы понять, в чем смысл сего действа. Какое отношение один частный пример интеграции llvm и Go будет иметь к сравнению скоростей работы компиляторов Go и Rust-а?

Тогда можно будет поговорить.

Пока вы ждете у моря погоды, посмотрите интересные картинки на соответствующую тему: Code gen'd quick sunday slam - Comparing compilation time of random code in C++, D, Go, Pascal and Rust

К тому что не осбо страясь можно получить ситуацию когда сборка замирает. Похожий пример на rust собирается за пару секунд.

К тому что не осбо страясь можно получить ситуацию когда сборка замирает.

А вы поспрашивайте ТС-а, часто ли у него сборка его редактора замирала. И часто ли ему приходилось у себя в Go с llvm линковаться. А то нашли пример, который 99.9% Go-шников нафиг не упал и носитесь теперь с уверенностью, что компиляция в Go медленнее, чем в Rust-е.

Дык, там небось большая часть кода на плюсах. Попробуйте с go build -x -v, чтобы увидеть, что происходит.

Какой смысл сравнивать hello.rs с проектом который процентов на 80% состоит из C++?

Прав был Стауструп, на «убогом» Го берут и пишут, а Раст только расхваливают. Растишки, покажите что-нибудь подобное сабжу на своем любимом язычке.

Ты в пятницу записываешься или в среду?

Многие его не используют по причине объёма зависимостей.

что-нибудь подобное сабжу

Подобное чему? Редактору в 100 строк?

https://github.com/oakes/SolidOak

https://github.com/google/xi-editor

https://github.com/gchp/iota

Недоделки с десятками контрибьтеров и несколькими годами разработки, как и все на Расте. А тут за четыре месяца один запилил.

Многие его не используют по причине объёма зависимостей.

И в место Qt используют... что?

На всякий случай, заранее позицию обозначу: да, «многие не используют Qt», но причины совершенно разные. Кто-то использует вообще не плюсы, кто-то на них делает кроссплатформенное ядро, а к нему прикручивает разный нативный гуй в зависимости от платформы. Вот только последнее делается, зачастую (собственно, в моём опытe - всегда), для достижения лучшего результата, а не из-за жирности фреймворка.

Ещё есть варианты использовать какой-нибудь другой фреймворк, но я более чем уверен, что все популярные тоже будут кроссплатформенными, то есть выбора между «поддержкой разных платформ» и «жирностью» стоять не будет. Хотя, конечно, можно будет найти какие-то экзотические исключения.

Недоделки с десятками контрибьтеров и несколькими годами разработки, как и все на Расте. А тут за четыре месяца один запилил.

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

(На самом деле, мне пофиг и камень в огород ТС кидать не хочу, что-то делает и молодец.)

Вот это я понимаю мнение иксперта.

У многих просто горит от его размера. Но альтернатив по-прежнему нет.

А то нашли пример, который 99.9% Go-шников нафиг не упал и носитесь теперь с уверенностью, что компиляция в Go медленнее, чем в Rust-е.

Компиляция в go может быть как быстрой так и медленной. Я понятия не имею в чём проблема заключалась на этот раз и выяснять не буду. В данный момент я слишком не заинтересован в go.

Дык, там небось большая часть кода на плюсах. Попробуйте с go build -x -v, чтобы увидеть, что происходит.

Спасибо, когда-нибудь надеюсь посмотрю.

Какой смысл сравнивать hello.rs с проектом который процентов на 80% состоит из C++?

Я нашёл несколько похожий пример на расте. В отличии от го он собрался почти мгновенно. https://gist.github.com/iwillspeak/1fed07333f7187c25735e90d73b82468

Я вне среды, и мне не нужно записываться.

Я нашёл несколько похожий пример на расте. В отличии от го он собрался почти мгновенно

Осспыыыдяяя ... :-( Ты хоть понимаешь что единственный корректный вывод их этого - это то, что NextGenenration - полный дебил?! "... несколько похожий пример ..." *ля! :-(

Сильный аргумент(нет)

Ну и естественно, я проводил тесты, линейное ускорение до 10 CPU (дальше меня не интересовало пока). И в однопоточном режиме быстрее референсной C-имплементации в несколько раз.

[вне дискуссии о языках] Успехи в линейном ускорении на самом деле обманчивы: если наблюдается линейное ускорение, значит, однопоточная реализация далека от оптимальности. А такой успех по сравнению с «референсной» реализацией я мог бы объяснить тем, что она не референсная, а черновая (ну или режим никакой не однопоточный).

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

Ну это зависит от задачки. Например любая embarrassingly parallel задача должна ускоряться линейно. Если задачу можно разбить на почти независимые куски, то будет что-то типа линейности. Референсная задача однопоточная. Референсная она в том смысле, что 99% real world анализов делается в ней.

Это ж сколько лишнего времени на набивание букв тратит инженер, пишущий на Go, mamma mia!

Совсем дурачок? Для этого снипеты есть. Ты поди и пробелы для выравнивания по одному набиваешь.

Кто-то тут не умеет в сарказм.

Тут макропроцессор нужен. Но касается это не столько func, сколько других конструкций.

Мои претензии к автору: 1. Редактор падает, если не скопировать goatee.conf в ~/.config/goatee/ вместо того, чтобы сделать это самостоятельно. 2. Подсветка кода для Go работает избирательно (тут видимо косяк gtksourceview2). 3. Нет закрытия вкладки нажатием на таб колесом мыши. 4. Нет справки.

Вот еще пару:

5. Нет своей иконки в панели задач, рисуется дефолтная.

6. Нет возможности вызвать команды основного меню из контекстного.

Огромное спасибо, доработаю.