nats лучше

но проблем с gc я там не наблюдал

NATS вполне написан и работает

вы его использовали? я в первый раз сталкиваюсь

а их там и нет

вы его использовали? я в первый раз сталкиваюсь

тестировали

тестировали

а в чем проблемы были?

nats лучше

Чем?

не падает

и как оно? реально готовая альтернатива кафки или сыровато пока?

А nsq падает? При каких условиях?

не падает

лучше расскажи как себя ведет когда падает

:)

как пример нагруженного, большого проекта, centrifugo

я не знаю, на самом деле

потому что пока не падают - они все котики

мы его тестили, но в прод так и не взяли

nsq у нас и на тестах падал, под нагрузкой

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

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

в чем противоречие между «пилить круд» и «генерить круд из сваггер схемы» о мой немогущий в логику друг?

простите, не удержался

я вам не друг, коллега, у вас вечно бомбит

в чем противоречие между «пилить круд» и «генерить круд из сваггер схемы» о мой немогущий в логику друг?

Логично ж, одни слабые, другие сильные

тааааак

сильные обычно сами столы носят

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

Biscuit is a monolithic, POSIX-subset operating system kernel in Go for x86-64 CPUs. It was written to study the performance trade-offs of using a high-level language with garbage collection to implement a kernel with a common style of architecture. You can find the research paper about Biscuit here: https://www.usenix.org/system/files/osdi18-cutler.pdf https://github.com/mit-pdos/biscuit

10 Conclusions Our subjective experience using Go to implement the Biscuit kernel has been positive. Go’s high-level language features are helpful in the context of a kernel. Examination of historical Linux kernel bugs due to C suggests that a type- and memory-safe language such as Go might avoid real-world bugs, or handle them more cleanly than C. The ability to statically analyze Go helped us implement defenses against kernel heap exhaustion, a traditionally difficult task. The paper presents measurements of some of the performance costs of Biscuit’s use of Go’s HLL features, on a set of kernel-intensive benchmarks. The fraction of CPU time consumed by garbage collection and safety checks is less than 15%. The paper compares the performance of equivalent kernel code paths written in C and Go, finding that the C version is about 15% faster. We hope that this paper helps readers to make a decision about whether to write a new kernel in C or in an HLL. чет я ожидал, что будет сильно хуже. а тут прям бери и пиши

10 Conclusions Our subjective experience using Go to implement the Biscuit kernel has been positive. Go’s high-level language features are helpful in the context of a kernel. Examination of historical Linux kernel bugs due to C suggests that a type- and memory-safe language such as Go might avoid real-world bugs, or handle them more cleanly than C. The ability to statically analyze Go helped us implement defenses against kernel heap exhaustion, a traditionally difficult task. The paper presents measurements of some of the performance costs of Biscuit’s use of Go’s HLL features, on a set of kernel-intensive benchmarks. The fraction of CPU time consumed by garbage collection and safety checks is less than 15%. The paper compares the performance of equivalent kernel code paths written in C and Go, finding that the C version is about 15% faster. We hope that this paper helps readers to make a decision about whether to write a new kernel in C or in an HLL. чет я ожидал, что будет сильно хуже. а тут прям бери и пиши

лень читать простыню, как они без ос запилили рантайм?

10 Conclusions Our subjective experience using Go to implement the Biscuit kernel has been positive. Go’s high-level language features are helpful in the context of a kernel. Examination of historical Linux kernel bugs due to C suggests that a type- and memory-safe language such as Go might avoid real-world bugs, or handle them more cleanly than C. The ability to statically analyze Go helped us implement defenses against kernel heap exhaustion, a traditionally difficult task. The paper presents measurements of some of the performance costs of Biscuit’s use of Go’s HLL features, on a set of kernel-intensive benchmarks. The fraction of CPU time consumed by garbage collection and safety checks is less than 15%. The paper compares the performance of equivalent kernel code paths written in C and Go, finding that the C version is about 15% faster. We hope that this paper helps readers to make a decision about whether to write a new kernel in C or in an HLL. чет я ожидал, что будет сильно хуже. а тут прям бери и пиши

memory safe Go?! Kernel?! are u d@cking kidding guys?!

лень читать простыню, как они без ос запилили рантайм?

модифицировали гошный, добавив 1500 строк ассеблера

модифицировали гошный, добавив 1500 строк ассеблера

интересно, надо будет на досуге почитать

интересно, надо будет на досуге почитать

Статья довольно простая и подробная

Need a new kernel? Use a proper systems programming language: https://www.redox-os.org писать OS kernel на языке без статической безопасности, GC и относительно слабой оптимизацией компилятором это блин просто маразм как по мне..

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

люди взяли и запилили

и выводы их позитивные

если там все через unsage.Pointer, то го от си ничем не отличается)

я вот читаю — судя по всему на бенчмарках они сравнивали по сути производительнсть ассемблерной части бисквита с ядром на C и всё на unsafe.Pointer насколько я понимаю ну такое опять же, как гошный GC себя поведёт в долгом режиме работы — бабка надвое сказала В общем-то подобные ядра пишут и писали на любом языке, вплоть до js и lua к тому же они по сути сделали borrow checker а-ля руст для написания ядра с другой стороны работа всё-таки интересная, правда код, судя по всему, увидеть нельзя

мы его закрыли

это очень грустно

я вот читаю — судя по всему на бенчмарках они сравнивали по сути производительнсть ассемблерной части бисквита с ядром на C и всё на unsafe.Pointer насколько я понимаю ну такое опять же, как гошный GC себя поведёт в долгом режиме работы — бабка надвое сказала В общем-то подобные ядра пишут и писали на любом языке, вплоть до js и lua к тому же они по сути сделали borrow checker а-ля руст для написания ядра с другой стороны работа всё-таки интересная, правда код, судя по всему, увидеть нельзя

про borrow checker там что нибудь написано?

я вот читаю — судя по всему на бенчмарках они сравнивали по сути производительнсть ассемблерной части бисквита с ядром на C и всё на unsafe.Pointer насколько я понимаю ну такое опять же, как гошный GC себя поведёт в долгом режиме работы — бабка надвое сказала В общем-то подобные ядра пишут и писали на любом языке, вплоть до js и lua к тому же они по сути сделали borrow checker а-ля руст для написания ядра с другой стороны работа всё-таки интересная, правда код, судя по всему, увидеть нельзя

https://github.com/mit-pdos/biscuit

https://github.com/mit-pdos/biscuit

спасибо

про borrow checker там что нибудь написано?

Ну не совсем BC, но очень похоже на рустовские проверки 6.3 Static analysis to find s We have developed a tool, M AX LIVE, that analyzes the Biscuit source code and the Go packages Biscuit uses to find s for each system call. The core challenge is detecting statically when allocated memory can no longer be live, since many system calls allocate memory for transient uses. Other challenges include analyzing loops with non-constant bounds, and determining reservations for background kernel activities that are not associated with a specific system call.

hmmm

Ну не совсем BC, но очень похоже на рустовские проверки 6.3 Static analysis to find s We have developed a tool, M AX LIVE, that analyzes the Biscuit source code and the Go packages Biscuit uses to find s for each system call. The core challenge is detecting statically when allocated memory can no longer be live, since many system calls allocate memory for transient uses. Other challenges include analyzing loops with non-constant bounds, and determining reservations for background kernel activities that are not associated with a specific system call.

Ну по факту Роман прав, что писали на го, а изобрели руст :)

кстати мне сегодня во сне мысль пришла.. func Take(mutableInt int) { /*...*/ } func main() { var immutableInt immut int = 42 Take(immutableInt) // Compile-time error } поумолчанию, следуя правилам, мы не можем принять immut int как mut int потому-что immut->mut casting нелегально но... это-ж скалярный тип.. он же всё-равно копируется.. для него же можно сделать исключение и разрешить в данном случае данный cast. Т.е. разрешить casting скалярных иммут в мут (но только скалярных).

?

кстати мне сегодня во сне мысль пришла.. func Take(mutableInt int) { /*...*/ } func main() { var immutableInt immut int = 42 Take(immutableInt) // Compile-time error } поумолчанию, следуя правилам, мы не можем принять immut int как mut int потому-что immut->mut casting нелегально но... это-ж скалярный тип.. он же всё-равно копируется.. для него же можно сделать исключение и разрешить в данном случае данный cast. Т.е. разрешить casting скалярных иммут в мут (но только скалярных).

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

эднако это актуально только в случае mutability by default, в ином случае когда поумолчанию всё имутабельно такой проблемы быть не должно

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

нет. ? я не предлагаю Ownership & Borrowing, лишь compile-time mutability safety)

workflow не сильно изменится, а вот O&B меняет workflow коллосально

Результаты бенчмарков Go 1.0 c Go 1.11 от Дейва Чейни. ?? https://gist.github.com/davecheney/311169ef04e27fe469ca91859af9cdff

Результаты бенчмарков Go 1.0 c Go 1.11 от Дейва Чейни. ?? https://gist.github.com/davecheney/311169ef04e27fe469ca91859af9cdff

Что думаем? Как добились?

_ <- chanOrders cannot use _ as value ?

Все же пройди готур

Докер на всех системах есть ?

На Андроиде, например, нету

на ios тоже

добрый вечер подскажите как реализовать url с переменным значением ПР. Route::get('/blog/{id}/{title} в ларавеле

добрый вечер подскажите как реализовать url с переменным значением ПР. Route::get('/blog/{id}/{title} в ларавеле

Взять любой роутер, например, chi

ERROR: S client not available

Go 2.0 не будет ещё очень долгое время, лет эдак 5

Go2 это лишь маркетинговое название Go 1.13 and beyond

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

потому-что сама спефицификация языка не ломается, но вот старый код может не скомпилиться по причине конфликтов имён символов с новыми ключевыми словами

Взять любой роутер, например, chi

а нативными средствами есть возможость

а нативными средствами есть возможость

руками парсить r.Url.Path

руками парсить r.Url.Path

есть ли где нибудь функционал чтоб выделить из url эти переменные

есть ли где нибудь функционал чтоб выделить из url эти переменные

регулярка

спасибо пойду разбираться

не мучай себя, если речь не идет о паре хэндлеров. возьми chi

еще вопрос если я изменю r.Url.Path то ответ же придет

зачем?

не мучай себя, если речь не идет о паре хэндлеров. возьми chi

это уже готовый сервис и надо быстро переделать примерно 25 урлов не трогая остальные я в мидлваре буду паристь и в контекст писать

это уже готовый сервис и надо быстро переделать примерно 25 урлов не трогая остальные я в мидлваре буду паристь и в контекст писать

нормально. пиши в контекст, а не в r.Url.Path

понял спасибо

но все же если я изменю r.Url.Path то ответ придет или нет

зачем?

это запрос. запрос не надо менять.

не понял о чем вы

r.Url.Path - это урл запроса. Запрос менять не надо.

оставил пост запросы

Добрый вечер

Мужики а что сейчас популярно из franework - ов на ГО ?

Мужики а что сейчас популярно из franework - ов на ГО ?

standard library

По большей части для API нужен

А кроме стандартных ?

По большей части для API нужен

https://github.com/MarlikAlmighty/examplefasthttp Если конечно понравится.

А что на счёт GIN или Echo ?