V
Size: a a a
2020 November 19
V
Хорошо сказано
m
Привет. Хочется странного :)
Нужно вызывать код на Go из С - всё получается под Linux/gcc.
Но Windows/MSVC - go build -buildmode=c-archive хочет gcc. Но компилятор обязательно cl.exe или в крайнем случае clang-cl.
Собственно вопрос: умеет ли golang делать виндовый static lib (точнее для msvc) или хотя бы dll?
Нужно вызывать код на Go из С - всё получается под Linux/gcc.
Но Windows/MSVC - go build -buildmode=c-archive хочет gcc. Но компилятор обязательно cl.exe или в крайнем случае clang-cl.
Собственно вопрос: умеет ли golang делать виндовый static lib (точнее для msvc) или хотя бы dll?
x
на php (если брать fpm) нету никакого смысла писать микросервисы - там каждый запрос это отдельный микросервис - крашнулся и ладно.
На Go, даже с recover отдельных вызовов ситуация не такая радужная.. появляется понятие statefull приложений с долгой инициализацией, где монолит становится рискованной затеей.
Если подходить более философски,за что я всегда топлю - в некотором смысле скорость процессинга данных выросла настолько, что в пару порядков опередила скорость реакции пользователя. Это значит, что сколько бы микросервисов не было, сетевые задержки в современном мире позволяют строить любые юниты достаточно атомарно. Упрощается поддержка, тестирование, защита от "падучек". Увеличивается значимость архитектуры, речь идет о верном комбинировании юнитов, а может даже и FaaS
На Go, даже с recover отдельных вызовов ситуация не такая радужная.. появляется понятие statefull приложений с долгой инициализацией, где монолит становится рискованной затеей.
Если подходить более философски,за что я всегда топлю - в некотором смысле скорость процессинга данных выросла настолько, что в пару порядков опередила скорость реакции пользователя. Это значит, что сколько бы микросервисов не было, сетевые задержки в современном мире позволяют строить любые юниты достаточно атомарно. Упрощается поддержка, тестирование, защита от "падучек". Увеличивается значимость архитектуры, речь идет о верном комбинировании юнитов, а может даже и FaaS
Казалось бы, какое отношение способ запуска и хранения состояния имеет к микросервисам.
D
на php (если брать fpm) нету никакого смысла писать микросервисы - там каждый запрос это отдельный микросервис - крашнулся и ладно.
На Go, даже с recover отдельных вызовов ситуация не такая радужная.. появляется понятие statefull приложений с долгой инициализацией, где монолит становится рискованной затеей.
Если подходить более философски,за что я всегда топлю - в некотором смысле скорость процессинга данных выросла настолько, что в пару порядков опередила скорость реакции пользователя. Это значит, что сколько бы микросервисов не было, сетевые задержки в современном мире позволяют строить любые юниты достаточно атомарно. Упрощается поддержка, тестирование, защита от "падучек". Увеличивается значимость архитектуры, речь идет о верном комбинировании юнитов, а может даже и FaaS
На Go, даже с recover отдельных вызовов ситуация не такая радужная.. появляется понятие statefull приложений с долгой инициализацией, где монолит становится рискованной затеей.
Если подходить более философски,за что я всегда топлю - в некотором смысле скорость процессинга данных выросла настолько, что в пару порядков опередила скорость реакции пользователя. Это значит, что сколько бы микросервисов не было, сетевые задержки в современном мире позволяют строить любые юниты достаточно атомарно. Упрощается поддержка, тестирование, защита от "падучек". Увеличивается значимость архитектуры, речь идет о верном комбинировании юнитов, а может даже и FaaS
вы сильно ошибаетесь в понимании того что такое микросервис.
D
подскажите пожалуйста по цикличным импортам
есть пакет Server - в нем типы, интерфейсы и тп для работы сервера
генерация создала моки которые в пакете mocks и которые импортируют пакет Server для того чтобы возвращать типы нужные из функций
и вот при попытке протестировать методы в пакете Server получаю циклический импорт
тесту нужен мок структуры из пакета Server и я импортирую mocks, этот мок импортирует Server и получаем циклическую зависимость
как правильно располагать моки и тп ?
есть пакет Server - в нем типы, интерфейсы и тп для работы сервера
генерация создала моки которые в пакете mocks и которые импортируют пакет Server для того чтобы возвращать типы нужные из функций
и вот при попытке протестировать методы в пакете Server получаю циклический импорт
тесту нужен мок структуры из пакета Server и я импортирую mocks, этот мок импортирует Server и получаем циклическую зависимость
как правильно располагать моки и тп ?
А
вынеси интерфейсы
D
выносить интерфейсы в отдельный пакет ?
D
типа Interfaces?
x
Интерфейсы должны быть в том принимающем пакете.
Это не всегда возможно, но желательно.
То есть, есть функция:
То интерфейс
Это не всегда возможно, но желательно.
То есть, есть функция:
func SomeFunc(i SomeInterface) { ... }То интерфейс
SomeInterface должен быть объявлен в этом же пакете.А
Да, либо как Валентин говорит, или если лень то отдельно
D
Интерфейсы должны быть в том принимающем пакете.
Это не всегда возможно, но желательно.
То есть, есть функция:
То интерфейс
Это не всегда возможно, но желательно.
То есть, есть функция:
func SomeFunc(i SomeInterface) { ... }То интерфейс
SomeInterface должен быть объявлен в этом же пакете.так оно так и есть. интерфейс обьявлен в пакете Server
D
а мок на этот интерфейс в пакете mocks
x
а мок на этот интерфейс в пакете mocks
А зачем пакет
Пакет с моками ничего не должен импортировать, он должен просто реализовать нужные интерфейсы.
server импортируется в пакете mocks?Пакет с моками ничего не должен импортировать, он должен просто реализовать нужные интерфейсы.
D
А зачем пакет
Пакет с моками ничего не должен импортировать, он должен просто реализовать нужные интерфейсы.
server импортируется в пакете mocks?Пакет с моками ничего не должен импортировать, он должен просто реализовать нужные интерфейсы.
А интерфейс возвращает тип который объявлен в сервер пакете. Для этого моки импортируют сервер
x
А интерфейс возвращает тип который объявлен в сервер пакете. Для этого моки импортируют сервер
1. Что значит интерфейс возвращает тип?
2. Вам не надо явно использовать интерфейс, просто используйте структуру, которая его реализовывает. Утиная типизация это позволяет и в большинстве случаев подразумевает
2. Вам не надо явно использовать интерфейс, просто используйте структуру, которая его реализовывает. Утиная типизация это позволяет и в большинстве случаев подразумевает
D
1. Что значит интерфейс возвращает тип?
2. Вам не надо явно использовать интерфейс, просто используйте структуру, которая его реализовывает. Утиная типизация это позволяет и в большинстве случаев подразумевает
2. Вам не надо явно использовать интерфейс, просто используйте структуру, которая его реализовывает. Утиная типизация это позволяет и в большинстве случаев подразумевает
Type client interface
GetUser() User
GetUser() User
D
И вот юзер объявлен в сервере.
D
И моку нужно импортировать сервер что добраться до этого юзера и вернуть его
x
И вот юзер объявлен в сервере.
Вы крайне непонятно описываете проблемы, и поэтому вам очень тяжело помочь.
Почему у вас
Пользователь к серверу никакого отношения не имеет и не может иметь. Выносите эту сущность в другой слой.
Кроме того, не совсем понятно,
Почему у вас
User объявлен в пакете server?Пользователь к серверу никакого отношения не имеет и не может иметь. Выносите эту сущность в другой слой.
Кроме того, не совсем понятно,
GetUser() - это метод сервера? Если да, то в честь чего?