AN
Нашел, там похоже просто аналог котлиновской метадаты, не полноценный IR
Size: a a a
2020 March 23
AN
или что-то среднее...
I
Да, IR - это аналог Dotty.
I
Вернее, того, что лежит в tasty файлах.
SM
Мне в такие моменты всегда в голову лезет философский вопрос 🙂 А могло ли сообщество в исторической перспективе так скооперироваться, чтобы вместо двух проектов с удвоенной энергией разивать один 🤔
I
Мне в такие моменты всегда в голову лезет философский вопрос 🙂 А могло ли сообщество в исторической перспективе так скооперироваться, чтобы вместо двух проектов с удвоенной энергией разивать один 🤔
Нет, конкуренция - причина инноваций.
SM
Нет, конкуренция - причина инноваций.
Не, я прекрасно понимаю все выгоды параллельного развития конкурирующих проектов 🙂
Но лично для меня обсуждаемая задача как-то смахивает (целью) на LLVM или какой-нибудь Webkit. Вот не видется мне в ней большого скопления точек, которые могут стать конкурирующим преимуществом. Очень похоже на весьма сложную, но всё-таки на весьма конкретную техническую задачу.
Но лично для меня обсуждаемая задача как-то смахивает (целью) на LLVM или какой-нибудь Webkit. Вот не видется мне в ней большого скопления точек, которые могут стать конкурирующим преимуществом. Очень похоже на весьма сложную, но всё-таки на весьма конкретную техническую задачу.
SM
Ведь и Scala и Kotlin научились когда-то в байткод JVM 🙂 Чего бы также не взять и не научиться одновременно во что-нибудь другое (промежуточное) 😁
I
LLVM - это совсем не то. И IR, и TASTy - языко-специфичны и платформо-независимы, тогда как LLVM IR - языко-независим (хотя сишные UB так и пролезают тут и там) и таргетит только натив. Натянуть котлин и скалу на LLVM, чтобы он
1) хранил всю информацию о типах
2) его можно было несложно менять
3) всё это работало быстро
невозможно
Можно сделать 2 из 3, но все 3 - нет.
1) хранил всю информацию о типах
2) его можно было несложно менять
3) всё это работало быстро
невозможно
Можно сделать 2 из 3, но все 3 - нет.
SM
LLVM - это совсем не то. И IR, и TASTy - языко-специфичны и платформо-независимы, тогда как LLVM IR - языко-независим (хотя сишные UB так и пролезают тут и там) и таргетит только натив. Натянуть котлин и скалу на LLVM, чтобы он
1) хранил всю информацию о типах
2) его можно было несложно менять
3) всё это работало быстро
невозможно
Можно сделать 2 из 3, но все 3 - нет.
1) хранил всю информацию о типах
2) его можно было несложно менять
3) всё это работало быстро
невозможно
Можно сделать 2 из 3, но все 3 - нет.
Т.е. IR/TASTy сильно ближе к языку, чем к таргету? Я правильно понял мысль?
I
Именно так
SM
Благодарю за комментарии 🤝
I
Обращайтесь!
AN
С дотти всегда вопрос возникает - доплывет ли оно до релиза и если доплывает, не будет ли там родовых травм предыдущей скалы. История показывает, что сделать все языковые хотелки, не жертвуя скоростью и совместимостью, не получается.
SM
С дотти всегда вопрос возникает - доплывет ли оно до релиза и если доплывает, не будет ли там родовых травм предыдущей скалы. История показывает, что сделать все языковые хотелки, не жертвуя скоростью и совместимостью, не получается.
Поживём, увидем 😁
VS
А к вопросу fun interface из K1.4, есть какое-нибудь объяснение почему нельзя для всех интерфейсов разрешить использование как лямбд?
2020 March 25
EM
Как же достали эти спамеры
2020 March 26
RV
Всем привет при компиляции получаю ошибку type argument is not within bounds Типы совпадают вроде как, но в чем может быть причина еще? Почему ошибка?
val postgreSQLContainer: PostgreSQLContainer<*> = PostgreSQLContainer<Any?>("postgres:11.1")
.withDatabaseName("integration-tests-db")
.withUsername("sa")
.withPassword("sa")SM
Ох уж эти self-generic Testcontainers 😁
RV
Да да это они))