и зависит всё от того, что решит компилятор

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

не что решит компилятор, а что написано в исходниках

а там написано - вернуть слайс, указывающий на тот же буфер

ты ссылку кидал на strings, а не на компилятор

Кто был на Badoo'шном митинге. Доклады уже выложили где-нибудь?

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

компилятор не волшебник, он делает то, что написано в программе. А в программе _нет_ копирования буфера при вызове string.Trim

О чем я и сказал в самом начале

спасибо, так лучше :))

компилятор не волшебник, он делает то, что написано в программе. А в программе _нет_ копирования буфера при вызове string.Trim

https://play.golang.org/p/wzdfGHLWeTT

хотя нет, гоню, нужен другой способ

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

Да, это структура, описывающая строку скопировалась.

нужно вытащить указатель на блок данных ?

какой то подтекст?)

https://play.golang.org/p/7JIfsW3vEyW

?

т.е. получается реально одна строка, но с разной длиной?

прикольно

https://play.golang.org/p/DNiDotpJNDn - а вот пример с TrimSpace

нужно вытащить указатель на блок данных ?

говорю же, прогнал) отправил, а потом понял, что ансейфом нужно было приправить)

https://play.golang.org/p/DNiDotpJNDn - а вот пример с TrimSpace

да, это я уже понял, я тестил на более старой версии, где происходило копирование

Trim прямо копировал строку? Это странно, конечно, ну да ладно. Кстати, это пример, почему иммутабельные строки - это хорошо. Можно делать вот такие выкрутасы с подстроками очень эффективно.

хм, а как в этом случае GC определит, что блок данных можно освободить? :S

или я туплю?

GC просто умный :) Я не знаю, как он работает, но, думаю, не освобождает блок, пока ссылки на него есть.

(As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. The alternative, which we tried and rejected, is to make string slicing so expensive—an allocation and a copy—that most programs avoid it.)

не умный

?

вообщем нет, я не туплю ?

Он не умный но вы умнее. Так что вы сами должны знать когда вы имеете дело с большой строкой и маленькой подстрокой а когда строка небольшая и можно оставитьв мпамяти)

Классика же)

https://golang.github.io/dep/

не видел раньше - у dep сайт появился

не видел раньше - у dep сайт появился

Ну как сайт ... страничка, картинка, и несколько кнопок )

Ну как сайт ... страничка, картинка, и несколько кнопок )

с доками

а что еще там должно быть? доки да ссылка скачать

хм... и правда, доки есть

Думал, ссылка на wiki на гитхаб будет ))

они месяц назад сделали доку

https://golang.github.io/dep/blog/2018/01/23/announce-v0.4.0.html

(As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. The alternative, which we tried and rejected, is to make string slicing so expensive—an allocation and a copy—that most programs avoid it.)

а откуда это взято?

где хранить пул коннектов? вот у меня есть пакет database, в нем есть connect() который устанавливает соединение и Get() который возвращает *sql.DB, это нормалная реализация? Или нужно делать вот эту структуру с Env: куда ложить логгер, db, и прочее?

(As an aside, there is a well-known gotcha in Java and other languages that when you slice a string to save a small piece, the reference to the original keeps the entire original string in memory even though only a small amount is still needed. Go has this gotcha too. The alternative, which we tried and rejected, is to make string slicing so expensive—an allocation and a copy—that most programs avoid it.)

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

где хранить пул коннектов? вот у меня есть пакет database, в нем есть connect() который устанавливает соединение и Get() который возвращает *sql.DB, это нормалная реализация? Или нужно делать вот эту структуру с Env: куда ложить логгер, db, и прочее?

sync.Pool, не ?

пул коннектов я имею ввиду sql.DB, там же внутри есть уже пул

короче, где хранить *sql.DB

вот что я хотел узнать)

где хранить пул коннектов? вот у меня есть пакет database, в нем есть connect() который устанавливает соединение и Get() который возвращает *sql.DB, это нормалная реализация? Или нужно делать вот эту структуру с Env: куда ложить логгер, db, и прочее?

Глобальную переменную типа *sql.DB, в этом пакете установить соединение и везде пользоваться, чем плохо? Зачем Get?

ну т.е., у меня есть хендлеры, и в них передавать *sql.DB? а чем плохо database.Get().Query() делать?

ну или database.Get() и погнал

пул коннектов я имею ввиду sql.DB, там же внутри есть уже пул

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

короче, где хранить *sql.DB

Вот образец, за код не пинать, первая прожка на го. https://github.com/MarlikAlmighty/examplefasthttp

Зачем Get? database.DB.Query()

Зачем Get? database.DB.Query()

ну а инициализацию как сделать? Допустим, база ещё не поднялась. но приложуха уже должна что-то отвечать

пока sql.Open() поинтер будет нил, и потом будет race condition

Есть init

init блочит же

Инит лучше не юзать.

init блочит же

где можно поподробней почитать?

Инит, да, плохо. Или заранее, прочитать конфиг, соединение с базой сделать

где можно поподробней почитать?

напиши в init time.Sleep(time.Second * 60)

Да вон же наверху ссылка, написано криво, но смысл там понятен, там всего два файла.

И пока прога не проинициализируется, нахрена ей отвечать что-то?

И пока прога не проинициализируется, нахрена ей отвечать что-то?

потому что коннекты собираются в очередь

ERROR: S client not available

она должна отвечать ошибкой и не копить их, ну или копить пока не треснет

Нихрена не понял, у тебя нет соединения с базой, нет ничего, но уже есть коннекты?

ну да, люди долбят сайт

ну да, люди долбят сайт

Пока с базой не соединишься никуда всё-равно не поедешь

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

Сперва читаем конфиг, пусть пока долбят, мы их не слушаем. Согласно конфигу соединяемся с базой и т.п. мы никого не слушаем, зачем? Потом поднимаем хттп сервер

Те кто долбят моргнуть не успеют как это всё произойдёт

Или база на марсе?

проблема в том, что если база упала, а перед Go нету ничего (например, Nginx), то сайт будет валяться как труп

нужно отобразить какую-то ошибку

если ставишь вперед nginx

то он копит в пул соединения, если твой сокет или порт начинает отвечать

но тогда пул разростается, вариант с тем чтобы читать конфиг и валятся мертвяком с nginx спереди приемлем.

Ну дык если упала база, фактически и бэкенд накрылся, тада фронтенд должен ошибку отобразить.

тогда nginx будет отрисовывать ошибки

Какой пул?

Нет базы после старта, отвечай 500

Но коннект уже настроен, он будет реконектиться сам

Каждый день удивляюсь предметам спора в этом чате

Я ж ведь даже и не спорил

Вопрос изначально был о том, где хранить *sql.DB. В init() не вариант. Прямой доступ тоже как-то плохо. Что мешает где-то по тупняку сделать db = nil? Делаем Get() возвращающий поинтер на *sql.DB и connect() который коннектится к базе и подменяет поинтер через atomic.SwapPointer, чтобы гонки не было. Или я не прав?

Это даже лучше не слушать пока все инициализации не пройдут. Человек открывает страницу, а у него полосочка загрузки начинает медленно передвигаться, он не уходит пока у тебя приложуха стартует, секунд 20 ждёт, энжи также делает прежде чем 500 отдать. Потом у тебя запустился сервер и всем отдал инфу. А если ты сразу всем отдашь 500, а потом начнёшь конфиг читать, не все вернутся потом за инфой. Да и порт на котором принимать запросы разве не в конфиге?

Вопрос изначально был о том, где хранить *sql.DB. В init() не вариант. Прямой доступ тоже как-то плохо. Что мешает где-то по тупняку сделать db = nil? Делаем Get() возвращающий поинтер на *sql.DB и connect() который коннектится к базе и подменяет поинтер через atomic.SwapPointer, чтобы гонки не было. Или я не прав?

Там всё продумано, не нужен атомик!

И ты перед каждым запросом коннект типа поднимаешь?

мда, записывайтесь к Василию на курс вообщем

И больше не ешь эти грибы

Интересный вопрос. Если я в переменной храню указатель и в миллионе горутин его читаю, но только в одной пишу. При этом мне не важно прочитался старый указатель или новый. Состояние гонки может повредить указатель при одновременном чтении и записи и надо лочить?

go-database-sql.org вот это хорошо читать

go-database-sql.org вот это хорошо читать

Лучше вообще про рейсы почитать, наверно

Лучше вообще про рейсы почитать, наверно

Это я про предыдущую тему о базе

Интересный вопрос. Если я в переменной храню указатель и в миллионе горутин его читаю, но только в одной пишу. При этом мне не важно прочитался старый указатель или новый. Состояние гонки может повредить указатель при одновременном чтении и записи и надо лочить?

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

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