Size: a a a

2020 December 12

AH

Ayrat Hudaygulov in pro.net
ничоси
источник

AH

Ayrat Hudaygulov in pro.net
а как на свифте чот пишут?
источник

E

EgorBo in pro.net
во времена второго на нем писали только совсем хипсто стартапы однодневки
источник

E

EgorBo in pro.net
писали сразу в урну
источник

A

Aloraman in pro.net
Сравнимо с первым netcore или хуже?
источник

E

EgorBo in pro.net
что говорить если аби стабилизировался только с 5ым свифтом
источник

E

EgorBo in pro.net
+ у свифта та же проблема что и плюсов нерешаемая - ллвм бэк
источник

E

EgorBo in pro.net
медлительный
источник

E

EgorBo in pro.net
правда у обжси тожн
источник

NT

Nikita Tsukanov in pro.net
Aloraman
Сравнимо с первым netcore или хуже?
Первый неткор был вполне ок
источник

A

Aloraman in pro.net
Nikita Tsukanov
Первый неткор был вполне ок
Со всем мясом в виде dnx? Впрочем , тут говорят что на Swift приходилось даже свой Substring писать, так что первый кор не настолько хипстоват
источник

NT

Nikita Tsukanov in pro.net
Aloraman
Со всем мясом в виде dnx? Впрочем , тут говорят что на Swift приходилось даже свой Substring писать, так что первый кор не настолько хипстоват
А оно не мешало
источник

NT

Nikita Tsukanov in pro.net
Мясо это
источник

NT

Nikita Tsukanov in pro.net
Для гринфилд-проектов было вполне ок всё
источник

A

Aloraman in pro.net
Для гринфилда - да, но хипстота ж хочет существующий продукт переписать всегда. У меня такое ощущение было, что первый кор ок для гринфилда, но с риском что все может улететь в урну, если второй кор будет вообще не совместим/пойдет по пути WinJS
источник

A

Aloraman in pro.net
С Убером вот же ситуация - ни разу не гринфилд, взялись переписывать, огребли все проблемы early adopters, могли бы вылететь в трубу если б Apple не поднимала лимиты на размер приложения, дважды (!). В итоге слили тысячи килобаксов, а на выходе "вообще хорошо вышло, архитектура стала понятной" - а такое случается просто от факта переписывания, а не смены языка/стека.
источник

LY

Lev Yas in pro.net
EgorBo
We also replaced *all* of our Swift structs with classes. Value types in general have a ton of overhead due to object flattening and the extra machine code needed for the copy behavior and auto-initializers etc. This saved us space so we pressed on.
Гы, я по умолчанию в своём вычислительном проекте сделал классы точек с доп информацией помимо координат. Стало интересно, сработают ли структуры лучше, не сработали, больше тратилось памяти и хуже перфоманс.
источник

LY

Lev Yas in pro.net
Прочитал тред. Хорошо что я не в мобильной разработке 😄
источник

D

Denisio in pro.net
мы тут недавно оптимизирвали кое какие расчёты и переделали аллокации на использование ArrayPool<T>, расход памяти стал в разы ниже
источник

D

Denisio in pro.net
и за счет более редкого прихода GC - скорость расчётов выросла почти в  два раза
источник