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

Я там интерфейс сделал. Можно любой сторедж будет подключить.

Есть смысл, я уж понял) пасиб!

Скоро, выложу, причешем...

https://github.com/mit-pdos/biscuit ого, чего творится! Мож кто соберёт?! ;)

Ядро было написано аспирантом MIT Cody Cutler в рамках исследования «The benefits and costs of writing a POSIX kernel in a high-level language» и доступно на GitHub странице MIT PDOS (Parallel and Distributed Operating Systems group at MIT CSAIL) под лицензией MIT.

Biscuit неплохо документирован и содержит 27 тысяч строк на Go, из которых всего 90 функций содержат небезопасные вызовы («unsafe»), необходимые для задач вроде доступа к регистрам процессора. Есть также небольшой загрузчик, написанный на ассемблере.

Особенности:

Многоядерность.
Управляемые ядром потоки.
Журналируемая файловая система.
Виртуальная память с поддержкой copy-on-write.
Реализация TCP/IP стека.
Поддержка AHCI SATA дисков.
Поддержка Intel 10Gb NIC.
Скомпилировать и опробовать ядро довольно просто:

git clone https://github.com/mit-pdos/biscuit.git
cd biscuit/src
./make.bash && make -C ../biscuit qemu CPUS=2
При этом сборка с нуля занимает всего 38 секунд, из которых 33 секунды приходится на немного модифицированный рантайм Go, и всего 5 секунд непосредственно на сборку ядра.
Интересны результаты исследования. После проведения тестов производительности на таких приложениях, как NGINX, Redis, и CMailbench — обнаружилось, что сравнение производительности эквивалентных путей кода на Си и на Go показало всего 15% разницы. Доля процессорного времени, потребляемого сборкой мусора и проверками безопасности, по результатам авторов статьи — составляет менее 15%.

Это интересно!))

Самому интересно) для каких-то специфических проектов самое то...

Всем привет!) Помогите плз, посмотрел весь интернет и библиотеку стандартную но не нашел ответа

в tcp connection с клиентом, я отправляю ему сообщение через client.Conn.Write(). Метод возвращает (n, error), n - количество отправленных байтов. Может быть такое что сервер будет перегружен или еще что-то, и в итоге я не смогу отправить все сообщение целиком

тогда получается n, мне покажет сколько байтов я отправил и придет какая-то ошибка. Как будет выглядеть ошибка? как мне сравнить error == ?

мой код

// writeMessage write message to client
func (c *client) writeMessage(msg []byte) error {
 sentSize := 0
 for sentSize != len(msg) {
  n, err := c.conn.Write(msg[sentSize:])
  if err != nil {
   sentSize += n
  }
 }
 return nil
}

Единственное что нашел, это в стандартной либе

Write must return a non-nil error if it returns n < len(p). Write must not modify the slice data, even temporarily.

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

есть ссылка на источник? Я никак протестить не могу

Write must return a non-nil error if it returns n < len(p). Write must not modify the slice data, even temporarily.

это из стандартной библиотеки, написано что если n < len(p) то придет ошибка

покажите где такое написано

хмм