V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
hopingtop
V2EX  ›  Visual Studio Code

快 2024 年, Go 语言下 vscode 对比 Goland 还有哪些劣势?

  •  
  •   hopingtop · 125 天前 · 4469 次点击
    这是一个创建于 125 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我在 2018 年初用的 Goland ,之前用了一段时间 vscode (当然还有古老的 liteIDE ?就是一个太极图标那个)感觉要配置的东西还是比较多,而且 DEBUG 也不方便。今天在家里面迫于忘带公司的电脑( Goland 是公司内网授权),得看下代码,就配置了一下 vscode 发现,现在配置如此快捷,就是安装一个 Go 的插件,然后 install all 基本上就完成了。

    目前就是 Go 插件 + Go struct tag

    体验下来:
    1. 发现现在 Go 插件很强大了,目前对比下来好像没有缺少之处,是我 Goland 用的不深?
    2. Debug 功能目前也挺好用的,体验几乎一致,就是不太清楚稳定性怎么样?
    3. 我初体验 vscode 上的 Copilot 好想比 Goland 上面的好用一些,主要是感觉要丝滑一些,目前 Goland 总是会出现 Mem 的内容和 File 内容不一致的 弹框,很影响体验。还有就是一些 猜想弹框也挺适合的

    因为本人之前用 Goland 主要是 编码+DEBUG 和极少的配置

    但是现在感觉下来好想 vscode 都能做到?

    你们觉得 Goland 在 Go 情况对比 vscode 还有哪些明显的优势?

    大项目不卡?提示快?

    但是。。vscode 一个免费+丰富插件 感觉优势好大,目前通过账号同步配置,多台设备迁移也比以前方便太多了!

    想听听水友们的体验,如果没有明显的坑,我就有点想切换到 vscode 了! Goland 不便宜

    第 1 条附言  ·  124 天前
    感谢各位水友的回答!!!我感觉我也可以慢慢切入到 vscode 了! 带着发展的眼光看,目前主要是感觉 Goland 已经很久没有那种让人大获惊喜的改进了!还要考虑到费用问题。
    51 条回复    2023-12-27 16:31:58 +08:00
    N0rman
        1
    N0rman  
       125 天前 via Android
    补充一个 JSON to Go ,但我是冲着 monokai pro 和免费
    heww
        2
    heww  
       125 天前   ❤️ 3
    Go Group Imports, Go Struct Tag Autocomplete & Generator, SemanticDiff, Tooltitude for Go (GoLang), Go Mod Explorer, Koverage, Coverage Gutters, Ginkgo Test Explorer
    XCFOX
        3
    XCFOX  
       125 天前   ❤️ 1
    vs code 能无痛远程开发,本地连环境都不用装,Goland 不能
    just1
        4
    just1  
       125 天前
    vscode 能搜索标准库及所有引用的第三方 package 不( interface 的实现及普通文本搜索)
    LonelinessA
        5
    LonelinessA  
       125 天前
    目前能感觉到 goland 的优势在于索引,之前有尝试过用 vscode 阅读一个框架源码,找着找着就莫名其妙找不到北了,然后用 goland 重新走了一遍,发现 vscode 少了几个引用索引
    steveway
        6
    steveway  
       125 天前
    @XCFOX vsc 的远程开发真的做的比 goland 好多了
    dacapoday
        7
    dacapoday  
       125 天前   ❤️ 1
    vscode 的 go 插件是 golang 团队亲自构建的,肯定比 goland 更懂 go ,劣势就是因为是免费的,容易被外行人士(比如 javaer)评价为不够专业。
    thinkershare
        8
    thinkershare  
       125 天前   ❤️ 1
    没想到有什么特别影响体验的地方,我现在除了.NET ,其它编程语言的代码统一都用 vscode 搞,all in one, 不同的编程语言用不同配置文件和插件,然后配合 Copilot, 感觉很好,实在有不舒服的地方,就自己用 ts 搞插件增强一下。主要还是 vscode 的远程工具实在太强大了,还在一直增强,我现在用它来显示 Linux 的远程 UI 图像。
    AEnjoyable
        9
    AEnjoyable  
       125 天前   ❤️ 1
    快速浏览一个 go 代码的话我选择 vsc ,毕竟轻量,不卡顿。但是要说编写我还是选择 goland ,习惯 goland 了 快捷键和高亮什么的。
    当然,还有就是可能我这边 vsc 配置不太对吧,vsc 打开 go 的项目经常会报一些奇奇怪怪的 error 或者 warning (插件装了),但是能编译,goland 就没问题
    专业性也确实吧,我觉得 goland 专业性确实更高
    hopingtop
        10
    hopingtop  
    OP
       124 天前
    @just1 #4 目前我简单了用了一下,interface 的实现和引用 索引还很不错,会在左边弹出一个边框让你看到所有
    hopingtop
        11
    hopingtop  
    OP
       124 天前
    还有一个感觉比较友好的,DEBUG 时 测试方法执行列表,vscode 可以在右侧,显示执行记录,这样我测试之前用过的方法会快捷一点。Goland 如果运行一个新 Test ,如果之前的是退出状态,就会覆盖掉。。。。有时想看记录就真实蛋疼
    kuanat
        12
    kuanat  
       124 天前   ❤️ 1
    我用 GoLand 非常少,印象里有几个方面比 VS Code 要好:

    1. 自动补全更加“智能”,或者说排序、展示形式更人性化更符合预期
    2. 重构支持 interface/implementation ,而 gopls 还在 symbol 层面
    3. 代码跳转( navigation )更舒适
    4. Debugger 更好用?
    5. 自带 vim 键位比 VS Code 插件好用

    这里面 1 是短时间 VS Code 追不上的,这个需要投入比较多的人工打磨,不是个技术问题。

    第 2 点 gopls 是可以做功能支持的,但是需要 VS Code 插件端提供一套 UI 流程,确认哪些要改哪些保留,我个人觉得是无所谓的。第 3 点也差不多,VS Code 是个 editor ,UI/UX 是不如 IDE 的,但这一点说实话我觉得不影响,但是还是列出来了。第 4 点,我周围的人说 GoLand 好用,但我个人觉得是个习惯问题,现在来说 Delve 做得越来越好了。最后第 5 点,现在都用 VS Code 集成一个 neovim 实例,我觉得已经反杀了。

    除了第 1 点,剩下的优势其实是源于插件功能受限于 VS Code 界面机制,不如 IDE 那么灵活。



    我是 old school 派的,所以对 editor+plugin 的好感远大于 IDE 。自从 VS Code 出来,标准化了 LSP/DAP 之后,我的就开始 vim/VS Code 并用,原因是我可以花时间为开发用的语言做配置,但是很多时候要阅读那些我不写的语言的代码,VS Code 提供了很好的默认配置。再后来微软的 Remote 开发成熟了,我就彻底转向了 VS Code ,同时用 neovim 替代了 vim 。

    GoLand 我自己在 2021 年前后短暂用过。个人观点是,在 2022 年之前,GoLand 优势还是比较明显的,但是 2022 年之后,GoLand 的优势只在细节层面了。技术层面无论是当下还是未来,可能都追不上 VS Code 了。

    2021 这一年,VS Code Go 体验有了质的飞跃。一是实现了 Testing API ,二是和 Delve 合作支持了 DAP 。没有多长时间,又实现了 Testing/Benchmark 的可视化,DAP 也支持了远程 attach 。测试 Debug 成了真正可用的特性。

    之后 2022 年都是些细节改善,比较大的功能就是 inlay hints 。到现在体验已经非常好了。
    guanzhangzhang
        13
    guanzhangzhang  
       124 天前
    @XCFOX 我发现远程无法跳转代码,需要安装哪个插件吗
    ic3z
        14
    ic3z  
       124 天前 via iPhone
    goland 要钱💰
    dcoder
        15
    dcoder  
       124 天前
    作为后端,一直不了解你们成迷于远程开发是为啥.
    正确不步骤不该是自己 local 调试好了,脚本 push/deploy 到 cluster 里所有的机器.
    这样的话,即使调远程调试,也应该在远程的 *一个* server 机器上调试么? 类似你 local 的开发机.
    真的要调试分布式程序,不该是打 log ,然后在 log service 上看么. stage, prod 都改如此搞.
    所以你们远程调试的有点到底是啥?
    Rehtt
        16
    Rehtt  
       124 天前
    我现在是 nvim + gopls
    herozzm
        17
    herozzm  
       124 天前
    vscode 和 专门写 go 的 goland 不是一个量级的,各个方面
    CodeCodeStudy
        18
    CodeCodeStudy  
       124 天前   ❤️ 1
    VSCode 的 Golang 的自动 import 很难用,有谁介绍一下吗
    lrh3321
        19
    lrh3321  
       124 天前 via Android
    @dcoder #15 远程开发当然是为了保证开发环境和运行环境尽量一致。你也不想,一次开发处处调试吧。另外,在本地把各种依赖都搭好或,mock 掉,不如直接用测试环境的现成资源。
    hopingtop
        20
    hopingtop  
    OP
       124 天前
    @kuanat #12 感谢你的用心回答! 我现在回过头来用,真的是感觉有了质的飞跃!接下来我会逐步迁移到 vscode ,后续又更多的体验也会总结更新!
    hopingtop
        21
    hopingtop  
    OP
       124 天前
    @dcoder #15 有时候数据层隔离的,数据只有 remote 的机器才能调取,有些比较复杂的项目还有相关依赖,比如云机器上面的 Agent 等等, 本地都跑不起来的,所以这个时候能远程就真的很 nice 。 不然本地只能 人肉编译看是否有 BUG , 这样出错的概率会大大增加的!
    hopingtop
        22
    hopingtop  
    OP
       124 天前
    @herozzm #17 不应这么绝对,带着发展的眼光看,我挺赞同#12 的分析
    HowToMakeLove
        23
    HowToMakeLove  
       124 天前
    refactory 很强大,关联 namespace 自动调整
    多函数搜索,文件搜索
    method struct
    做项目还是推荐 goland ,浏览文件推荐 vsc
    gongquanlin
        24
    gongquanlin  
       124 天前
    感觉 vscode 上各种语言的 evaluate expression 都不如 jetbrains 家的好用……不知道有没有解决办法?
    bthulu
        25
    bthulu  
       124 天前
    @dcoder 不是想成迷于远程开发, 而是线上出 bug 了, 线上直接改最简单高效. 线下改还要重新发版, 麻烦的很.
    lvlongxiang199
        26
    lvlongxiang199  
       124 天前
    额外提一下 goland 的其它优点/功能
    + 能查 mysql, pgsql 之类的数据库
    + 能直接发 gRPC, http 请求, 调试起来
    + git 功能感觉比 vscode 更好用
    echoZero
        27
    echoZero  
       124 天前
    上周刚刚发现 goland 的一个高级功能,支持 go 三方库 安全检测,自动提示出库是否有 CVE 漏洞,以及其修复版本
    echoZero
        28
    echoZero  
       124 天前
    @dcoder 我司配的是 windows 电脑,开发 golang 一言难尽。都是自己搞个虚拟机然后远程开发
    ZxykM
        29
    ZxykM  
       124 天前
    @guanzhangzhang 你需要在远程主机单独装 go 的插件
    equationzhao
        30
    equationzhao  
       124 天前
    我觉得各有优势

    goland 补全和提示, 连数据库, 跳转比较舒服
    vscode 在行内可以直接集成 GitHub 的 PR 的对话, 有一个统一的测试栏, 把所有 test 函数列出来

    goland 索引也有些 bug

    jrqlxue
        31
    jrqlxue  
       124 天前
    之前用 goland 习惯了,第一次转 vscode 感觉不方便,感觉主要是
    1. 补全、提示、跳转、自动修正可能更好或者更习惯
    2. 快捷键和各种命令菜单可能更方便或者更习惯
    3. git 提交一个是功能丰富的弹窗,一个是侧边一个小输入框,差异显著,尤其是写长和结构复杂的 commit 文本(个人习惯只加 emoji 但是 vscode 就常常提示超长度)

    不过 goland 好像从去年末支持泛型开始一方面 index 各种卡(启动需要忍受),另一方面 debug 时中间值卡的出不来,后来就没用了
    elechi
        32
    elechi  
       124 天前
    用 jb 家的已经习惯了从来不 ctrl+s 了,也算更方便了点
    gerefoxing
        33
    gerefoxing  
       123 天前
    jetbrain 系列产品 git 功能比 vscode 的好用。
    hopingtop
        34
    hopingtop  
    OP
       123 天前
    @gerefoxing #33 我最开始以为也很简单,但是打开 GITLENS 感觉也还好, 但是还没深度使用的
    dyllen
        35
    dyllen  
       123 天前
    @bthulu 还能有线上直接改的。。。。真会玩。
    edisonwong
        36
    edisonwong  
       123 天前
    1. 快捷键统一 。我经常同时开着 goland 、pycharm 、datagrip ,有时候还有 webstorm 偶尔还有 intellij 。统一的交互和行为减少了使用成本。其他的语言的话,轻量点的我还用 fleet ,不过一言难尽。。
    2. vscode 各种插件,配置快捷键我是研究不明白😂,还有不同电脑的配置同步 ide 配置,我用 gist ,发现不怎么好用。。
    3. 确实吃配置。我 32g 的电脑,goland (四五个项目),datagrip ,webstorm ( 2 个)就右下角弹窗内存不足了。。。
    dcoder
        37
    dcoder  
       123 天前
    @lrh3321 #19 dev/stage/prod 环境要强一致的话,不应该是 docker/LXC 之类实现的么? 另外, 不想在本地搭建整个 dev 环境的话, 可以设置 dev 环境里的各种 proxy, 可以让本地 service 假装在 dev 环境里.
    我假设我说的是针对后端开发,构架是 micro services.
    dcoder
        38
    dcoder  
       123 天前
    @hopingtop #15 各种安全要求确实烦,在有些很别扭的安全要求下,即使 remote 也难以跑起来...
    如果你们公司的东西,本地就是跑不起来,那没办法了. 我也在这种公司 or 组工作过, 很痛苦, 可以理解...
    dcoder
        39
    dcoder  
       123 天前
    @bthulu 你这个"线上直接改最简单高效. 线下改还要重新发版"
    是在 production 上直接裸奔改 bug 么? 那你司风格粗犷, 哈哈哈
    dcoder
        40
    dcoder  
       123 天前
    @echoZero 这种本地虚拟机开发,goland 也可以搞定吧
    dcoder
        41
    dcoder  
       123 天前
    你们要在 remote server/dev 机器上跑 VSCode server, 然后远程开发的, 不会卡么...
    如果后端构架是 micro services 的话, dev/stage 的机器比本地开发机器弱太多了吧, 大点的项目不得卡死.

    我能想到的最适合 remote 开发的, 是那种很贵很大的科学计算服务器, 因为 remote server 比本地强多了.
    不然你留着本地 16G/32G Mac Book Pro 不用,连到 remote micro service server, VSCode LSP server 在 remote 大项目 repo 上一跑,间歇性卡到不行,不是很影响开发体验.
    dcoder
        42
    dcoder  
       123 天前
    在非特殊的, 大多数情况下,如果开发环境在 local 跑不起来,那多半是 CTO/Infra/DevOps 们没好好设计, 最后是干活的工程师生活质量受影响. 用 remote 开发, 一般是补偿这种 infra 设计上的问题... 后端的组呆多了, 有时候就是这样, 遇上了也没办法, 只能适应.
    lrh3321
        43
    lrh3321  
       123 天前
    @dcoder #37 只能说你很幸运,不像我们有那么多翔要忍。大家的业务都不一样。不是什么都能 proxy 的。你本地发 MTU 9000 的巨型帧到测试环境试试。
    echoZero
        44
    echoZero  
       123 天前
    @dcoder 不一定是本地虚拟机,有云平台的。之前体验过 goland 的远程开发 ,激活那些都是麻烦事
    bthulu
        45
    bthulu  
       123 天前
    @dcoder 有什么问题么? 不涉及到钱的, 直接改, 就算改错了, 马上恢复就是, 又能有什么问题? 直接改难道不是解决问题最快的方式么? 你还在那吭哧吭哧的跑流程, 我这边早已经改好了.
    hopingtop
        46
    hopingtop  
    OP
       123 天前
    @lrh3321 #43 哈哈,很形象,特别是接到特别老的历史项目, 扒拉各种 shit 啊
    hopingtop
        47
    hopingtop  
    OP
       123 天前
    @bthulu #45 不一定,多数情况下,如果这个项目是你一手起来的,那么你直接改,解决问题的概率可能是 99.9%, 但是如果是接手的一个项目,那么考虑的问题就多了,最好保持原始流程最小改动,说不定就被某种特殊场景坑了
    Nazz
        48
    Nazz  
       123 天前
    公司不允许用盗版软件, goland 自带的 datatrip 比免费数据库 ui 都强.
    dcoder
        49
    dcoder  
       123 天前
    @lrh3321 我也做过在 local 跑步起来的项目,可以理解. 不过你们测试都要考虑 MTU 大小, 确实挺特殊的.
    dcoder
        50
    dcoder  
       123 天前
    @bthulu 打工的话,最好还是走流程.
    如果是自己的项目, 可以. 但也仅仅限于单机 service, 不然改的部分不方便 sync 到其它 service replicas.
    guanzhangzhang
        51
    guanzhangzhang  
       121 天前
    @ZxykM 大佬,我 linux 机器上 go install 了那些二进制,也 vscode 的扩展里显示 远端安装了 Go 扩展 ,写的时候还是报错 gopls was not able to find modules in your workspace
    🤔,是不是需要项目目录下配置`.vscode/xxx` 啥的才能解决
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2928 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 07:58 · PVG 15:58 · LAX 00:58 · JFK 03:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.