@lemonchan Airwallex 有兴趣么？国内 base 在上海。有兴趣的话可以 pdf 简历发我
wechat: c3RhcnJ5XzQ= (base64 encoded)

@857681664 你翻一下我上一个发的主题 里面有联系方式

我司主要 base 就在上海，而且就是用 kt 写后端

https://app.mokahr.com/apply/kongzhongyunhui/2265/#/jobs?zhineng=11730

坐标 Airwallex ，kotlin 后端普及率九成以上

我知道的 Afterpay 也是全部 kotlin 后端

意义在于你会不会做一层隐藏具体实现的封装。

比如你某些存储用的 KV ，今天用 Redis ，明天用 TiKV ，后天用自研了。但只要都是 KV 的，那你用它的时候就十有八九还是 get(k): V 这种姿势。

那么你可以封装出一个 persistence interface ，以后底层换实现了，只要操心写配置文件+注入，然后改改这个 persistence interface 就好了，其它模块都不用动的。

@afewok 我第一时间想到的就是 Pulsar

1. JVM 在 o11y 上有天然的优势。如果换一套 practice / 换一个 vendor ，你就知道别的语言有多痛苦了。没有 wire ，probe 要不要 dev 自己改？没有 agent ，SRE 要不要自己出苦工？

用 Spring 无论是 dev 还是 SRE 只需要把全家桶里那些事实规范照着一引入就好了。

2. 对研发来说，我自己体验的部署成本取决于服务发现（不要从 ip 开始让我啥都自己写） / 配置方式（自己写一屁股 yaml placeholder 还是热配置中心） / 部署平台（能不能让我点点点就完事）的成熟度。跟语言没啥关系。

3. 开发效率取决于能不能方便切分「可以乱写的部分」和「不能乱写的部分」，并规整好它们的依赖。C++我没写过，不敢乱说。就 C 和 go 这种语言的 module 和依赖管理，光是想到一下头就在疼了。

而且易读性这个东西要怎么定义呢？假设让一个完全没见过 JVM 系语言的人来看

@ Data
@ AllArgsConstructor
@ NoArgsConstructor
public class RandomStuff {
private String a = "a";
private String b = "b";
}


class RandomStuff(
val a: String = "a",
val b: String = "b",
)

1. 应不应该强逼着语言新手理解 annotation ？
2. 如果不用 lombok ，第一个东西你手写会变多长？
3. 手写原生 constructor ，RandomStuff(String a)，我怎么让这个东西只接受一个参数，但能选择赋值给 a or b ？
4. 读惯了与好读是等价的吗？

坐标: Airwallex
现状: 公司级别使用 Kotlin ，Kotlin 和 Java legacy 比例差不多 95 : 5
我了解的同情况的公司：Afterpay （公司级别已普及）, Lego （公司级别在转型）, Google （部分组）

Kotlin 写后端到底好不好用：
Springboot 2.3.9, 语言层面只遇到过一个坑：Kotlin 自己的 Collection 是有 Immutable 和 Mutable 两种的，而 Java 都是 Mutable 的，至少这个版本对 Kotlin Immutable Collection 支持有问题。所以在 wire bean 的时候要注意下。
别的没遇到过任何语言层面的问题，支持得相当完美。

我理解的阻力：
1. 面向简历编程。在这个公司不干了，去下一家未必能用 Kotlin 。
我觉得这个问题无解，尤其在国内。

2. MVC vs Webflux, JDBC vs R2DBC 。
这其实跟 Kotlin 够不够好没啥关系。我们组自己的服务已经彻底 reactive 化了，没有这方面烦恼。别的组也不是都用这些，但照样可以用 Kotlin 。

3. 觉得语法糖用不上，怕编程风格不统一。
前者的话，我个人觉得都不用说 null safety （毕竟这个东西和 Java 的互兼容性是好是坏是值得讨论的，不是所有 lib 都会给你好好加 @Nullable ），constructor 的优化和 apply 这两个东西已经足够让我忘记 Java 了。

后者的话，如果你们组 /公司的 CR 流程和风气够好，我觉得互相理解、统一、寻找 better practice 是必经之路，也跟语言没什么关系。

首先不知道楼主是什么岗位，我自己是后端，并且 toB / toC 都做过，说说个人的感受

1. 「好玩」的反馈是用户给的，但不是所有的 PM 需求都会让用户觉得「好玩」。因为不「好玩」而失败，还占用了资源，最后导致大家下一轮绩效 review 都尴尬的情况是更多的。不然为什么大家 offer 对比的时候都会说看组呢。

2. 即使你真的在做一个「好玩」的东西，但是落到后端这里，写代码的时候不一定就是好玩的。设计和复用的第一关不是你说了算，是 PM 和 UX 说了算。并且真落到实施的时候，大家的合作是要服从康威定律的，会进一步限制你的设计。

3. 是会收到很多反馈，正反馈一定是先夸 PM 的，负反馈一定是要你先半夜起来修 bug 的。

4. toB 客户也不是不得不用，归根结底还是你们公司在竞标中胜出了。其实竞标能胜出，和用户觉得好玩而来玩，这两件事基本就是对标的，区别可能是在使用量能不能给你这个研发一个正反馈。

5. SaaS 类型的 toB ，你的服务是要接不少流量的，也可以让你在写代码时有好玩的感觉。

@ww050312 @Lqxc
我又去找我们 HR 问了一下，现在也是招 dev 实习生的，有兴趣可以加我 wechat 联系

持续招人中，解答几个最近加我的朋友普遍问的问题

上海 office 地点：黄浦区马当路中海国际中心
北京 office 地点：东城区东长安街 1 号东方广场
吃饭方便吗：上海这边吃饭很方便，楼下一堆吃的，但是贵。楼下吃基本一顿 30+起步。北京不清楚

@Jackwang0127 是的，会跨组跨国开 zoom meeting

@Jackwang0127 中文面，过程中会考验你的英文能力

@Lqxc 我们是有实习生，但我没看到有招日常实习生，都是假期的实习，你可以再等一等，summer intern 应该就要开了

让我看看这次吵得起来不

@lazydog 我们基本 100%Kotlin

@dryadent
设计有

运营的话，毕竟是 fintech 而不是互联网，没有所谓的运营，是有开户 operation / marketing 这类的岗位。不知道和你的背景和期待是不是相符。

@lidlesseye11
从 dev 层面，我觉得以 toB startup 的这些流量，可能谈不上什么巨大收益。。。
从 ops 层面，我个人猜测就是 RabbitMQ 的 ops 越来越不好招了吧，哪有多少人愿意天天跟 erlang 打交道。就像我之前在小红书，小红书从 mongo 切 mysql ，一个主要原因就是 dba 随便招。。。

spring cloud stream 能同时支持这两个 mq ，抽象成一套 interface 来用。有坑点都是 spring cloud stream 的坑点