LINUX.ORG.RU

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

 , ,


1

5

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

Основные возможности, преимущества:

  • Автоматическое определение кодировки и перекодирование;
  • Отображение бинарных файлов в виде hex`а, а если установить синтаксис(hex.lang), то ещё и подсвечивать 00 и FF;
  • Определение синтаксиса(sh,perl,python...), в том числе для файлов конфигурации, чего, кажется, никто не умеет;
  • Корректное открытие файлов через drag and drop и с удаленнных машин(gvfs);
  • Возможность скрыть меню, скрыть кнопку закрытия вкладки(крестик), отображения вкладок на всю ширину(homogeneous tabs).

Ну и ещё, что не мало важно, по крайней мере для меня, это отсутсвие привязки ко всяким dconf.

Из недостатков - код все ещё сырой, тестов нет, большой объем бинарника(так как go).


Ответ на: комментарий от Weres

Редактор не важен, я узнал про размер и сравнил с тем что может ред, и да ред оказался лучше, но не стоит сильно переживать, возможно на го тоже когда-нибудь можно будет делать адекватные гуевые программы, но это не точно.

loz ★★★★★
()
Ответ на: комментарий от slovazap

Субъективщина же. С таким же успехом:

«Прекрасный язык с GC вместо ручного управления памятью, с интерфейсами и нормальным возвратом ошибок вместо нечитаемых дженериков и медленных и неудобных исключений, с классным defer вместо негибкого raii, распределенной инфраструктурой и встроенным пакетным менеджером. Со статической сборкой, никаких плясок с версиями библотек или подмен .so на вредоносный код. Команда на зарплате занимающаяся языком full time, клёвый маскот. И без упоротых застрявших в мире однобайтовых кодировок и отсутствия интернета пользователей.»

Davidov ★★★★
()
Ответ на: комментарий от Davidov

Субъективщина же. С таким же успехом:

Это было бы так, если бы Go можно было бы сравнить только с C++. Но ведь его же можно сравнить с D (статика, сборка мусора, и исключения, и RAII, и шаблоны, и компиляция быстрая, и иммутабельность нормальная в языке, только что разрабы не на зарплате). Или с Rust-ом (нет GC, но с контролем со стороны компилятора, с интерфейсами и нормальным возвратом ошибок, с RAII, с генериками, и с разрабами на зарплате).

eao197 ★★★★★
()
Ответ на: комментарий от loz

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

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Язык делается не только для текстовых редакторов, а для других программ тоже. Отличный пример на эту тему это порт гуев из браузера в standalone движок + сайт, когда чятик в слаке весит 300 метров, как думаешь, против гуя в 5 метров будет разница? А приложения для мобилок? И так во всем.

loz ★★★★★
()
Ответ на: комментарий от loz

Чет Go проигрывает расту чуть более чем во всем, как их можно сравнивать?

Так мы на LOR-е или где? :)

Ну и по скорости компиляции Go как-то пошустрее Rust-а будет, afaik.

eao197 ★★★★★
()
Ответ на: комментарий от loz

И так во всем.

Но всё-таки найдётся немало случаев когда поддержка других платформ, кроме Windows, окажется важнее размера.

Если что, Red мне интереснее, чем Go (был бы он ещё статически-типизированным...), но сути это не меняет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от loz

Порог входа и возможность говнокодить не приходя в сознание (как на Java). Для промышленных решений это важнее контроля за памятью со стороны компилятора. Хотя как программист я бы выбрал раст.

Weres ★★★
()
Ответ на: комментарий от Weres

Порог входа и возможность говнокодить не приходя в сознание (как на Java). Для промышленных решений это важнее

Я бы поспорил важнее это или нет, но да, наличие огромного количества легко заменяемых, и как следствие дешевых, кодеров хорошо для работадателя, но не для программиста.

loz ★★★★★
()

не не, мой хипстометр не пробивает дно
Надо было таг: написать веб службу на го, клиентскую часть на js и завернуть в electron

mos ★★☆☆☆
()

кста, всяко оценил помещение этого в /dev
Ведь это ТС стончил, да ведь? да?

mos ★★☆☆☆
()
Ответ на: комментарий от RazrFalcon

PS: никак не могу перестать угарать с ссылок на git master в зависимостях. Каждая сборка - приключение.

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

EXL ★★★★★
()
Ответ на: комментарий от DarkEld3r

Еще раз повторю - GTK гуй скоро будет, сейчас маковский заканчивают и он уже на очереди. Насколько я знаю это связано с тем что перед спонсорами надо отчитываться, поэтому гуй даже до GC делают.

был бы он ещё статически-типизированным

Ret/System по-сути сишечка, для обычного реда в теории можно накрутить проверок сверху, на практике конечно он слишком динамичен для анализа кода.

loz ★★★★★
()
Ответ на: комментарий от eao197

Я считаю, что D с Rust и Go — это просто разные ниши. В Go принят ряд удачных решений, поэтому на нем легко писать консольные утилиты и веб-сервисы. Но в куче мест Go просто не заработает, например, код драйвера или микроконтроллер писать на Go глупо. Это не значит, что Go плохой язык, это значит, что он не подходит для определенных задач.

Ну плюс языку D примерно 16 лет, и все это время мы ждем, как он наконец-то убъет C++. При этом Go появился на 8 лет позже, чем D, и уже давно его обогнал и нашел свою нишу.

Так что уже пора перестать думать про D, как про новый многообещающий язык.

Что касается Rust, он классный, но сложный. Не всем и не всегда хочется воевать с borrow checker. Скажем переучиться с Python на Go можно за пару недель, с Rust такое не пройдет.

Davidov ★★★★
()
Ответ на: комментарий от slovazap

Я начал писать кое-что для научных подсчетов на Go, когда Rust ещё не стабилизировался. И я могу уверенно сказать, с D или C/С++ я намучился бы намного сильнее; то есть это был правильный выбор на тот момент.

Главное свойство языка — безопасность, очень тяжело себе выстрелить в ногу. Плюс concurrency, естественно. Многие решения, имхо, довольно удачные. В том же Rust скопировали каналы недавно, если я правильно понял. Отладка очень простая. Большинство претензий к языку от тех, кто с ним едва знаком.

Из того, чего действительно хотелось бы — это дженерики. В принципе с интерфейсами можно жить и без них.

Так что черное/белое — это все субъективно.

Davidov ★★★★
()
Ответ на: комментарий от Davidov

Речь была не об этом, а о том, что в современном мире сравнение Go c С++ имеет мало смысла. Если мозгов хватает только на то, чтобы переучиться с Python-а на Go, то рассматривать C++ в качестве альтернативы точно не будут. А вот D можно и рассмотреть. Ну и для написания редактора, которым будет пользоваться полтора пользователя, D подойдет не хуже Go.

eao197 ★★★★★
()
Ответ на: комментарий от Davidov

И я могу уверенно сказать, с D или C/С++ я намучился бы намного сильнее

Простите мне мой французский, но с чем в D можно намучаться? Особенно в сравнении с Go?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Отсутствие библиотек :) Которые уже тогда были доступны для Go, а для D я месяц назад проверял, нормальных библиотек нелинейной оптимизации не было и нет.

Кстати, у D основная имплементация частично под несвободной лицензией, я правильно понял? Тогда я бы D вообще не рассматривал.

Davidov ★★★★
()
Ответ на: комментарий от Davidov

В том же Rust скопировали каналы недавно, если я правильно понял

Каналы в Rust есть... уже лет 6-7, наверное.

tailgunner ★★★★★
()
Ответ на: комментарий от Davidov

безопасность, очень тяжело себе выстрелить в ногу

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

Плюс concurrency, естественно

Это тоже от некомпетентности. Хипстеры с легковесными поточками никогда не почешутся посчитать сколько реально ускорения они получают со своими каналами. А чаще всего они получают только замедление, потому что никакой магической параллельности у них не наступает, а оверхеда каналов никто не убирал. Настоящее concurrency достигается только параллельностью по данным, а для неё не нужно ни канальчиков, ни синхронизации, ни оверхеда у неё нет, и пишется хоть на сырых pthread_create/pthread_join, хоть на fork/wait, хоть вообще не пишется, тогда последовательный код запускается в нужном числе экземпляров и параллелится и на ядра, и на машины, и на датацентры.

Отладка очень простая.

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

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

Это про C++

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

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

Может быть если писать на маленьком подмножестве C++, то довольно безопасно. Но это подмножество довольно ограниченное, это раз; реальные программы часто используют намного больше. А вы понимаете, для чего используется defer?

Это тоже от некомпетентности. Хипстеры с легковесными поточками

Вы какую-то чушь несете. Во-первых, concurrency — это не только параллелизм. Во-вторых, естественно, модель тредов POSIX гибче. Но, в Go же есть не только каналы, если надо.

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

А плохой код можно написать хоть с потоками, хоть с каналами.

Отладка нужна для тех кто не понимает что пишет

Бугага. :) Ну и для протокола, я не имел ввиду интерактивную отладку, её мне в Go не приходилось пока использовать.

Но про некомпетентность — это какие-то ваши фантазии; даже не буду обсуждать.

Davidov ★★★★
()

Вас на галеры нужно ссылать, кто редакторы велосипедит.

BigAlex ★★★
()
Ответ на: комментарий от RazrFalcon

Да не, база как и планировалась это тот же Rebol, у авторов довольно ясное представление о том что они делают, в основном допиливают фичи и фиксят баги, изменений мало.

loz ★★★★★
()
Ответ на: комментарий от Davidov

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

В 2017-м году хвастаться поддержкой unicode в языке - это клиника.

нормальным возвратом ошибок

Лул. Нет. Нормальный в rust.

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

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

Команда на зарплате

Не осилившая дженерики и динамическую линковку. Бинарь весит в разы больше rust'a, который тоже статически собирается.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

В 2017-м году хвастаться поддержкой unicode в языке - это клиника

Клиника - это продолжать писать прикладуху на языках без юникода. И таких клинических полный опенсорс.

Не осилившая дженерики и динамическую линковку

Они осилили главное - доступный язык. В отличие от авторов раста.

// Сам ближе к растолюбам, но справедливости для.

anonymous
()

По сабжу - сразу была та же ассоциация, что у Harald. Хоть и не любитель этого дела, на ЛОРе научился :D

anonymous
()
Ответ на: комментарий от RazrFalcon

У раста небыло аналогичного предшественника, как говорят авторы реда - это на 90% ребол.

loz ★★★★★
()
Ответ на: комментарий от slovazap

Я впреть буду читать до конца, прежде чем строчить ответы

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

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

последовательный код запускается в нужном числе экземпляров и параллелится и на ядра, и на машины, и на датацентры

Отличный комментарий в свете новости о текстовом редакторе. Какое минимальное количество датацентров нужно, чтобы запустить твой любимый редактор?

А так-то в go нет ничего что было бы проще gdb.

Ну вот тут было бы хорошо уточнить, что мы отлаживаем. Потому как отладка шаблонного C++ кода была, есть и остается огромной болью в заднице, начиная от проблемы постановки breakpoint-а. И, кстати, будь gdb удобнее, чем втыкание отладочной печати, возможно я бы пользовался им чаще.

kawaii_neko ★★★★
()
Ответ на: комментарий от slovazap

. Я gdb в руки брал последний раз в середине 90-х

XIX века, ага.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Клиника - это продолжать писать прикладуху на языках без юникода.

Это уже клиника^2.

RazrFalcon ★★★★★
()
Ответ на: комментарий от kawaii_neko

Это слишком просто.

Нужно что-то типа:

    std::vector<int> v({1, 2, 3});
    int &i = v.at(1);
    v.erase(v.begin() + 1);
    std::cout << i << std::endl;
RazrFalcon ★★★★★
()
Ответ на: комментарий от Davidov

В Go принят ряд удачных решений

Список в студию.

Скажем переучиться с Python на Go можно за пару недель, с Rust такое не пройдет.

Конечно. Проще потратить своё время на ручную обработку ошибок.

RazrFalcon ★★★★★
()
Ответ на: комментарий от DarkEld3r

Но всё-таки найдётся немало случаев когда поддержка других платформ, кроме Windows, окажется важнее размера.

Qt это не спасло.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Тысячу раз да! А ещё ключевые слова в Rust аж вдвое короче (fn вместо func). Это ж сколько лишнего времени на набивание букв тратит инженер, пишущий на Go, mamma mia!

anonymous
()
Ответ на: комментарий от loz

Еще раз повторю

Видел, но «сейчас доделывают» - это не «имеется уже».

Ret/System по-сути сишечка, для обычного реда в теории можно накрутить проверок сверху, на практике конечно он слишком динамичен для анализа кода.

Red/System - это всё-таки немного не то. Вот если бы они сделали Red/Typed было бы забавно.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Вот если бы они сделали Red/Typed было бы забавно

Как ты понимаешь в реде анализ кода это элементарная вещь, если есть опыт создания систем с выводом/проверкой типов - типизированный диалект не сложно замутить.

loz ★★★★★
()
Ответ на: комментарий от Weres

Порог входа и возможность говнокодить не приходя в сознание (как на Java)

Не знаком с java, но на go это выливается в то что в сознание лучше не приходить. Ибо приходится писать кучу однообразного рутинного кода

NextGenenration ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.