十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
我最早使用的语言是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
相信自己的判断,相信自己的逻辑, 赢就是赢,输就是输
转载仅供参考,版权属于原作者。祝你愉快,满意请采纳哦
这有得选吗?不就是JavaScript吗?虽然wxml中可以插入wxs代码,但这其实也是JavaScript。小程序是基于浏览器内核的(但又有别于浏览器),所以程序代码也肯定只能是基于浏览器的脚本语言的,也就是JavaScript。
如果你说的是后台程序,这就没什么限制了,喜欢用什么就用什么,只要能接收到小程序的连接请求并按小程序要求的格式返回数据即可。当然微信官方是推荐用nodejs和php的。不过这跟小程序本身就没有直接关系了,因为开发普通APP的后台程序也是完全一样的啊。
微信小程序开发一般有php语言和java语言两种语言、html/css/js三件套都要会。
微信小程序常见使用“MINA”框架,这个框架为微信小程序的运行提供了丰富的组件和API。微信小程序开发者要学会和掌握小程序的框架结构、数据绑定机制、模板、数据缓存、常用组件和API等相关知识。
1、微信官方为小程序提供了大量的接口api,开发小程序需要有基本的Javascript,HTML,CSS的基础。
2、 小程序开发,常见使用“MINA”框架
Apache Mina Server 是一个网络通信应用框架,也就是说,它主要是对基于TCP/IP、UDP/IP协议栈的通信框架(当然,也可以提供JAVA 对象的序列化服务、虚拟机管道通信服务等),Mina 可以帮助我们快速开发高性能、高扩展性的网络通信应用,Mina 提供了事件驱动、异步(Mina 的异步IO 默认使用的是JAVA NIO 作为底层支持)操作的编程模型。
这个框架为微信小程序的运行提供了丰富的组件和API。要学会和掌握小程序的框架结构、数据绑定机制、模板、数据缓存、常用组件和API等相关知识。
在Go语言中,规定的方式是,函数返回错误信息。这没什么。如果一个文件并不存在,op.Open函数会返回一个错误信息。这没什么。如果你向你一个中断了的网络连接里写数据,net.Conn里的Write方法会返回一个错误。这没什么。这种状况在这种程序中是可以预料到的。这种操作就是容易失败,你知道程序会如何运行,因为API的设计者通过内置了一种错误情况的结果而让这一切显得很清楚。
从另一方面讲,有些操作基本上不会出错,所处的环境根本不可能给你提示错误信息,不可能控制错误。这才是让人痛苦的地方。典型的例子;一个程序执行
x[j],j值超出数组边界,这才痛苦。像这样预料之外的麻烦在程序中是一个严重的bug,一般会弄死程序的运行。不幸的是,由于这种情况的存在,我们很难写出健壮的,具有自我防御的服务器——例如,可以应付偶然出现的有bug的HTTP请求处理器时,不影响其他服务的启动和运行。为解决这个问题,我们引入了恢复机制,它能让一个go例程从错误中恢复,服务余下设定的调用。然而,代价是,至少会丢失一个调用。这是特意而为之的。引用邮件中的原话:“这种设计不同于常见的异常控制结构,这是一个认真思考后的决定。我们不希望像java语言里那样把错误和异常混为一谈。”
我刚开始提到的那篇文章里问“为什么数组越界造成的麻烦会比错误的网址或断掉的网络引出的问题要大?”答案是,我们没有一种内联并行的方法来报告在执行x[j]期间产生的错误,但我们有内联并行的方法报告由错误网址或网络问题造成的错误。
使用Go语言中的错误返回模式的规则很简单:如果你的函数在某种情况下很容易出错,那它就应该返回错误。当我调用其它的程序库时,如果它是这样写的,那我不必担心那些错误的产生,除非有真正异常的状况,我根本没有想到需要处理它们。
有一个你需要记在心里的事情是,Go语言是为大型软件设计的。我们都喜欢程序简洁清晰,但对于一个由很多程序员一起开发的大型软件,维护成本的增加很难让程序简洁。异常捕捉模式的错误处理方式的一个很有吸引力的特点是,它非常适合小程序。但对于大型程序库,如果对于一些普通操作,你都需要考虑每行代码是否会抛出异常、是否有必要捕捉处理,这对于开发效率和程序员的时间来说都是非常严重的拖累。我自己做开发大型Python软件时感受到了这个问题。
Go语言的返回错误方式,不可否认,对于调用者不是很方便,但这样做会让程序中可能会出错的地方显的很明显。对于小程序来说,你可能只想打印出错误,退出程序。对于一些很精密的程序,根据异常的不同,来源的不同,程序会做出不同的反应,这很常见,这种情况中,try
+
catch的方式相对于错误返回模式显得冗长。当然,Python里的一个10行的代码放到Go语言里很可能会更冗长。毕竟,Go语言主要不是针对10行规模的程序的。
就是要说明这一点:Go语言程序员认为,把error作为一种内置的类型是非常重要的。