Область использования языка GO?

Question

[slepowl]

Здравствуйте, подскажите область использования языка go. Интересуют подобные задачи:
1) Например, создание NamedPipe для связи со старым Delphi-приложением с одной стороны и связь с API WEB-сервера с другой. По сути моста для передачи данных.
2) Парсер xml-файлов с возможностью каталогизации и конвертации данных из xml в другие форматы.
3) передача данных по сети на канальном и сетевом уровнях
4) Работа с UART-интерфейсами
5) web-сервисы
6) простые ГУИ (кнопка, кнопка и оконце).

Я знаю, что все можно на С, интересует golang - подобные задачи можно ли решать и если да, насколько быстро(скорость разработки)? То есть использовать для прототипирования итд. Или проще забить и взять С\Java?

Answer 1

[evnuh]

Рассматривайте Go как что-т осрденее между явой и плюсами. Соответственно, всё сделать можно, особенно учитывая, что Go может работать с С кодом. А писать GUI на нём так же, как на C++, только либ ещё меньше. Есть биндинги Qt.

Comments

[slepowl]

Спасибо, ГУИ может и хватил, просто иногда нужен минимальный интерфейс, но веб не всегда получается использовать.

Answer 2

[bnytiki]

Канальный и сетевой уровень - вы уж хватили. Это уровень драйверов.

Все остальное - вполне.

Comments

[slepowl]

Ну тут я имел ввиду возможность запаковать данные в ethernet II кадр и выдать в порт, не более)

[bnytiki]

slepowl:
Если есть библиотеки, написанные на С, которые это позволяют - то Go это позволяет тоже.

Answer 3

[Rou1997]

2) Парсер xml-файлов с возможностью каталогизации и конвертации данных из xml в другие форматы.
6) простые ГУИ (кнопка, кнопка и оконце).

Проще забить и взять C# если Windows, а если нет, то Java, Python, C++.

5) web-сервисы

Смотря какие.

интересует golang - подобные задачи можно ли решать и если да, насколько быстро(скорость разработки)?

Он не для скорости, скорость разработки и Google несовместимы, он для высокой нагруженности.

Comments

[bnytiki]

Судя по всему вы с Go не знакомы.

Сделать парсер xml на нем - просто. Взять C#, Java, Python, C++ - ничем не лучше, ничем не хуже.
А если размер xml-файла небольшой, то сделать парзер на Go так вообще - элементарно.

type Email struct {
		Where string `xml:"where,attr"`
		Addr  string
	}
	type Address struct {
		City, State string
	}

	var result struct {
		XMLName xml.Name `xml:"Person"`
		Name    string   `xml:"FullName"`
		Phone   string
		Email   []Email
		Groups  []string `xml:"Group>Value"`
		Address
	}

	err := xml.Unmarshal(data, &result)

[bnytiki]

Он не для скорости, скорость разработки и Google несовместимы, он для высокой нагруженности.

В том числе и для скорости разработки.
Специально для этого разработан его синтаксис.
Многие любители традиционных языков (с усложненным синтаксисом) - принимают синтаксис Go в штыки за его высокую простоту.

[Dark Hole]

bnytiki: это как? Простой и быстрый синтаксис, я имею ввиду.

[Rou1997]

bnytiki:

Судя по всему вы с Go не знакомы.

Знаком.

Взять C#, Java, Python, C++ - ничем не лучше, ничем не хуже

Для GUI однозначно лучше C#, но, судя по всему, вы не знакомы с WinForms и WPF!
Простота, говорите? А ну-ка продемонстрируйте мне простоту GUI на Go! Здесь одним синтаксисом не обойтись, он него не так и много зависит.
Во-вторых, C#, Java, Python, C++ лучше тем, что популярнее, то есть экосистема больше, поэтому проще и легче.

Многие любители традиционных языков (с усложненным синтаксисом) - принимают синтаксис Go в штыки за его высокую простоту.

И еще раз, синтаксис не решает!

var result struct {
XMLName xml.Name `xml:"Person"`
Name string `xml:"FullName"`

Ну и что?
Вот в C# подобное:

[XmlRoot("StepList")]
public class StepList
{
    [XmlElement("Step")]
    public List<Step> Steps { get; set; }
}

public class Step
{
    [XmlElement("Name")]
    public string Name { get; set; }
    [XmlElement("Desc")]
    public string Desc { get; set; }
}

[Rou1997]

bnytiki: И да, у Brainf*ck простой синтаксис или наоборот?

[bnytiki]

Rou1997:

Для GUI однозначно лучше C#, но, судя по всему, вы не знакомы с WinForms и WPF!

Уже в 1997 году был знаком с их предком - Delphi
Да и с возможностями построения интерфейсов в C#/NET знаком.

Но для создания примитивных интерфейсов в стиле.

простые ГУИ (кнопка, кнопка и оконце).

Никакие WPF не являются необходимыми

[bnytiki]

eax.me/go-gkt-gui
Вполне достаточно.

[bnytiki]

Dark Hole: Для сравнения - Java довольно многословен, много концепций.
Лишняя (не всегда нужная) нагрузка на мозг.

Изначально Java был создан, чтобы программисты были со всех сторон защищены от косячного кода (чтобы нельзя было отстрелить себе ногу как в С).

[bnytiki]

Dark Hole:
Как показала практика - этого можно добиться и меньшей многословностью.

[Dark Hole]

bnytiki: а можно писать на JS. Или удобно, или быстро.

[Rou1997]

bnytiki: "Никакие WPF не являются необходимыми"
WPF действительно избыточен для большинства задач, а вот на WinForms да и на VCL (Delphi) интерфейсы создаются именно очень просто и быстро, сам интерфейс создается без единой строчки кода, по вашей же ссылке eax.me/go-gkt-gui как я и ожидал предлагается писать все вручную, а на Windows это не одобрялось вообще никогда, Visual Basic 1.0 для Win 3.1 уже был "Visual", впрочем сторонники Линукса наоборот предпочитают мышке клавиатуру, следовательно, выбор зависит и от личных предпочтений, хотя напрашивается объективное мнение: предпочтения клавиатуры морально устарели.

Про многословность и параноидальность Java я с вами согласен, это так и есть, но Java - довольно старый язык, и даже Android 7.0 все еще наследует старые подходы от Линукса и Jav'ы.

[bnytiki]

Dark Hole: В языках со динамической типизацией - слишком много скрытых ошибок.
Писать на них быстрее - а вот отлаживать дольше.

[Dark Hole]

bnytiki: во-первых, ошибок нет. Просто есть не всегда очевидные вещи. И отладка необязательно дольше - с хорошим редактором производительность опытного программиста на JS где-то 90-95% от такого же, только на статике.

[bnytiki]

Dark Hole:
Уточняю формулировку

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

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

[Dark Hole]

bnytiki: опять вы непривильно выразились. От ошибок в алгоритме никто не спасет. А вот вы понимаете, почему JS именно динамически типизирован?

[bnytiki]

Dark Hole:
Если ошибка в алгоритме из-за, что не переменная не того типа заехала в функцию - от этого прекрасно спасает компилятор статически типизируемого языка.

[bnytiki]

Dark Hole:
JS потому просто он оказался на этом месте и в это время.
Вот и все.
На его месте мог оказаться и статически типизируемый язык.
Но исторически сложилось так как сложилось.

[Dark Hole]

bnytiki: это уже не ошибка алгоритма.

[bnytiki]

Dark Hole:
Это в статически типизируемых - не ошибка алгоритма. Потому что оно просто не пройдет в готовую программу.

В динамически типизируемых - как раз иногда нарочно используется в алгоритмах такие вещи.

[Dark Hole]

bnytiki: "исторический сложилось так" - распространенное заблужденнние. Дело в том, что в статически типизируемых языках существуют недоказуемые статически выражения. Одно дело - в статических их не так уж много, но в вебе их просто колоссальное количество. И JS тут, по большей части, не при чем.

[Dark Hole]

bnytiki: например? Программист на динамике перекладывает на интерпретатор совершенно другие вещи. Вместо того, что бы его утруждать проверкой собственного кода. Для компилятора, проверка кода один раз - вполне нормально, а если он будет в рантаме вам ошибки проверять...

[bnytiki]

Dark Hole:
Язык по факту в браузерах ОДИН-ЕДИНСТВЕННЫЙ.

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

Так что именно исторически сложилось что победил именно JS....при всех его недостатках, а ведь JS не пинал только ленивый. Тем не менее от него никуда не деться.

=======================

Никто не заморачивался "статической доказуемостью" когда шла война браузеров (на том этапе IE забил до смерти Netscape, но Netscape все же успел подложить нам всем свинью).

=======================

В статически типизируемых языках прекрасно решают это ваше "в вебе колоссальное количество". Было бы желание.
Писать кода больше, да, но решить можно.

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

И выбрали не Java, хотя были и у Java все шансы.

[bnytiki]

Dark Hole:
Для простых типов как "число" или "строка" - смешивание типов дурной тон даже в JS (хотя и возможно).

А вот для сложных объектов - в реальном коде JS постоянно происходит работа с "не понять каким типом, но будем надеется, что с тем что надо". Вполне естественным является передача в параметрах самых разных непредсказуемых объектов

[bnytiki]

Dark Hole:

Программист на динамике перекладывает на интерпретатор совершенно другие вещи. Вместо того, что бы его утруждать проверкой собственного кода. Для компилятора, проверка кода один раз - вполне нормально, а если он будет в рантаме вам ошибки проверять...

Ну во первых мне в рантайме ошибки не нужны вообще, когда отладка завершена.
Я сделал систему - и пошел заниматься другой системой, про эту забыл.

Во вторых это очевидно, что в динамически типизируемых языках работа обстоит по другому.

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

Правда, проверки эти не обязательны, они остаются на усмотрение программиста.
Что и позволяет программистам надеятся на авось, халявничать...

[Dark Hole]

bnytiki: насчет последнего, соглашусь. Недавно видел плэйер, который мог все, кроме перевода с момента на момент. Почему? Да потому, что NaN:NaN

[abcd0x00]

bnytiki:

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

Ничего там не вылезет, для этого есть юнит-тесты. Кто без них сейчас пишет? Если пишешь без тестов, там всё равно будет куча малозаметных логических ошибок. А если пишешь с тестами, то ничего не пропустишь независимо от типизации.

[bnytiki]

abcd0x00:
Ошибаетесь.
;)
Юнит тестов недостаточно.
Кроме TDD существует еще и BDD, но и этого недостаточно
;)

Кроме того, для статических тоже никто не мешает делать тесты.
;)

[slepowl]

Уоу, какой накал) Спасибо за отклик. по сабжу: про скорость разработки - это я взял из описания на язык во всяких вики.
Рython конечно взять можно, просто он перестал устраивать из-за танцев с запуском на винде для людей не знакомых с python, совместимости 2 и 3 версии (в том числе и модули), так же стала критичной скорость работы (нужна скорость для запуска сетевого потока данных с высокой частотой (мэк 61850-92).
Хочется чего-то простого как python, с возможностью быстрой разработки, низкоуровневого программирования, универсальности.

[slepowl]

С ГУИ может и переборщил) иногда нужен простой интерфейс, а веб использовать бывает не реально. Раньше делал delphi обертки на python (ну что знаю)) может на С# погляжу, спс.

[abcd0x00]

bnytiki:

Юнит тестов недостаточно.

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

[bnytiki]

abcd0x00:
Их таки надо делать. Туч чел писал, что никаких таких особых затрат по времени нет.