各国程序员薪资水平,最高都知道、垫底想不到...

Python070

各国程序员薪资水平,最高都知道、垫底想不到...,第1张

大家好,我是 微笑。

看到一份「 2022年各国程序员的平均薪资报告 」,给大家参考看看。

智能招聘平台 CodeSubmit 统计分析了 20 多个国家在 2022 年的软件工程领域的平均工资发现,美国的软件工程师薪资水平最高,瑞士和以色列紧随其后。

前十榜单还包括丹麦、加拿大、挪威、澳大利亚、英国、德国和瑞典。中国则排在第 19 位,平均薪资水平为 23,790 美元 / 年。

其他方面,印度是一个西方公司倾向于将其技术需求外包的国家,其平均年薪为 7,725 美元。尼日利亚薪资水平垫底,为 7,255 美元 / 年。

CodeSubmit 方面指出,总体而言软件开发是世界上最受欢迎的职业。对软件开发人员需求最高的国家是加拿大、澳大利亚、俄罗斯、瑞典和新西兰;由于人才紧缺,工资水平也往往更高。

美国软件开发人员 的平均工资为每年 110,140 美元或每月 9,178 美元。初级开发人员的平均工资为每年 69,354 美元或每月 5,779 美元,高级开发人员的平均工资为每年 104,188 美元或每月 8,682 美元。

软件开发人员收入最高的州是加利福尼亚,平均工资为 146,770 美元;华盛顿次之。收入最高的城市包括圣何塞(167,420 美元)、旧金山(158,320 美元)和西雅图(148,200 美元)。

该国的编程语言平均薪资水平中,Go 和 Python 等流行的后端语言位居榜首。具体表现为:

欧洲软件开发人员的平均工资水平低于美国。

总体而言,欧洲国家在东西方之间存在很大差异。 西欧开发者 的年收入至少为 40,000 美元以上,而 东欧的开发者 期望的收入要少得多,约为 20,000 美元以上; 南欧开发者 的薪酬也要低于北欧开发者。 西班牙、意大利、葡萄牙和希腊的开发人员 预计年薪范围在 21,314 到 36,323 美元。

美国和欧洲国家之外, 以色列软件开发人员 的平均年薪为 71,559 美元或每月 5,963 美元。初级开发人员每年赚 69,851 美元或每月 5,820 美元,高级开发人员通常年薪为 114,751 美元或每月 9,562 美元。

语言方面,Golang(每年 109,702 美元)和 Python(每年 83,369 美元)平均薪资水平最高。PHP 和 Ruby 在以色列支付的薪资水平最低,分别为每年 64,573 美元和 64,525 美元。

此外, 日本开发人员 的平均工资为每年 36,024 美元或每月 3,002 美元。编程语言薪资方面,iOS 水平最高,Ruby 位居第二;SQL 和 Java 是日本收入最低的编程语言。

印度软件开发人员 的平均工资为每年 7,725 美元或每月 643 美元。Ruby 是印度收入最高的编程语言,每年 12,372 美元。Android 是薪资水平最低的语言,为 5,181 美元 / 年。

总体而言,各国总体编程语言薪资水平中,Golang 和 Ruby 往往是高薪语言,而 JavaScript 和 PHP 则是工资最低的语言。

文末有一个我们团队正在测试的副业,已经操盘了快1年多,执行力够强的小伙伴基本都能拿到结果。

感兴趣的话,可以加下他的微信,领取一份副业笔记。

扫码加我微信

凭文章截图,领取价值999元的

《副业赚钱实战笔记》

我最早使用的语言是Java和Python, 并且一直都对Python充满好感, 我喜欢这种很朴实和高效率的感觉, 但我却最后没有采用Python,原因其实也很简单, 我就是不喜欢缩进语法, 就跟很多人换工作仅仅是为了屏幕更大一点一样, 另外就是有了同样很棒的可选方案, 这就是Ruby, 所以我最终采用了Ruby作为主力编程语言, 同样也为不能使用Python而有一点小遗憾,毕竟Python的健壮性比Ruby好很多,只不过Ruby也一直在进步, 所以这一点无伤大雅

我们都知道,无论是Python还是Ruby,甚至Java, 都是在解决业务层的问题, 属于应用型语言, 以解决业务逻辑为主, 但还有一个领域是系统领域,偏网络层和底层操作,在这一块我一直在寻找一种优雅的方案, C++被我首先给淘汰掉了, C的开发效率太低, Java倒是比较合适, 就是太臃肿,而且缺少系统编程的基因,毕竟它是企业级开发出身的

最后我选择了Erlang, 因为它在网络层方面表现优秀, 同时容错性和健壮性都很不错, 它的虚拟机是唯一可以跟JVM媲美的, 而且还有OTP的超重量级武器, 几乎可以是通杀网络层应用, 但根据我的总结它有一个硬伤和一个软肋,这一点后面展开,可以说选择Erlang是我目前所知道的方案里面是最优的

直到有一天我了解了Golang, 我知道Golang其实也蛮早的, 大概08年的时候就知道Google在搞一门奇怪的语言, 之后的几年,一直有不少以老莫为代表的人在嘀咕Golang, 其实我一直没太关注,我从ROR中吸取的经验是,成熟度对于商用很重要, 后来基于Golang开发的产品越来越多,让我不得不去研究一下, 这我才知道, 这就是我梦想中的Python, 效率和性能达到了最佳的平衡,对Go了解越多, 就越不愿意用Erlang写代码,主要原因:

1、Erlang的硬伤在于代码的可读性、表现力, 让我来举个小例子, 比如你为你的系统软件构建一个RESTFUL的接口,我们大致了解一下代码风格,先不说Erlang, 无论是你c/c++/python/ruby/java 出身, 对Go是不是有种很久违的感觉, 为什么说是硬伤? 因为对一门语言来说,语法是不大可能会大幅度变更的, 而且不会出现大的变化, 我不知道有没有人读过《松本行弘的编程世界》,里面阐述的道理很明白, 真正好的编程方式是人去主宰计算机而不是计算机主宰人, 我感觉Erlang就有点主宰我的编程思维的感觉(我的视力本身就不好,它还在不断的扼杀我的眼睛!), 编程首先是门逻辑学,其次是工程学,最后才是数学, 又让我想起吴军的《数学之美》所说的, 人工智能上个世纪一直在走弯路, 期望机器的高度图灵完备, 而忽视人类本身已有的文明,统计归纳的应用

2、Erlang的软肋在于高质量的库少,尽管有不少杀手级应用, 同样Go在这方面也是软肋, 这一点对于一个不到五年的语言有情可原, 但对于一个20多年的语言是不是有点说不过去, 比如你用json解析库,很多人都是从mochiweb这个基本不更新的库中去抽取, 而我认为对于类似json这种东西可以考虑融入到语言标准库中, 因为未来的商业软件的api化趋势越来越明显,说的难听点 , 一个倚老卖老一个与时俱进,反正我对Golang的库一点也不担心, 目前的成绩易经非常棒了, 远远优于Ruby/Python的前五年, 可参见已有的高质量的库列表

3、Erlang不合群, 这主要体现在跟其他语言的交互性上, 当然这也有深层次的原因, Erlang本身有自己的哲学, 如出错恢复机制, 你融入一个其他语言的东西进去, 这帐就不好算,就好比你硬要让一个喝咖啡的跟一个吃大蒜的坐在一起, 总之你写一个Erlang的port远远比Go复杂, 甚至比Python/Java还要复杂, 这就造成了Erlang在底层编程上效果不是很好, 没法利用linux已有的很多优秀成果,我一直认为Erlang的什么的mysql/pg/oracle驱动都没有必要存在, Erlang一定是一个self-container应用, 你只要用到了其他东西, 根据木桶理论, 你就不敢号称9个9,以系统的眼光看问题, 我觉得一个系统的鲁棒性不能依赖于某一组件, 这也是为什么爱立信本身的Erlang应用并不广泛

4、说说数据类型吧, 我不止听到1个人说Erlang对字符串的处理不有好, 它把string当做list来处理,其实本质上是该这么,但,还是那句话, 违背了面向人的哲学, 应该做一些DSL, 比如Golang里面的 := 就是一个糖衣, 等价于 var xx yyy = zzzz, 大大方便的程序员少敲不少字符, Golang里面对字符转可以说基本和python差不多, slice map函数很强大, 支持lambda条件,虽然Erlang的基本类型很少, 但有很多构造, 所谓构造等价于Golang里面复杂的struct, 也奇怪了,我就是感觉Erlang构造伤眼睛好吗?可能是各种括号的比对的原因吧, 而且我认为这是不必要的, 显然Erlang缺少DSL的基因, 当然跟Erlang出身的年代有关, 我不夸张的说, 自打用Erlang以后我的视力又下降了100度左右, 我不是很喜欢lisp所说的符号也是一种语法, 可能这又跟函数式编程有关吧:形式推导远大于逻辑演绎

5、其实我最不关注的是性能问题, 因为随着摩尔定律, 单位计算单元的性价比会无限高,但Golang既然提出它的性能逼近C, 那我还是提一下吧, 当然, Erlang也还可以, 虽然比Java慢, 但跟Python一个档次吧

6、再谈谈报错机制, 因为Erlang的的报错信息太让人纠结了, 起初以为我不会看出错信息, 后来也使用了Sasl, 还是不够直观,甚至有时要用工具分析crash文件来定位问题,还是跟Erlang的哲学有关, 在Erlang中一切都是并行的, 所以它根本不care是物理哪一行出错, 只跟Actor绑定, 然后告诉你Actor的ID和出错代号, 你自己凭经验去分析吧,这样做的好处是可以很方便定位出并行中出现的问题,但凡事都是相对的, 在这一点上有点纠枉过正,根据我的经验, 绝大部分时候我只希望先给我明确的指出哪一行出错了好吗? 甚至把顺序的backtrace用完整的英文句子打印出来好吗?至于并行中的错误及时在命令式多线程语言中是不常见的,虽然并不是没有, 但遇到错误我再费劲去调试好了, 但并不是所有的逻辑都用并行的思维去定位问题, 我甚至认为, 对于一个系统不完全是并行也不完全是串行,跟好比我们衡量世界不能单纯的唯物也不能完全的唯心一样, 这一点Golang就做了很好的折中, 不需要并行的时候你老老实实的写串行代码, 需要并行的时候也有较复杂的机制来应对, 合乎情理

7、再说说招人吧, 以前招过好几个C出来的人,说实话水平很好, 可以一周就完成一个小组件, libevent用的熟的很,后来我逼人家用Erlang,结果把人家逼走了,至今我还很后悔, 自己的一厢情愿强加在别人身上真是太不合适了,但我招纯Erlang出来的人,可以说比招objc的人还难, 没有人,空谈技术的优雅性首先就是不靠谱的,再看看邮件列表, Golang的活跃度明显比Erlang高很多, 基本逼近Ruby,更重要的是, 我根本不担心Golang的人才,因为只要熟悉Python/C/Ruby/或者C++, 基本可以实现半天入门, 之后就可以噼里啪啦边搜资料边干活了,虽然有足够的深度,但门槛极其平缓,工程人员也可以复用很多已有的知识。 Erlang在这一点其实跟第一点硬伤有关,大部分人学一周都摸不着头脑,不是每个人的抽象思维和世界观都是一样的好吗, 所以函数式编程尽管不比命令式语言起步晚,但始终学的人很少,这就是历史, 对于大部分人, 更希望解决问题,创造价值, 而不是数学来推导去

8、最后我建议, 如果你是玩c/c++的, 现在开始学Golang,是最好的时机, 跟一门靠谱的语言一起成长, 这种感觉非常棒, 你用Erlang折腾1个应用, 用Go恐怕都完成了10个开源项目, 当然,也要结合自己的口味, Golang就是Sublime Text, Erlang就是Emacs

相信自己的判断,相信自己的逻辑, 赢就是赢,输就是输

转载仅供参考,版权属于原作者。祝你愉快,满意请采纳哦

在 gRPC 里客户端应用可以像调用本地对象一样直接调用另一台不同的机器上服务端 应用的方法,使得您能够更容易地创建分布式应用和服务。与许多 RPC 系统类似,gRPC 也是基于以下理念:定义一个服务,指定其能够被远程调用的方法(包含参数和返回类型)。在服务端实现这个接口,并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

gRPC 客户端和服务端可以在多种环境中运行和交互 - 从 google 内部的服务器到你自己的笔记本,并且可以用任何 gRPC 支持的语言来编写。所以,你可以很容易地用 Java 创建一个 gRPC 服务端,用 Go、Python、Ruby 来创建客户端。此外,Google 最新 API 将有 gRPC 版本的接口,使你很容易地将 Google 的功能集成到你的应用里。

gRPC 默认使用 protocol buffers,这是 Google 开源的一套成熟的结构数据序列化机制(当然也可以使用其他数据格式如 JSON)。名叫 proto3 的新风格的 protocol buffers,它拥有轻量简化的语法、一些有用的新功能,并且支持更多新语言。当前针对 Java 和 C++ 发布了 beta 版本,针对 JavaNano(即 Android Java)发布 alpha 版本,在protocol buffers Github 源码库里有 Ruby 支持, 在golang/protobuf Github 源码库里还有针对 Go 语言的生成器, 对更多语言的支持正在开发中。

有了 gRPC, 我们可以一次性的在一个 .proto 文件中定义服务并使用任何支持它的语言去实现客户端和服务器,反过来,它们可以在各种环境中,从Google的服务器到你自己的平板电脑—— gRPC 帮你解决了不同语言及环境间通信的复杂性.使用 protocol buffers 还能获得其他好处,包括高效的序列号,简单的 IDL 以及容易进行接口更新。

现在让我们来仔细了解一下当 gRPC 客户端调用 gRPC 服务端的方法时到底发生了什么。我们不究其实现细节,关于实现细节的部分,你可以在我们的特定语言页面里找到更为详尽的内容。

首先我们来了解一下最简单的 RPC 形式:客户端发出单个请求,获得单个响应。

服务端流式 RPC 除了在得到客户端请求信息后发送回一个应答流之外,与我们的简单例子一样。在发送完所有应答后,服务端的状态详情(状态码和可选的状态信息)和可选的跟踪元数据被发送回客户端,以此来完成服务端的工作。客户端在接收到所有服务端的应答后也完成了工作。

客户端流式 RPC 也基本与我们的简单例子一样,区别在于客户端通过发送一个请求流给服务端,取代了原先发送的单个请求。服务端通常(但并不必须)会在接收到客户端所有的请求后发送回一个应答,其中附带有它的状态详情和可选的跟踪数据。

双向流式 RPC ,调用由客户端调用方法来初始化,而服务端则接收到客户端的元数据,方法名和截止时间。服务端可以选择发送回它的初始元数据或等待客户端发送请求。 下一步怎样发展取决于应用,因为客户端和服务端能在任意顺序上读写 - 这些流的操作是完全独立的。例如服务端可以一直等直到它接收到所有客户端的消息才写应答,或者服务端和客户端可以像"乒乓球"一样:服务端后得到一个请求就回送一个应答,接着客户端根据应答来发送另一个请求,以此类推。

通过运行下面的命令克隆并安装grpc-go代码库:

下载protobuf源码包

安装golang-protobuf

第一步使用 protocol buffers去定义 gRPC service 和方法 request 以及 response 的类型。

要定义一个服务,必须在.proto 文件中指定 service:

然后在服务中定义 rpc 方法,指定请求的和响应类型,gRPC 允许定义4种类型的 service 方法。

服务.proto文件如下所示: