Re: FlexBuffers

So here's how I think this fits into all the other different types of data serialization:

Schema-ful, copying: Protobuf, Thrift, plenty more

Schema-ful, zero-copy: Cap'n'proto, Flatbuffers

Schema-less, copying: Json (binary and other variants included), XML

Schema-less, zero-copy: Flexbuffers (Any others? This seems new to me)

uluyol, 8 hours ago

Друзья, мы опять live, в гостях Александр Валялкин https://www.youtube.com/watch?v=FYQ5uwqJC9I

Интересно, оказывается был такой пост 10+ дней назад, про отказ от TS во внутренних частях Deno.

- compile time when changing files takes several minutes
- isn’t proving itself helpful to organize Deno code
- и еще 3, которые сюда пихать не хочу :)

https://startfunction.com/deno-will-stop-using-typescript/

Re: Deno will stop using TypeScript

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds.

[1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw#

First paragragh of that document:

> Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

inimino, 4 hours ago

Сильная штука https://en.cppreference.com/w/cpp/filesystem/path/append

Язык настолько гибкий, что выпадает из рук https://docs.python.org/3/library/pathlib.html#operators

>>> p = PurePath('/etc')
>>> p
PurePosixPath('/etc')
>>> p / 'init.d' / 'apache2'
PurePosixPath('/etc/init.d/apache2')
>>> q = PurePath('bin')
>>> '/usr' / q
PurePosixPath('/usr/bin')

Ни разу это в живую не встречал, спасибо Алексею.

Приберу к рукам комент из треда:

Справедливости ради, выкладывание (временных) приватных ключей может иметь смысл. Например, вы можете наблюдать как некоторая публичная база данных (например, результаты голосования) меняется в реальном времени, сделать себе копию, убедиться в её целостности и так далее (при помощи известного заранее публичного ключа), но не можете расшифровать содержимое, пока вам не выдали приватный ключ (а его опубликуют, когда голосование завершится, например).

(еще оказывается это автор Mercurial, не знал 👀) А вот пойти найти это в nginx надо, интересно, зачем оно такое

DNS Push Notifications RFC появился на горизонте. Один из авторов из Apple, что позволяет спекулировать о том, что решения будет для мобильных устройств (почему - угадайте).

Как можно угадать по названию - расслыать изменения пользователям заранее, как только данные были изменены. Вещь конечно интересная, некоторые уже посмеялись про "сколько ж это времени уйдет на адаптацию".

https://www.rfc-editor.org/rfc/rfc8765.html

Странно, что никто не сказал о Nomad 0.12, а ведь приятно видеть апдейт.

Да как бы и HashiConf идёт, ток как-то тихо в ленте...

https://www.hashicorp.com/blog/announcing-hashicorp-nomad-0-12-beta/

Cloud Platform подъехал, я сперва подумал, что это будет абстракция на AWS, GCP, so on но это только для раскатки продуктов хашикорпа, но все равно прикольно.

https://www.hashicorp.com/blog/announcing-cloud-platform/?utm_source=twitter

a toy jvm in awk, based on this tutorial: zserge.com/posts/jvm

https://github.com/rethab/awk-jvm #ненормальное

Крутая штучка, советую лайкнуть

A sampling Go profiler that allows you to analyze On-CPU as well as Off-CPU (e.g. I/O) time together.

https://github.com/felixge/fgprof by twitter.com/felixge

And it's literally under 100 lines! Amazing!

Такие дела https://twitter.com/dhh/status/1275901955995385856

Какой хороший бенчмарк. Наверное. В общем меня привлёк 3й участник, да, на V lang, который я без стеснения называл скамом.

Как можно догадаться, если глянуть в код, то можно увидеть, как быстро работает echo на вашем epoll/kqueue https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/V/pico.v/main.v и https://github.com/S-YOU/picoev.v

Вопрос, зачем это бенчить оставлю открытым. Если пролистать (сильно) ниже, можно найти Go с роутером chi, выдающий "жалкие" 240к рпс. Что вполне себе хороший результат. Написано без пуллов и прочей магии, простое как палка.

Вещь конечно прикольная, но эхами меряться лучше не на публику.

Результаты конечно же https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=json

Маленькая ода для sync.Once в #go

А именно. Часто можно встретить какую-то операцию, которую нужно и можно сделать 1 раз. Это может быть и закрытие соединения в каком-то клиенте и часто инициализация каких-то вещей.

Так как многим хочется эти вещи еще и в разных горутинах дергать, приходится добавлять какие-то синхронизации. Конечно же проще всего бахнуть Mutex и забыть о проблемах, некоторые чуть изощряются и делают на каналах, на атомиках тоже, но ведь уже есть простое решение - sync.Once !

Это буквально 3 инта (мютекс 2 32битных содержит https://github.com/golang/go/blob/go1.14.4/src/sync/once.go#L18 опустим вопрос кешлиний и прочих веселостей) и на этом вся логика заканчивается. Самое главное, как по мне, что это заметно лучше читается:
- ты видишь sync.Once
- ты знаешь, что он выполнится 1 раз
- ты знаешь, что по другому его не использовать

Эт круто.

Сюда же добавлю select {} который просто заблочит горутину (часто испоользую в main), поэтому другие решения (через бесконечный цикл, чтение из неиспользуемого канала) по сути не нужны.