会有熟练 Java 的愿意做 dotnet core 后端吗？

不是高手，但是我觉得只要给够钱，语言都不是问题

会 c/c++和 Java，c#还会难吗？

@huiyifyj

刚好我三个都会。个人看法，如果只会 Java 的话，真的要上手 C# 路还蛮长的。

没玩过函数指针的人会怎么理解 delegate 呢？我很想知道

工资 double 可以考虑

@noli 确实，如果只会 Java 学起来难度确实很高。
如果都会的话，c#很好上手。
何况 visual studio 真的是很好的工具。

一般很少 java 喜欢去做 C#的吧，工资比 java 低得有点多

用 C#有什么优越感，用 Haskell 我才服。

给钱， 语言从来不是障碍

有点担忧 dotnet 的前景

顺便问一下 lz 公司所在地？

生态是个问题。之前做过.Net C#，现在做的 Java。
从.Net 到 Java 感觉从原始社会到了现代社会。

---

不过有一点可以说的。C#的部分理念要高过 Java 不少，不管是语言，还是设计。

原来十几年前 DDD 刚刚出的时候，是以 Java 为样本讲解的，但是感觉 DDD 在 Java 生态没有开花结果。
在.Net 上发展的却不差。起码现在再搜一搜 DDD 相关教程，全是 5，6 年前的.Net 文章。

@noli 2 楼都说了，会 C/C++ 怎么会不知道函数指针。再说 delegate 拿接口做也一样，虽然麻烦多了，即使是有 lamdba 也麻烦。

wpf 路过。.net 这边特别喜欢的就是 async/await 写并发了。不知道 core 里需要并发时是用 task 比较多呢还是 thread 比较多呢？
顺便问下 lz 公司.net core 的 Jd，做.net framework 久了，想往 core 上发展发展

为什么去碰 M$ 的东西？

@poorcai 广州

@WispZhan 我不认为写 Java 的人里面合格的 C++ 程序员比例会超过 5%，能够用好函数指针的人算法能力应该也可以，比例就更低了。以我本人为例，C++ 熟练之后觉得 Java 真的是手动搬砖的感觉。

@verrickt 当然是 async/await，谁有闲心去操心那些线程池，信号，手写状态机谁还想写。


### 后端技术要求

1. 语言不限，有 Java 或 C# 经验的优先；有游戏后端开发经验优先；

2. 熟悉多线程开发和框架，熟悉异步 IO、死锁、高并发等概念；

3. 熟悉网络协议知识，包括但不仅限于 TCP/IP , HTTP，RESTFUL 等等；

4. 了解微服务、去中心化、高可用等多种服务端架构设计思想或风格，了解 Actor 模型；

5. 了解 Consul 或 ZooKeeper 的使用等；

6. 熟练使用一种或多种数据库；


### 后端职位描述

1. 使用业内前沿的 .Net CORE 框架(C#)，开发基于 Linux 的游戏服务器框架，以及实现游戏逻辑；

2. 使用一系列分布式、去中心化技术，实现高可用的游戏服务集群；

3. 设计和实现高效率、高实时性的游戏客户端和服务端通信协议；

4. 应对灵活需求和业务变更的挑战的同时，保证代码逻辑的稳健可维护；

5. 与游戏前端 （ Unity3D C#）紧密协作，共同推进；

卧槽，这个位置太符合我了，我之前的公司就是用 Java 做 FPS 游戏的后台的。

能不用 Windows 开发的话，还是可以考虑下的。

Mono 吧，以前玩过，不知道现在是什么情况了。

珍爱绳命远离瘟到死

不是高手，宁愿写 c++

@sutra @niubee1

哈哈，服了。

看不到跟帖内容就算了，
看到自己不理解的词语 (dotnet core) 也可以强行套上自己的经验，
什么 “ mono 吧？” “远离 瘟到死”

作为你们的同行，我感到很悲哀，可以后知后觉乃至不知不觉到这个程度。

jvm 上方言 scala kotlin 不比 c#? 还有 java 的库做支撑

@noli 做为一名 Java 高手，我不是很理解你的迷之自信。C#这种东西在我看来，花一天看看语法，再花个两三天看看编译、包管理、主流框架就可以上手了。
Delegate 有什么难理解的？一个简化版的 interface 而已。

回你主贴的问题：C#是个好语言。但是其使用者以及生态建设在互联网从业者的视角来看实在太不入流了。
你想找懂“分布式、高可用、微服务、去中心化”的人，可能还真的得从 Java 生态找点人才，.NET Core 从业者恐怕你是指望不上的。

别瞎 jb 扯了，github 贴一个看看你什么水平

@noli 已经十多年没研究过 dotnet 了，我只熟悉 .Net Framework 1.1.

C#语言设计大概相当于 Java 20 的水准，VM 相当于 Java 7，生态可能还不如 Java 1.4。

只要钱管够，我写 VB 都行

@incompatible

Orleans 了解一下。

简化版 interface ？很明显这是一个错误的理解。

interface 必须名字符合、函数签名符合；
delegate 不需要，只需要参数类型和返回类型一致就好；
C# 里面 delegate 还可以支持协变, 算了，估计 Java 用 object 就够了，不需要理解什么叫协变。

哦或许你认为这叫做“简化版”？

我叫这个叫更宽松的约束描述更低程度的耦合。

Java er 的蜜汁自信啊……

@751762476

我没说 Scala Kotlin 不好。不过你要觉得 Kotlin Scala 好那你发个帖开战呗。

再者，写 Java 的有多少人会写 Scala ？
装什么呢……

@incompatible

IList<T> Sort<T>(this IList<T> list, Func<T, T, int> comparator);

你用 interface 表达的时候，势必要引入一个新的类型，难道还要全世界 extends 一遍你的新类型才能用 Sort ？

Java 高手，指点一下？

@xiaoshenke 就你 tm 也配论斤两？

于是大神的 github 呢？

@noli 秀 github 啊，程序员谁来给你玩虚的

@ykrank 时没打算公开某些项目。

@xiaoshenke

没人要跟你要斗代码。也没有打算让你们承认我实力如何。

再说了，代码乃是生产资料，分享给你们，也不见得尔等会添砖加瓦，对我有啥好处？
就为了让你说一句“哦大神”？

别那么幼稚好不好

@noli 引入一个新的叫做 Comparator 的类型有什么问题？全世界 implement 一遍新类型有什么问题？
全世界还可以选择匿名内部类，还可以选择用 lambda。
函数指针、delegate、interface 说到底就是对行为的封装，如你所说，无非是约束范围不一样而已。

你会用 delegate、懂协变，那你真的很棒啊。请问你因此比我更懂分布式和高可用了吗？
Definitely not：）

@incompatible

引入一个新的 Comparator 当然有问题啊，因为你不可以指望第三方的库也实现 Comparator。
对于一组类似的 comparator 行为，你就只能多写几个 Adaptor 类。

用 Comparator 不是平凡的 Comparator，而是需要使用上下文的，那么使用匿名内部类封装就必须在 new 的时候把上下文带进去；换句话说，不同上下文类型还要写成不同的 adaptor 类；呵呵……

如果用 Lambda，又丧失了预先封装复杂上下文数据的能力。

也就是说，如果需要一个，既需要构造复杂上下文，又需要从调用初捕捉上下文的 Comparator,

Java 就是办不到。

对行为的封装，只能用 interface 封装行为，就是为了封装行为引入一大堆不需要的约束，这就是 Java 为了适应它自己不合适的抽象模型而制造的不合理的耦合。


请指教。

@incompatible

要说分布式和高可用，Fast PAXOS 还是微软专利呢，呵呵呵~

Java er 不就是用用 ZooKeeper 和 Consul 嘛，还因为封装协议能力不足只能搞 HTTP 协议上的。

离开了 NIO 就写不了高性能网络应用的 Java 废也好意思呱噪哦。

不好意思，在下刚好就是写这样的服务的，你觉得我懂不懂 HA ？

@noli 你的行为依赖了上下文，那自然要把依赖带入到行为的作用域里。这是必要的耦合，用任何封装行为的方法都是不可能解掉的。你觉得你用某种封装行为的方法就可以解耦了？不，你只是假装解耦了。

是是是，你比较懂。你老板若是没给你发三百万年薪 + 千万 RSU 简直就对不起你的聪明才智。你管高性能网络应用叫 HA，管 Consul 叫分布式。别人废柴离了 NIO 编不了码，你自己手撸高性能 NIO。真诚为您鼓掌。

@incompatible

1. 转移话题？ 我说的是，Java 没办法用自然的方式解耦合，而要手动制造一堆类；

2. 不好意思，C# 不需要手撸 NIO ；标准库也好，接入外部库也好，形式都是一样的 async await ; Java 自己去撸 Future Promise 吧。

@noli

手动制造一堆类有什么问题？ 你要做一个依赖上下文的 comparator，那就写个类叫做 ContextBasedComparator。这有什么不自然的吗？简直没有什么比这更自然了。

你贬损了半天 Java 和 Java 程序员，你自己还不也是个拿着现成 library 写写业务代码、拿着 C#里的语法糖秀秀优越感的码而已。摊手。

@incompatible

1. 写 C# 不需要引进新的类型，就可以完成刚才的需求。算了，你觉得习惯就好。夏虫不可语冰

2. 虽然我不介意你误解我为用 library 写写业务代码；不过我也可以跟你说，用 C# 写 Libraray 要比 Java 容易多了，因为你低估了语法糖的重要性。

更别说 async/await, delegate, linq, Expression Tree 本质上就不是语法糖。

啊，你也吃不到，当然会认为是酸的咯。

@incompatible

另外，你要讨论语法糖的话。
先准备好知识点，ANTLR 以及 Monadic Parser 分别是什么鬼。

没有写过 parser，AST walker 就别人云亦云说什么 语法糖了。你根本没弄清楚自己在说什么。

好了 Java 简单工整天下第一，其他都是渣渣。满意了吧？

关于什么是语法糖，什么不是，我参照的是维基的说法： https://zh.wikipedia.org/wiki/%E8%AF%AD%E6%B3%95%E7%B3%96

“指计算机语言中添加的某种语法，这种语法对语言的功能没有影响，但是更方便程序员使用。”

1. 为什么 async/await 不仅仅是语法糖，
因为带有 async/await 的代码段会被 C# 编译器插入状态机代码。这已经改变了代码原来的含义了。

2. delegate 对应到 C++ 的相同作用的应该是类似于 std::bind，std::bind 就不是一个 class 或者别的语法结构的替代物。硬要用 class 来表示的话，至少也得支持重载 operator() ;

可惜这两者 Java 都不支持。所以说 delegate 就是 interface 的简化版，要么蠢要么坏。

3. LINQ 只是一个 SQL 语言嵌入在 C# 里面，可以用函数以及一些类来组合表示达到同样的效果？

这样想纯粹是因为那些人只会写 SQL。
SQL 有 delete update insert 这些 LINQ 都没有，也不需要。

因为 LINQ 实际上是表达一个 C# 的语法树结构 AST，并且 C#编译器保证这个 AST 至少能符合 C#语义

然后，有了 AST，你就可以在不同的场合 interpret 也好，compile 也好，让它做不一样的事情。
例如在 与数据库交互的领域，你可以让这个 AST 翻译成对应的 SQL。
如果你自己写一个数据库，你也可以直接解析运行这个 AST 而不需要 转一遍 SQL。

管这些叫语法糖？？

这种代码及数据 的在编程语言中的实践，除了 LISP F# C# ，目前我还不知道别的通用编程语言能做到。

你喜欢认为这是语法糖的话，你开心就好。

@noli 抱歉，在你看来 可惜 / 酸 的事儿对我来说完全不足挂齿。请你尽情自 high♂

你的长篇大论说到底只是在描述 C#的特性而已，C#并不是您本人设计的对不对？我看好这些特性的话我可以直接下载一个 dotnet sdk 开始用它了对不对？就可以瞬间拥有你也拥有的优越感了对不对？请问你到底高明在哪儿了？？

@incompatible 我本来不觉得自己有多高明，不过是前人探路我跟上得比较快；

但是经你这么一提醒，我发现我还是蛮高明的；

高明在我已经用 C# 写出我想要的代码，而别的语言很难写得这么方便；

然后发现有很多像你这样愿意抬杠的，把我拾人牙慧后的自卑心都弥补了：
原来自己虽然不是 1% 的聪明人，也是 10% 以内的。

你该不该替我开心一下？哈哈

@incompatible

为了和你抬杠下去，我不得不认真思考一下 C# 到底好在哪里，什么是是语法糖。

整理完之后，我发了一个知乎回答： https://www.zhihu.com/question/28942665/answer/403871596

欢迎你过去继续抬。

我反正是挺享受这个过程的。谢谢了。

niubi.cs

Java C# 都会，Java 语法过于陈腐了，想起很久很久以前和一个同事维护一个更久更久以前的 VBA 项目，那朋友写着写着骂了一句，“妈的，写个属性都这么嗦，人家一句话就搞定了”，这话同适用于 Java。

dotnet core = java100 的语言设计,java50 的性能,java10 的生态,java1 的后备韭菜

dotnet 生态太差了,至少国内是这样,招一批人,问一个分布式,回答都是"没了解过 /有这个吗 /你是想问异地部署",我都怀疑我去了假的大学,好在上面沟通从上海请了 2 位救兵过来负责这部分的开发了