Как стать автором
Обновить

Комментарии 30

Python не требует специфической иерархии каталогов

Вы уверены? Модули же надо как-то организовывать.
Рискну дать совет: не используйте фреймворки в Go. То есть набор полезных пакетов (типа Gorilla) — само собой. А вот всё, что несёт свою идиоматику (вроде Gin), или привносит магию в код — с большой осторожностью.
Даже больше того, на мой взгляд, в Go нет толковых и действительно необходимых фреймворков.
И, кстати, в Go слабая типизация, как и в Си. (Но статическая, да)
Вот прямо +++, хочется подписаться под каждым словом. Не хватает только рекомендации Chi: github.com/go-chi/chi
Всячески поддерживаю! Очень удобный роутер, который логично работает с нативным net/http!
Что вы называете слабой типизацией?
Такой код на Go не скомпилируется:
package main
  
type A int
type B int

func main() {
        var a A
        var b B
        a = 1
        b = a
}


Вылетит ошибка
cannot use a (type A) as type B in assignment


А такой код на Си не выведет даже warning'а (в последнем gcc). Даже с -Wall и -Wextra:
typedef int A;
typedef int B;

int main( void )
{
        A a;
        B b;
        a = 1;
        b = a;
}
Я ничего не называю, это всё термины. ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B8_%D1%81%D0%BB%D0%B0%D0%B1%D0%B0%D1%8F_%D1%82%D0%B8%D0%BF%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Для программиста это всё явно не видно и с помощью кода вряд ли можно продемонстрировать.
В Go слабая статическая типизация. В Python типизация динамическая (слабая или сильная — не знаю).
Я всегда полагал, что неявные приведения типов (яркий пример которого на Си я написал выше) — атрибут слабой типизации.
P.S. В Python считается, что строгая типизация (насколько она может быть строгой в динамически типизированном языке).
Приведение типов средой исполнения — динамическая типизация. Она может быть сильной или слабой, зависит от внутренней реализации языка. Про слабую типизацию в Go на Гитхабе писал один из разработчиков языка. Ну и логично, Go ведь пошёл от Си, а Си — известный пример языка со статической но слабой типизацией.

Сильная/строгая (strong) и слабая (weak) типизации — это про явное и неявное приведение типов. У Go строгая типизация, так как приведение типов всегда явное.


Касательно информации от разработчика Go, то подозреваю, что имеется в виду этот известный комментарий от Ian Taylor. Увы, но в нём речь идёт не о типизации (typing), но о системе типов (type system). Понятия хоть и связанные, но все же разные. Слабая система типов Go выражается в том, что шаг вправо/влево, и уже приходится чертыхаться с interface{}, теряя гарантии проверки корректности типов на этапе компиляции (ошибка несоответствия типа выстрелит только во время выполнения). И Ian Taylor сообщает, что это как раз сделано намеренно, дабы программисты "писали код, а не типы".

Полезно.
НЛО прилетело и опубликовало эту надпись здесь

Ну вот в brainfuck, к примеру, программисты как раз и пишут "код", а не функции =)


Я понимаю вашу позицию, я и сам её сторонник. Но разработчики Go спроектировали язык именно так под свои задачи. Им надо именно такой трейд-офф. Нам лишь остаётся либо пользоваться этим инструментом, либо выбрать другой. Каждый сам решает.

Кстати, в Go тоже есть неявное приведение типов. Думаю что в вашем же примере каждый из пользовательских типов получится присвоить переменной базового — int — без явного приведения.
Не получилось. Что я делаю не так?
package main
  
type A int
type B int

func main() {
        var a A
        var b B
        var i int = 3
        a = 1
        b = 1
        a = i
        println(a)
        println(b)
}

cannot use i (type int) as type A in assignment

Go пошёл не только от Си:
Go's heritage is at least as much Oberon as it is C!
Вот в этой книге см. 13 страницу.

И Go изначально задумывался сильно-типизированным:
essentially strongly typed, but probably w/ support for runtime types
Вот так, к примеру, можно. Но это всё ерунда бесполезная.
package main

import "fmt"

type A [1]int

func main() {
	var a A
	i := [1]int{3}
	a = i
	fmt.Println(a)
	fmt.Println(i)
}


[3]
[3]
Это уже не простые типы, а коллекции. Если бы в Go была такая штука как structural equality (и, соотв., inequality ), то этот код, наверное, тоже не собрался. Но это другой уровень, Clojure, F#, Haskell
Здесь одинаковый тип элементов, как выше и написали.

И из не приведенных примеров, в Go нельзя без явного приведения типов смешивать очень близкие типы, например сложить байт и инт, или знаковое с беззнаковым.
Это непривычно первое время, но защищает от ошибок и позволяет делать удобные вещи типа 5*time.Second (имеющий тип).

Все же считаю Go языком со строгой типизацией, в отличие от C.
Переводчики а можно не подменять понятия?
Нативный параллелизм

В оригинале
Native concurrency

И это важно потому что:
Concurrency is not parallelism
А как перевести корректнее? Во всех книжках именно параллелизм (Донован-Кериган, что-то ещё вроде было на русском). Есть какой-то устоявшийся термин?
Думаю, что можно так и написать, конкурентность.
Э… А как можно перейти из Python в Go? Как в дополнение к Python выучить Go я понимаю — языки взаимодополняющие, но как перейти — нет. Языки почти не пересекаются по назначению. Да, Python когда-то начинал как скриптовый язык (роднит с Go), но Python сейчас это про сложную бизнес-логику или математику, а Go про инфраструктурные задачи без бизнес-логики.

Может автор изначально ошибся в языке?

Мне всегда казалось, что сложную бизнес логику пишут на Java или C#. Тогда как Python больше про скорость разработки для стартапов и науки. Мимо этого заблуждения ещё можно пройти.


Но записать Go в скриптовые языки (да даже в статье упоминаются статическая типизация и компиляция)! Это на грани добра и зла.

Как скриптовый язык Go вполне себе. Не Powershell, конечно, но можно применять.
Запускать можно go run — одной командой. Модуль OS имеется.
У Go настолько быстрый компилятор, что иногда он быстрее компилируется и запускается (go run, как тут уже ответили), чем Python.
И тем не менее система сборки в Android — использует Go именно как скриптовый язык.

Причём она очень забавно сделана: если в других системах сборки либо всё декларативно и иногда что-то очень сложно сделать, то тут — есть дуализм. С одной стороны есть достаточно простой декларативный формат Android.bp, с другой — если нужно что-то хитрое, то можно дописать модуль на Go в soong.

Разумеется при изменении и того и другого всё, прозрачно для пользователя, пересобирается и перезапускается… чем не скрипт?
Казалось бы, как раз таки на Go писать много логики проще и надежнее, чем на Python.
Вот для небольшой и выразительной математики да, лучше Python, из-за его сишных библиотек и особенностей синтаксиса. Но что-то большое и сложное на нем писать странно.

у меня вопрос в тему:
люди добрые, а подскажите чем в go можно заменить pytest, django orm и django rest framework?

В части ORM-фреймворков — ничем. Go прекрасный инструмент для другого. В части же тестирования — см. goconvey.co
ещё для тестов можно использовать ginkgo
Зарегистрируйтесь на Хабре, чтобы оставить комментарий