Go語言出後，Java還是最佳選擇嗎？

大眾才子

作為開發人員好幾年，我可以使用多種語言和框架來做自己喜歡的事情。其中包括Basic，C，C ++，FORTRAN，PHP，Javascript，最近也包括Golang和Python。

在開始使用雲服務器計算後，我被Golang吸引了。簡單的協程可幫助到我們以最少的工作量和高併發性編寫高度可擴展的後端。這使得在單頁面Web應用程序和混合移動應用程序去編寫API更容易。

和Java比較？好吧，我不是特別喜歡Java，雖然它很健壯，因為它複雜的語法才能實現比較簡單的目標。如果您在開始使用Java之前就已經學習過Python，那麼您完全有可能因為它的複雜性而放棄了。

Java在構建企業級軟件應用程序方面的強大功能尚無定論，但當您查看替代方案時，你就會覺得Java的複雜性就太大了。

儘管React-Native等混合框架越來越流行，Java仍然是Android和後端開發人員的最愛。許多公司已經使用Java構建了複雜的應用程序，尤其是在銀行業或者現在的阿里。但是，由於Golang的簡單性和直接編譯成機器語言的能力，它更勝過Java一籌。

當Golang被編譯成二進制文件並在不依賴目標系統的情況下進行分發時，Java使用Java虛擬機（JVM）。Java與底層硬件進行良好交互以實現性能的能力是其成功的主要因素，但是Golang的直接二進制編譯優勢使其成為編寫高性能腳本的有力競爭者。

與Python之類的解釋型語言相比，Java仍然更快。但是對於服務器端計算呢？Golang勝了！

與Java相比，Go的編譯速度更快，並且佔用的內存更少。考慮到Java的統治地位，這可能不是一個主要因素，但是Golang一直在穩步採用Java來構建可擴展的後端體系結構。

所以如果你想選擇一門又快又容易寫的語言，Golang真的很不錯。

Hacker

這是一個非常好的問題，作為一名從業多年的程序員，我來回答一下這個問題。

首先，在當前的雲計算、大數據和人工智能時代，平臺式開發將逐漸成為一個新的流行趨勢，而平臺式開發具有三個特點，其一是開發過程更加簡單；其二是可以通過平臺整合更多的資源；其三是程序擴展能力更強。

從編程語言的設計思路來看，Go語言相比於Java編程語言來說，更適合作為平臺開發語言，原因有三點，其一是Go語言的語法結構更加簡潔，這是平臺式語言的發展趨勢；其二是Go語言在設計之初就考慮到了大數據的應用場景，而目前的各種開發平臺幾乎都離不開大數據場景；其三是Go語言更小巧，這也會拓展Go語言的應用場景。

Go語言的簡潔性能夠帶來一個直接的好處就是開發效率的提升，這對於開發人員來說還是非常重要的，實際上目前上升趨勢明顯的Go和Python，在語法簡潔性上都要優於Java語言。

Go語言在設計之處就考慮到了大數據和雲計算的應用場景，實際上Go語言一個重要的設計思想就是如何能夠高效率處理大量的併發任務，所以隨著未來大數據和雲計算的發展，未來適合於Go語言的開發場景將進一步增加。

Go語言本身更加小巧，這使得Go語言完全可以適合當前“雲+邊”的開發場景，所以從任務處理的角度來看，未來Go語言在雲計算和邊緣計算領域都將有較大的發展潛力。

雖然Go語言有後發優勢，但是Java語言目前已經構建起了一個龐大的生態體系，實際上在大數據、雲計算時代，Java語言依然有大量的應用場景。從當前就業的角度出發，初學者更應該先考慮學習一下Java語言。

我從事互聯網行業多年，目前也在帶計算機專業的研究生，主要的研究方向集中在大數據和人工智能領域，我會陸續寫一些關於互聯網技術方面的文章，感興趣的朋友可以關注我，相信一定會有所收穫。

如果有互聯網、大數據、人工智能等方面的問題，或者是考研方面的問題，都可以在評論區留言，或者私信我！

IT人劉俊明

golang連基本的OO特性都支持不全（沒繼承），而且還沒有泛型…其中的痛苦，誰用誰知道（可能是因為我一直做java開發）…

java成熟而穩重，各類框架和庫全面而充分，性能均衡而穩定，大小公司都在用，技術成熟，工作機會多…未來5-10年必然仍舊是java的天下！

golang會在特定領域，比如微服務上有所建樹（話說回來，隨著Spring的發展，java在微服務上也不差）；但是，打敗java的不會是golang…

千萬別說go還在發展和演進，好像java不發展了一樣…

BitMan

我認為Java還會是企業級服務軟件以及大數據方向的首選，生態很完善和強大，不光是阿里美團這樣大廠的支持和佈道，對小公司也可以依靠Java完善的生態，快速搭建起自己的系統推向市場。 儘管oracle一直在作死，還是有很多大廠基於openjdk做支持，Java不會死，還會越來越好。

各種語言總有自己適合的領域，比如c做底層以及對性能追求極致的場景，Python在數據分析和機器學習上很火，未來go肯定會越來越好，只是目前最火的方向還是在docker，k8s雲原生和微服務領域。go語言原生對併發的支持，更易寫出高併發的系統，它更像一門面向互聯網的現代編程語言，不像Java有太多歷史包袱。有大廠內部的某些項目在用，不過在業務系統開發上，國內大規模在用的大廠也就頭條了。

所以我的觀點是go是一門值得學習和關注的語言，但是當你面臨技術選型時，如果很糾結，選擇Java一般不會錯，可能不會太好，但總不會太差。而且從就業面上來說，Java目前也會更好一些。

開源之道

如果從薪資出發，Go程序員的平均薪資是能高出Java一節的。

為什麼呢？

第一：Java 不管是大小廠都在用,低級Java 數不勝數,工資也入門級的,這些金字塔低端的人群拉低了 Java 的平均薪資。

北大青鳥優越IT學院

我來回答一下：

October Headline: Top 8 of the TIOBE index quite stable for the last 15 years

翻譯：TIOBE指數的前8名在過去15年中相當穩定

java寶座穩得一筆！！！數據來自：https://www.tiobe.com/tiobe-index/

目前來看，go肯定替代不了，java。這是肯定的！！！

Go

編程界的小鮮肉。高併發能力無人能及。即具有像Python一樣的簡潔代碼、開發速度，又具有C語言一樣的執行效率，優勢突出。

go語言的難度，相對來說，GO語言不難的。可是GO語言的學習資料相對其他的語言來說很少，所以學習起來沒有其他的語言那麼便利；

很多人說GO語言在國內更火，按照數據來說，是的。因為中國人多，基數大。其實GO在國外更火。對於現在來說，GO實際上也已經站穩腳跟了。不管是Google自帶光環也好，實際應用也好。go算是找到了屬於自己的空間。

GO語言的優點：

• 編譯時間快：GO語言編寫最大的微服務的時間大概需要6秒，相對Java和C++呆滯的編譯速度來說，GO語言快速編譯是主要的效率優勢。
• 併發性和通道：GO語言的logo大家可以瞭解一下，它就是致力於事情簡單化，也就是快。其實並沒有引入很多的新的概念。就是打造一門簡單的語言，使用起來很快。在goroutine上運行一個函數最小的樣板代碼，我們只需要使用關鍵詞go添加函數調用
• 生態系統也是很強大的：面向Redis、RabbitMQ、Template等等很多穩定的庫。有很強大的工具支持。

GO語言的缺點：

• 缺少框架：GO是沒有一個主要的框架。但是很多人認為不應該從框架的使用開始。也可以從社區的討論瞭解一下這個問題。
• 錯誤處理：在錯誤處理方式，很容易丟失錯誤發生範圍，所以在編程過程中很難向用戶提供出有意義的錯誤信息。
• 軟件包管理：在默認的情況下，沒有辦法制定特定版本的依賴庫。、也沒有辦法創建可以複寫的builds。

java

編譯語言，速度適中（2.67s），目前的大型網站都是拿java寫的，比如淘寶、京東等。主要特點是穩定，開源性好，具有自己的一套編寫規範，開發效率適中，目前最主流的語言。

作為編程語言中的大腕。具有最大的知名度和用戶群。無論風起雲湧，我自巍然不動。他強任他強，清風拂山崗；他橫由他橫，明月照大江。

Java可以做什麼：

安卓和IOS的應用開發、視頻遊戲開發、桌面GUI、軟件開發等等；

Java的優點：

• Java開發人員需求量大：這個是根據統計得出的。JAVA在很多語言當中，是需求量最大的；

• 進化語言：首先C++是基於C語言優化的，Java是被優化過來的。而且在這人平臺是增加了很多的功能，lambda等功能

• 安卓應用開發：谷歌的安卓移動平臺是世界第一的移動平臺，編寫安卓應用開發者使用的主要語言是Java；

Java的缺點：

• 使用大量的內存：Java和C++相比使用更多的內存所以佔用的內存就更大
• 學習曲線：這邊指的是Java雖然不是最簡單的入門語言，但是也不是最難- -||
• 啟動時間慢：用java寫過安卓的應用的人應該都知道。同樣的代碼在模擬器中啟動是非常緩慢的事情。

未來可期！

大家覺得呢？？？

碼農指南者

阿里妹導讀：隨著大量新生的異步框架和支持協程的語言(如Go)的出現，在很多場景下操作系統的線程調度成為了性能的瓶頸，Java也因此被質疑是否不再適應最新的雲場景了。4年前，阿里JVM團隊開始自研Wisp2，將Go語言的協程能力帶入到Java世界。既享受Java的豐富生態，又獲得異步程序的性能，Wisp2讓Java平臺歷久彌新。

Java平臺一直以生態的繁榮著稱，大量的類庫、框架幫助開發者們快速搭建應用。而其中大部分Java框架類庫都是基於線程池以及阻塞機制來服務併發的，主要原因包括：

1. Java語言在核心類庫中提供了強大的併發能力，多線程應用可以獲得不俗的性能；

2. Java EE的一些標準都是線程級阻塞的(比如JDBC)；

3. 基於阻塞模式可以快速地開發應用。

但如今，大量新生的異步框架和支持協程的語言(如Go)的出現，在很多場景下操作系統的線程調度成為了性能的瓶頸。Java也因此被質疑是否不再適應最新的雲場景了。

4年前，阿里開始自研Wisp2。它主要是用在IO密集的服務器場景，大部分公司的在線服務都是這樣的場景 (離線應用都是偏向於計算，則不適用)。它在功能屬性上對標Goroutine的Java協程，在產品形態、性能、穩定性上都達到了一個比較理想的情況。到現在，已經有上百個應用，數萬個容器上線了Wisp1/2。Wisp協程完全兼容多線程阻塞的代碼寫法，僅需增加JVM參數來開啟協程，阿里巴巴的核心電商應用已經在協程模型上經過兩個雙十一的考驗，既享受到了Java的豐富生態，又獲得了異步程序的性能。

Wisp2主打的是性能和對現有代碼的兼容性，簡而言之，現有的基於多線程的IO密集的Java應用只需要加上Wisp2的JVM參數就可以獲得異步的性能提升。

作為例子，以下是消息中間件代理(簡稱mq)和drds只添加參數不改代碼的壓測比較：

可以看到上下文切換以及sys CPU顯著降低，RT減少、QPS分別提升11.45%，18.13%。

Quick Start

由於Wisp2完全兼容現有的Java代碼，因此使用起來十分簡單，有多簡單？

如果你的應用是“標準”的在線應用(使用/home/admin/$APP_NAME/setenv.sh配置參數)，那麼在admin用戶下輸入如下命令就可以開啟Wisp2了：

curl https://gosling.alibaba-inc.com/sh/enable-wisp2.sh | sh

否則需要手動升級JDK和Java參數：

ajdk 8.7.12_fp2 rpm

sudo yum install ajdk -b current # 也可以通過yum安裝最新jdk

java -XX:+UseWisp2 .... # 使用Wisp參數啟動Java應用

然後就可以通過jstack驗證協程確實被開啟了。

Carrier線程是調度協程的線程，下方的- Coroutine [...]表示一個協程，active表示協程被調度的次數，steal表示被work stealing的次數，preempt表示時間片搶佔次數。

下圖是DRDS在ecs上壓測時的top -H，可以看出來應用的數百個線程被8個Carrier線程託管，均勻地跑在CPU核數個線程上面。下方一些名為java的線程是gc線程。

過多線程的開銷

誤區1: 進內核引發上下文切換

我們看一段測試程序：

pipe(a);

while (1) {

write(a[1], a, 1);

read(a[0], a, 1);

n += 2;

}

執行這段程序時上下文切換非常低，實際上上面的IO系統調用都是不會阻塞的，因此內核不需要掛起線程，也不需要切換上下文，實際發生的是用戶/內核態的模式切換。

上面的程序在神龍服務器測得每個pipe操作耗時約334ns，速度很快。

誤區2: 上下文切換的開銷很大

本質上來說無論是用戶態還是內核態的上下文切換都是很輕量的，甚至有一些硬件指令來支持，比如pusha可以幫助我們保存通用寄存器。同一個進程的線程共享頁表，因此上下文切換的開銷一般只有：

保存各種寄存器

切換sp(call指令會自動將pc壓棧)

可以在數十條指令內完成。

開銷

既然近內核以及上下文切換都不慢，那麼多線程的開銷究竟在哪？

我們不妨看一個阻塞的系統調用futex的熱點分佈：

可以看到上面的熱點中有大量涉及調度的開銷。我們來看過程：

調用系統調用(可能需要阻塞)；

系統調用確實需要阻塞，kernel需要決定下一個被執行的線程(調度)；

執行上下切換。

因此，上面2個誤區與多線程的開銷都有一定因果關係，但是真正的開銷來源於線程阻塞喚醒調度。

綜上，希望通過線程模型來提升web server性能的原則是：

活躍線程數約等於CPU個數

每個線程不太需要阻塞

文章後續將緊緊圍繞這兩個主題。

為了滿足上述兩個條件，使用eventloop+異步callback的方式是一個極佳的選擇。

異步與協程的關係

為了保持簡潔，我們以一個異步服務器上的Netty寫操作為例子(寫操作也存在阻塞的可能)：

private void writeQuery(Channel ch) {

ch.write(Unpooled.wrappedBuffer("query".getBytes())).sync();

logger.info("write finish");

}

這裡的sync()會阻塞線程。不滿足期望。由於netty本身是一個異步框架，我們引入回調：

private void writeQuery(Channel ch) {

ch.write(Unpooled.wrappedBuffer("query".getBytes()))

.addListener(f -> {

logger.info("write finish");

});

}

注意這裡異步的write調用後，writeQuery會返回。因此假如邏輯上要求在write後執行的代碼，必須出現在回調裡，write是函數的最後一行。這裡是最簡單的情形，如果函數有其他調用者，那麼就需要用CPS變換。

需要不斷的提取程序的"下半部分"，即continuation，似乎對我們造成一些心智負擔了。這裡我們引入kotlin協程幫助我們簡化程序：

suspend fun Channel.aWrite(msg: Any): Int =

suspendCoroutine { cont ->

write(msg).addListener { cont.resume(0) }

}

suspend fun writeQuery(ch: Channel) {

ch.aWrite(Unpooled.wrappedBuffer("query".toByteArray()))

logger.info("write finish")

}

這裡引入了一個魔法suspendCoroutine，我們可以獲得當前Continuation的引用，並執行一段代碼，最後掛起當前協程。Continuation代表了當前計算的延續，通過Continuation.resume()我們可以恢復執行上下文。因此只需在寫操作完成時回調cont.resume(0)，我們又回到了suspendCoroutine處的執行狀態(包括caller writeQuery)，程序繼續執行，代碼返回，執行log。從writeQuery看我們用同步的寫法完成了異步操作。當協程被suspendCoroutine切換走後，線程可以繼續調度其他可以執行的協程來執行，因此不會真正阻塞，我們因此獲得了性能提升。

從這裡看，只需要我們有一個機制來保存/恢復執行上下文，並且在阻塞庫函數里採用非阻塞+回調的方式讓出/恢復協程，就可以使得以同步形式編寫的程序達到和異步同樣的效果了。

理論上只要有一個庫包裝了所有JDK阻塞方法，我們就可以暢快地編寫異步程序了。改寫的阻塞庫函數本身需要足夠地通用流行，才能被大部分程序使用起來。據我所知，vert.x的kotlin支持已經做了這樣的封裝。

雖然vert.x很流行，但是無法兼顧遺留代碼以及代碼中的鎖阻塞等邏輯。因此不能算是最通用的選擇。實際上Java程序有一個繞不過的庫——JDK。Wisp就是在JDK裡所有的阻塞調用出進行了非阻塞+事件恢復協程的方式支持了協程調度，在為用戶帶來最大便利的同時，兼顧了現有代碼的兼容性。

上述方式支持了，每個線程不太需要阻塞，Wisp在Thread.start()處，將線程轉成成了協程，來達到了另一目的: 活躍線程數約等於CPU個數。因此只需要使用Wisp協程，所有現有的Java多線程代碼都可以獲得異步的性能。

手工異步/Wisp性能比較

對於基於傳統的編程模型的應用，考慮到邏輯清晰性、異常處理的便利性、現有庫的兼容性，改造成異步成本巨大。使用Wisp相較於異步編程優勢明顯。

下面我們在只考慮性能的新應用的前提下分析技術的選擇。

基於現有組件寫新應用

如果要新寫一個應用我們通常會依賴JDBC、Dubbo、Jedis這樣的常用協議/組件，假如庫的內部使用了阻塞形式，並且沒有暴露回調接口，那麼我們就沒法基於這些庫來寫異步應用了(除非包裝線程池，但是本末倒置了)。下面假設我們依賴的所有庫都有回調支持，比如dubbo。

1）假設我們使用Netty接受請求，我們稱之為入口eventLoop，收到請求可以在Netty的handler裡處理，也可以為了io的實時性使用業務線程池。

2）假設請求處理期間需要調用dubbo，因為dubbo不是我們寫的，因此內部有自己的Netty Eventloop，於是我們向dubbo內部的Netty eventLoop處理IO，等待後端響應後回調。

3）dubbo eventLoop收到響應後在eventloop或者callback線程池調用callback。

4）後續邏輯可以在callback線程池或者原業務線程池繼續處理。

5）為了完成對客戶端的響應最終總是要由入口的eventloop來寫回響應。

我們可以看到由於這種封裝導致的eventLoop的割裂，即便完全使用回調的形式，我們處理請求時多多少少要在多個eventLoop/線程池之間傳遞，而每個線程又都沒法跑到一個較滿的程度，導致頻繁地進入os調度。與上述的每個線程不太需要阻塞原則相違背。因此雖然減少了線程數，節約了內存，但是我們得到的性能收益變得很有限。

完全從零開始開發

對於一個功能有限的新應用(比如nginx只支持http和mail協議)來說我們可以不依賴現有的組件來重新寫應用。比如我們可以基於Netty寫一個數據庫代理服務器，與客戶端的連接以及與真正後端數據庫的連接共享同一個eventloop。

這樣精確控制線程模型的應用通常可以獲得很好的性能，通常性能是可以高於通過非異步程序轉協程的，原因如下：

線程控制更加精確：舉個例子，比如我們可以控制代理的客戶端和後端連接都綁定在同一個netty線程，所有的操作都可以threadLocal化

沒有協程的runtime和調度開銷(1%左右)

但是使用協程依舊有一個優勢：對於jdk中無處不在的synchronized塊，wisp可以正確地切換調度。

適應的Workload

基於上述的背景，我們已經知道Wisp或者其他各種協程是適用於IO密集Java程序設計的。否則線程沒有任何切換，只需要盡情地在CPU上跑，OS也不需要過多的干預，這是比較偏向於離線或者科學計算的場景。

在線應用通常需要訪問RPC、DB、cache、消息，並且是阻塞的，十分適合使用Wisp來提升性能。

最早的Wisp1也是對這些場景進行了深度定製，比如hsf接受的請求處理是會自動用協程取代線程池，將IO線程數量設置成1個後使用epoll_wait(1ms)來代替selector.wakeup()，等等。因此我們經常受到的一個挑戰是Wisp是否只適合阿里內部的workload？

對於Wisp1是這樣的，接入的應用的參數以及Wisp的實現做了深度的適配。

對於Wisp2，會將所有線程轉換成協程，已經無需任何適配了。

為了證明這一點，我們使用了web領域最權威的techempower benchmak集來驗證，我們選擇了com.sun.net.httpserver、Servlet等常見的阻塞型的測試(性能不是最好，但是最貼近普通用戶，同時具備一定的提升空間)來驗證Wisp2在常見開源組件下的性能，可以看到在高壓力下qps/RT會有10%~20%的優化。

Project Loom

Project Loom作為OpenJDK上的標準協程實現很值得關注，作為java開發者我們是否應該擁抱Loom呢？

我們首先對Wisp和Loom這裡進行一些比較：

1）Loom使用序列化的方式保存上下文，更省內存，但是切換效率低。

2）Wisp採用獨立棧的方式，這點和go類似。協程切換隻需切換寄存器，效率高但是耗內存。

3）Loom不支持ObectMonitor，Wisp支持。

synchronized/Object.wait()將佔用線程，無法充分利用CPU。

還可能產生死鎖，以Wisp的經驗來說是一定會產生死鎖(Wisp也是後來陸續支持ObectMonitor的)。

4）Wisp支持在棧上有native函數時切換(反射等等)，Loom不支持。

對dubbo這樣的框架不友好，棧底下幾乎都帶有反射。

總根據我們的判斷，Loom至少還要2年時間才能到達一個穩定並且功能完善的狀態。Wisp的性能優秀，功能要完整很多，產品本身也要成熟很多。Loom作為Oracle項目很有機會進入Java標準，我們也在積極地參與社區，希望能將Wisp的一些功能實現貢獻進社區。

同時Wisp目前完全兼容Loom的Fiber API，假如我們的用戶基於Fiber API來編程，我們可以保證代碼的行為在Loom和Wisp上表現完全一致。

FAQ

協程也有調度，為什麼開銷小？

我們一直強調了協程適用於IO密集的場景，這就意味了通常任務執行一小段時間就會阻塞等待IO，隨後進行調度。這種情況下只要系統的CPU沒有完全打滿，使用簡單的先進先出調度策略基本都能保證一個比較公平的調度。同時，我們使用了完全無鎖的調度實現，使得調度開銷相對內核大大減少。

Wisp2為什麼不使用ForkJoinPool來調度協程？

ForkJoinPool本身十分優秀，但是不太適合Wisp2的場景。

為了便於理解，我們可以將一次協程喚醒看到做一個Executor.execute()操作，ForkJoinPool雖然支持任務竊取，但是execute()操作是隨機或者本線程隊列操作(取決於是否異步模式)的，這將導致協程在哪個線程被喚醒的行為也很隨機。

在Wisp底層，一次steal的代價是有點大的，因此我們需要一個affinity，讓協程儘量保持綁定在固定線程，只有線程忙的情況下才發生workstealing。我們實現了自己的workStealingPool來支持這個特性。從調度開銷/延遲等各項指標來看，基本能和ForkJoinPool打平。

還有一個方面是為了支持類似go的M和P機制，我們需要將被協程阻塞的線程踢出調度器，這些功能都不適宜改在ForkJoinPool裡。

如何看待Reactive編程？

Reactive編程模型已經被業界廣泛接受，是一種重要的技術方向；同時Java代碼裡的阻塞也很難完全避免。我們認為協程可以作為一種底層worker機制來支持Reactive編程，即保留了Reactive編程模型，也不用太擔心用戶代碼的阻塞導致了整個系統阻塞。

這裡是Ron Pressler最近的一次演講，作為Quasar和Loom的作者，他的觀點鮮明地指出了回調模型會給目前的編程帶來很多挑戰 。

Wisp經歷了4年的研發，我將其分為幾個階段：

1）Wisp1，不支持objectMonitor、並行類加載，可以跑一些簡單應用；

2）Wisp1，支持了objectMonitor，上線電商核心，不支持workStealing，導致只能將一些短任務轉為協程(否則workload不均勻)，netty線程依舊是線程，需要一些複雜且trick的配置；

3）Wisp2，支持了workStealing，因此可以將所有線程轉成協程，上述netty問題也不再存在了。

目前主要的限制是什麼？

目前主要的限制是不能有阻塞的JNI調用，wisp是通過在JDK中插入hook來實現阻塞前調度的，如果是用戶自定義的JNI則沒有機會hook。

最常見的場景就是使用了Netty的EpollEventLoop：

1）螞蟻的bolt組件默認開啟了這個特點，可以通過-Dbolt.netty.epoll.switch=false 來關閉，對性能的影響不大。

2）也可以使用-Dio.netty.noUnsafe=true , 其他unsafe功能可能會受影響。

3）(推薦) 對於netty 4.1.25以上，支持了通過-Dio.netty.transport.noNative=true 來僅關閉jni epoll，參見358249e5

———————————————— 河南新華

慎談奧秘

go和python的出現，正在逐漸改變整個it互聯網行業，讓開發者有更好的選擇，以前可能會在c++ Java c#之間決策，現在這兩門新興語言的崛起，會給JAVA一定的壓力，未來甚至可能還會超越JAVA。

python學習起來是最簡單的，能夠讓新手快速工作，不需要考慮內存，指針，甚至是效率。同時它提供了豐富的功能，包括網絡，繪圖，工具等，近年來Python的強勢是大家有目共睹的。

go的執行效率是非常的高，甚至有時候能夠達到c++的運行速度。在這方面也有人嘗試把c++代碼移植到go，相對來說go比c++更安全。目前市場上招聘，go的崗位也越來越多。

綜上所述，開發立項之初，相比JAVA而言，可能會有更多的因素選擇go和python!

cpp架構

Java不僅僅是Java語言了，而是一個以Java為中心的生態圈，在這個生態圈裡面可以滿足你需要的各種資源，也是這麼多年發展起來的。

而Go語言就算說的有多麼強大，但是要發展起來還是需要一段時間的，近期來看Java還是很好的選擇，也比較成熟。不過對於有些新的應用，並且也是go適合的場景，嘗試一下go也未嘗不可。

淺析架構

這個問題的看待不能只從技術層面，技術的誕生服務於人，不論什麼技術最後都是服務與人的，go在一定程度上確實優異於java，但是它不一定是最佳選擇，在開發商選用技術語言通常要考慮多方面，人工成本，生態環境，穩定性，乙方接受程度，人才繼承性，總不能開發完的系統以後招個人維護都難，綜合各個因素來說，go的最佳選擇性就會降低很多。

關鍵字: 編程語言 開發人員 科技