у них в changelog'ах к EAP8 - "Many debugger improvements due to the upgrade of Delve to 1.0.0-rc.1, that among many other fixes adds support for LLDB on macOS."

Методом правки .с файлов из пакета: https://github.com/simplereach/51degrees Удалось запустить эту либу на винде. С дебаггером. Проблема в том, что в сишных файлах есть вызовы функций, которые, судя по всему, доступны только в юниксах. Так вот для дебаггера при спользовании cgo надо ставить параметр -ldflags="-linkmode internal" А он видит эти функции и не может найти им определение. Решение для винды. Код: void fiftyoneDegreesMutexClose(const fiftyoneDegreesMutex *mutex) { pthread_mutex_destroy((pthread_mutex_t*)&mutex->mutex); } Ругается на pthread_mutex_destroy. Меняем на: void fiftyoneDegreesMutexClose(const fiftyoneDegreesMutex *mutex) { return; } И работает :)

Собственно, коммент в сишном файле говорит о том, что на винде это не используется: /** * GCC / PTHREAD SIGNAL IMPLEMENTATION - NOT USED BY WINDOWS */

Если кто-нибудь знает более правильное решение, прошу подсказать.

Более правильное решение в библиотеке добавить ifdef'ы для винды

Такие? #ifndef _MSC_VER

Они там есть. И все компилится, работает. Но когда хочешь дебажить с -ldflags="-linkmode internal" эти ifndef игнорируются. Видимо, баг

а зачем там вообще сишный код?

Гошная либа - обертка оригинальной сишной либы 51Degrees

Оригинальную либу писали разработчики этой базы девайсов.

А может проще по сишнокму коду написать гошный аналог?

В идеале - разумеется. Но это время

Так и вопрос в том что проще и быстрее - податься и костылять код Сишной либы или написать pure-Go имплементацию

Имхо, правильнее линкер бы поправить :) Или как он правильно называется. Чтобы ifdef'ы учитывал.

Всем привет, Есть такая книжка для веба, подойдёт ли она или есть лучше? https://www.amazon.com/Web-Programming-Sau-Sheong-Chang/dp/1617292567 Был бы признателен, если у кого-то есть PDF этой книжки и сможет поделиться файлом.

а что ты хочешь по вебу из неё узнать?

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

для этого книжка не особо нужна

ну ок-ок, еще грейсфул шутдаун

Понятно, я просто думал что книжка мне может рассказать больше.

У кого-нибудь есть проект небольшой блог или что-то такое. Посмотреть как веб пишут на го с хорошей практикой.

Хорошая практика это API на go делать, а рендерить страничку так себе занятие

да, но я пока что буду ренедрить страничку, потом под api буду делать. Переделать не сложно, если нормально все написать.

да, но я пока что буду ренедрить страничку, потом под api буду делать. Переделать не сложно, если нормально все написать.

Не думаю, что тебе потом это поделие на js фреймворк будет легко перенести)

просто хочу на react, все написать, но я его изучал он простой, но вот redux недоучил. Поэтому вначале так, а потом когда подтяну знания react+redux, переделаю.

я не буду сильно большую систему писать

я попробую так и так, основная цель не создать проект, а научиться писать быстро и правильно.

@ktryapitsin я так понимаю, я что-то не так делаю?)

@ktryapitsin я так понимаю, я что-то не так делаю?)

Не, я тут сам нубьё можно сказать, просто не понимаю зачем реакт если система небольшая, и почему не сделать сразу через апи в таком случае

потому что я нуб в go, и нуб в react. Я буду учиться пистаь на go и за одно напишу проект. а если я буду учить еще react+redux, это в двойне сложнее. --- Я как-то взял nodejs, react+redux, писал долго и в итоге не дописал.

еще есть vuejs

говорят проще гораздо

да, писал даже

но я хочу на react )

так как я давно хотел react+redux, научиться. Но постоянно откладывал, приходилось другие вещи изучать.

так как я давно хотел react+redux, научиться. Но постоянно откладывал, приходилось другие вещи изучать.

А зачем, можно поинтересоваться?)

А зачем, можно поинтересоваться?)

Фронтендерам платят много)

Так го это вроде как не про фронтенд)

разговор пошел про api, я написал причину почему пока api не хочу писатью

потому что я нуб в go, и нуб в react. Я буду учиться пистаь на go и за одно напишу проект. а если я буду учить еще react+redux, это в двойне сложнее. --- Я как-то взял nodejs, react+redux, писал долго и в итоге не дописал.

Учи. Годная, востребованная связка с Go.

вот поэтому и хочу, потом клиентскую часть на реакте написать ))

Учи. Годная, востребованная связка с Go.

Плюсую. Еще хочу добавить что по моему мнению react+go сложнее, чем react+redux+go, так как не надо мутить и писать стейт компонентов, их можно вообще через const MyComponen = function () { return <div></div> }

а связка Vue-Go ?

Vue это как light angular

Была статья про Vue и Go (на Echo), годная статья. Обсуждать почему react а не vue - не в этом чатике, я думаю. react популярнее и перспективнее, с vue на react переходят чаще чем с react на vue.

Вакансий на реакте больше

Я второй случай )

React => Vue ...

хех )

А с выходом fibers он ещё и быстрее будет, если писать на preact - то и компактнее.

fibers?

После FMP это слово вызывает нервный тик )

preact тоже слышал

React => Vue ...

охотно верю. на вкус и цвет как говорится. я для себя выбрал react из-за react native как переломный фактор

да и + мобильный сайт можно написать на native )

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

I like it

Хорошая практика это API на go делать, а рендерить страничку так себе занятие

Джанго и миллион подобных на пхп тоже рендерят на сервере в темплейтах

Джанго и миллион подобных на пхп тоже рендерят на сервере в темплейтах

Да, но по хорошему надо разделять как можно больше.

потому что я нуб в go, и нуб в react. Я буду учиться пистаь на go и за одно напишу проект. а если я буду учить еще react+redux, это в двойне сложнее. --- Я как-то взял nodejs, react+redux, писал долго и в итоге не дописал.

Отдавать жсоны - проще и быстрее чем рендерить хтмл и искать массивную хуйню типа джанги

А фронт можно и на голом ажаксе запилить

Фронт отдельно, бэк отдельно.

Потом на реакт перенесешь, апи уже готовое будет

https://github.com/caseylmanus/go-react-native

Фронт отдельно, бэк отдельно.

Это сейчас модно\стильно\молодежно, да?

ERROR: S client not available

Да, но по хорошему надо разделять как можно больше.

Нет

Т.е. шаблонизаторы в го не в почете?)

Джанго и миллион подобных на пхп тоже рендерят на сервере в темплейтах

Да, на них это удобнее чем на go делать, как минимум там нет строгой типизации

Это сейчас модно\стильно\молодежно, да?

Типа того, можешь глянуть на почти любой крупный сайт. Он на фронте собирается.

Есть конечно куча вордпрессов, но я бы не стал ориентироваться на них.

можно ли написать api на go. потом через другой контроллер его ловить и в шаблон go template. --- а потом переписать это дело на react+redux.

Да, на них это удобнее чем на go делать, как минимум там нет строгой типизации

Я бы поспорил бы в этом месте. Как раз с типами удобнее.

Я бы поспорил бы в этом месте. Как раз с типами удобнее.

Удобнее делать сайт и рендерить его через шаблоны?

Нет

Disadvantages 1. Client must enable javascript. Yes, this is a clear disadvantage of SPA. In my case I know that I can expect my users to have JavaScript enabled. If you can't then you can't do a SPA, period. That's like trying to deploy a .NET app to a machine without the .NET Framework installed. 2. Only one entry point to the site. I solve this problem using SammyJS. 2-3 days of work to get your routing properly set up, and people will be able to create deep-link bookmarks into your app that work correctly. Your server will only need to expose one endpoint - the "give me the HTML + CSS + JS for this app" endpoint (think of it as a download/update location for a precompiled application) - and the client-side JavaScript you write will handle the actual entry into the application. 3. Security. This issue is not unique to SPAs, you have to deal with security in exactly the same way when you have an "old-school" client-server app (the HATEOAS model of using Hypertext to link between pages). It's just that the user is making the requests rather than your JavaScript, and that the results are in HTML rather than JSON or some data format. In a non-SPA app you have to secure the individual pages on the server, whereas in a SPA app you have to secure the data endpoints. (And, if you don't want your client to have access to all the code, then you have to split apart the downloadable JavaScript into separate areas as well. I simply tie that into my SammyJS-based routing system so the browser only requests things that the client knows it should have access to, based on an initial load of the user's roles, and then that becomes a non-issue.)

Ну и ещё они хуево индексируются

Удобнее делать сайт и рендерить его через шаблоны?

Да.

Ну и ещё они хуево индексируются

Гугл с яндексом уже давно js выполнять научились.

Да.

Ну ок, ещё кто-то игры на go делает

я начну с веб сайта, для практики. потом буду дмать что посложней сделать. ))

Ну и ещё они хуево индексируются

Уже нет. яндекс, гугл, бинг

Ну ок, ещё кто-то игры на go делает

Мнение твоё, но я бы на твоём месте всё-таки глянул на такую архитектуру.

Завместо go для рендерингай сайта из шаблонов есть более эффективные вещи

Ой, запутался. В общем писать сложные проекты с типами удобнее.

Я это имел ввиду.

Поэтому появились jsx и typescript

Ой, запутался. В общем писать сложные проекты с типами удобнее.

Если под "удобнее" понимается защита от дурака-программиста - пожалуй, соглашусь

Если под "удобнее" понимается защита от дурака-программиста - пожалуй, соглашусь

Да нет, подсказки в IDE как минимум. Без типов ты их не получишь.

Хотя js в принципе такой язык... ну такой...

Да нет, подсказки в IDE как минимум. Без типов ты их не получишь.

Ну я об этом примерно и говорил

Хотя js в принципе такой язык... ну такой...

https://www.destroyallsoftware.com/talks/wat

Баян, но смешной

Больше всего в js доставляет что он умеет в самый неподходящий момент скастить null к строке из четырех символов

'null'? (лень пересматривать презентацию)

Да

Это не в презе

Это из личного опыта

гыгыгы