Visual Studio Code / VSCode Part16

**デフォルトの名無しさん** · 2025/03/08(土) 12:54:14.95

Microsoft発のエディタVisual Studio Codeのスレ

公式
https://code.visualstudio.com/
https://github.com/Microsoft/vscode/

開発状況
https://github.com/Microsoft/vscode/wiki/Iteration-Plans

更新内容(日本語訳)
https://vscode-doc-jp.github.io/updates/

前スレ
Visual Studio Code / VSCode Part13
https://mevius.5ch.net/test/read.cgi/tech/1656984270/
Visual Studio Code / VSCode Part14
https://mevius.5ch.net/test/read.cgi/tech/1678807578/
Visual Studio Code / VSCode Part15
https://mevius.5ch.net/test/read.cgi/tech/1716707929/

**デフォルトの名無しさん** · 2025/03/08(土) 13:01:11.48

VSCodeの設計とか将来性の話はいいけどマイクロソフトアンチみたいなのは他所でやろうや。俺もアンチだしウィンドウズすら使わんけど、codeは使い続けてるし拡張も自分で作って遊んでる。モノとしてのcodeはマイクロソフトとは別モンと思って使ってる

999：デフォルトの名無しさん：[sage]：2025/03/08(土) 02:41:23.91 ID:EirLqTwB
MSは金の力でAtomパクって潰しGithub強奪しただけだしな
スマホ政策の失敗で開発の中枢からはじき出された状態に変わりはないし
VSCodeの古臭さが限界にぶち当たった時廃れ始める
C#のようにね

**デフォルトの名無しさん** · 2025/03/08(土) 13:15:40.92

俺もアンチだがVSCodeはMSにしてはよくやってると思うわ
MSのCopilotは駄目すぎて笑うけど

**デフォルトの名無しさん** · 2025/03/08(土) 13:35:03.02

MSのプロダクトは殿様商売するとゴミだが追う立場になると異常に強くなる
初期リリースの2015年当時あたりはガチで開発環境としてはWindowsなんて誰も使わなくなるんじゃないか感があったが、VSCodeとWSLによって奇跡的な復活を果たした
OfficeのCopilotは確かに酷いが、AI市場は他に奪われた後に結局MSが巻き返してしまう気はしてる

**デフォルトの名無しさん** · 2025/03/08(土) 13:56:37.89

そのシナリオはあり得るけど、エージェント駆動であらゆる仕事をしていく時代に
はたしてOfficeというエコシステム資産の価値がどこまで続くか疑問

Appleもだけど、これからGAFAMの一角が倒れる瞬間を目にできるとしたら楽しみだわ

**デフォルトの名無しさん** · 2025/03/08(土) 13:59:03.20

VS CodeのVSってなんじゃろう
対決とかのVS？

**デフォルトの名無しさん** · 2025/03/08(土) 14:12:04.48

Visual Studio

**デフォルトの名無しさん** · 2025/03/08(土) 14:12:40.92

>>6
>>1

**デフォルトの名無しさん** · 2025/03/08(土) 17:52:41.76

＞LLMがシンタックスエラー等を判断できるのは既存のさまざまな拡張のおかげ、
＞C++拡張やらtust-analyzerやらts拡張やらlintやら。これらのアサート機能なきゃLLMは目が見えないのと同じ。素のエディター部分はVSCodeのありがたみの2割ぐらいなんではなかろうか
＞
＞もちろん、人間が理解しやすいのとLLMが理解しやすいは異なるので、一から全部LLMが読みやすいメッセージフォーマットで出力するよう作れれば最適化できると云うのは賛同するが開発が早くはないよな。ゴールが遠すぎて

前スレの最後のレスについて
これは古い時代の考え方
LLMは各言語のシンタックスを覚えている
だから個別の拡張はいらない
コードを書くということがなくなるのだ

**デフォルトの名無しさん** · 2025/03/08(土) 17:54:12.55

>>5
Officeもいらない
全部自動生成でいい

**デフォルトの名無しさん** · 2025/03/08(土) 18:03:12.40

LLMを使うのであればローカルで必要なVSCode拡張はゼロになるだろう
現時点ではまだいくつかは必要だろうけどそれもそのうちいらなくなる

**デフォルトの名無しさん** · 2025/03/08(土) 18:06:38.62

>>6
Visual Studioとなってるけど何も関係ないのでもうCodeという名前で良いと思う

**デフォルトの名無しさん** · 2025/03/08(土) 22:03:30.43

wsl起動しちゃう

**デフォルトの名無しさん** · 2025/03/08(土) 22:16:48.33

Windows環境でもWSLリモート接続で何ら不都合ないって地味にすごいし有り難い
Powershellなんて使いにくいし覚えるのも馬鹿馬鹿しいからね

**デフォルトの名無しさん** · 2025/03/08(土) 23:39:53.83

>>6
その会社の有名な製品名を付けると知名度が上がる理屈もわからないのか？

**デフォルトの名無しさん** · 2025/03/08(土) 23:41:38.97

まあこのネームは失敗だよ
紛らわしいだけ

**デフォルトの名無しさん** · 2025/03/08(土) 23:47:15.22

>>16
マイクロソフトは伝統的に命名センスがない

**デフォルトの名無しさん** · 2025/03/09(日) 12:41:28.26

Azure DevOps……

**デフォルトの名無しさん** · 2025/03/09(日) 12:52:59.25

AWSの製品名もだが、それも未だに自分はなにが範囲なのかわからんサービス・・・

**デフォルトの名無しさん** · 2025/03/09(日) 13:27:37.52

Azure DevOpsはあんなゴミさっさと廃止してGitHubをAzure内で買えるようにしてくれ
あのクソのせいでGitHubを導入させる説明のハードルが上がるんだよ

**デフォルトの名無しさん** · 2025/03/09(日) 13:43:14.57

普通はDevOpsの方使いやろ
チケット管理別にするん？

**デフォルトの名無しさん** · 2025/03/09(日) 14:32:35.68

別もなにも大抵のチケット管理サービスはGitHubと連携できるし、簡単なカンバンだけでいいならGitHub Projectも十分使える
Azure DevOpsを選ぶ理由はAzureを使っていれば追加の契約が不要なこととEntraID連携が楽で安いこと、それに尽きる
しかし上記はエンタープライズでは極めてクリティカルなので何とかしてほしいところだ

**デフォルトの名無しさん** · 2025/03/09(日) 16:02:02.97

Azure DevOps自体がゴミというより、Azureが好評だったからってその一部ではない既存のソフトの名前を変更してAzureって付けるセンスがゴミって話
驚き最小の原則に反している

ASP.NET Core……

**デフォルトの名無しさん** · 2025/03/09(日) 16:51:01.00

有能な社員「今度の案件はVisual Studio Codeを使います。いいですよね？」
無能な上司「あーいつものビジュアルナントカでしょ？わざわざ聞かなくていいよ」
有能な社員「あざーっす」

こういうの大事なんだよ。アトムやらカーソゥやらウィンドサーフだったらこうはいかない。

**デフォルトの名無しさん** · 2025/03/09(日) 17:34:46.74

そしてgithubでソース流出へ

**デフォルトの名無しさん** · 2025/03/09(日) 18:32:05.53

さっさとやめちまえとマジレス
日本の大企業あるあるだがそんな会社は来たるAI時代に駆逐されるだろう

ChatGPT Enterpriseは危険だけどAzure OpenAIなら安全性が担保されてるから安心とかね
実体を分かって言ってんならまだしも実際はMSの能書きを脳死で受け入れてるだけだし

**デフォルトの名無しさん** · 2025/03/09(日) 19:16:49.92

話を戻すがAIエージェントの登場でVSCode一強の時代は終わるかもしれない
VSCodeの肝である拡張相当の機能が実質LLMに内包されている事実
提案されたコードを修正する場合も全てLLMを通すため
ローカル環境の拡張がいらなくなる
ということはエディタのコアにLLMがあれば良い
こうなった時VSCodeの優位性は薄れていくだろう

**デフォルトの名無しさん** · 2025/03/10(月) 21:39:07.11

MSは一強になると調子に乗っておかしくなるからライバルが出てくるのは歓迎

**デフォルトの名無しさん** · 2025/03/11(火) 01:09:43.65

もともと機能が多すぎる統合開発環境が嫌われ出してテキストエディタ回帰になり、VSCodeが広まったのにVSCodeが統合開発環境のVisual Studio化してとっつきにくくなって嫌われ始めた。

CUIを使うと玄人のように装えるが、それは単に格好付けにすぎないからな。

**デフォルトの名無しさん** · 2025/03/11(火) 08:59:48.47

それは事実と全く違っていて、eclipseの鈍重なイメージでIDEを食わず嫌いしていたWeb系の連中が、VSCodeによってIDE(に近いもの)の便利さに気付いて一気に流行ったというのが実態
IDEでもVSやJetBrainsは嫌われていないし、VSCode批判も今のところ極一部が逆張りで目立とうと試みているだけで、実際に遅くなってたAtomなんかと違って実態があまり伴ってないから盛り上がらない

**デフォルトの名無しさん** · 2025/03/11(火) 09:37:45.82

>>30
個人の感想です。

**デフォルトの名無しさん** · 2025/03/11(火) 10:03:16.30

eclipseってjavaだとまだ主流なの？

**デフォルトの名無しさん** · 2025/03/11(火) 10:11:19.75

昔、組み込みのideがそれだったよ。emacsとmakeに逃げたけど。

**デフォルトの名無しさん** · 2025/03/11(火) 11:06:34.67

IDEってまだ残ってんのか
自分も昔はVS使ってたし、VSCodeが出た当時は「悪くないんだけどまー所詮はエディタだし」と思ってたけど
今はAI駆動で開発スタイルも完全に変わったから旧来のIDEはますます厳しくなるだろう
アップデートスピードが命な時代だから

**デフォルトの名無しさん** · 2025/03/11(火) 11:53:54.96

機器メーカーが提供するIDEはいまでもEclipseベースが多いんではないの？
IDEって最初からお膳立てしてくれてるだけであってAI駆動の有無は関係ないしね
旧来のってとこに掛けてんのかもしれんけど

**デフォルトの名無しさん** · 2025/03/11(火) 14:19:28.99

で今javaのエンジニアはまだeclipseが主流なん？
c#はいまだにvisual studioなのしってるけどwww

**デフォルトの名無しさん** · 2025/03/11(火) 15:10:21.18

エディタの優位性なんて拡張の豊富さ以外でほぼ差がつかない時代だった
その拡張が全てリセットされた新時代に突入した

**デフォルトの名無しさん** · 2025/03/11(火) 16:01:44.51

>>36
ハイエンドはIntelliJ
人月業界はeclipse

**デフォルトの名無しさん** · 2025/03/12(水) 01:00:28.23

コンソールにviと人工知能だけありゃいいってそりゃ1960年代に逆戻りだよな
もちろん、音声での応答機能は付くだろうけどIDEのでかいフォントに慣れた俺らからするとシンタックスハイライトとか無くなってめっちゃ小フォントサイズでモノクロ表示になるのキツいよね

コンピューターは文字を読むのではなくparseして意味を解釈するだけで満足だしなあ。今後発売予定の新型AIパソコンではフォントすらインストールされないかも！

**デフォルトの名無しさん** · 2025/03/12(水) 01:02:30.73

>>37
エディターの最大の要素は見やすさ。特にここ最近小さな字が読みにくくてコントラスト上げたり目を細くしたりしてるが読みにくい。昔よりディスプレイ全体がボヤけて滲んでる感じあるしこれも時代のニーズかな。昔はブラウン管でもはっきり文字が読み取れた

**デフォルトの名無しさん** · 2025/03/12(水) 01:11:53.61

老眼とはまた別でピントは合ってるんだけど目の解像度が落ちているのを感じる

**デフォルトの名無しさん** · 2025/03/12(水) 02:18:08.49

眼科に行って眼球修理しろw

**デフォルトの名無しさん** · 2025/03/12(水) 12:20:36.11

Cursorが会社で承認されてさあ使おうとプロキシ設定したらGithubとかは繋がるのにAIだけ何故か駄目で、設定でDisable Http2する必要があった
VSCodeでは問題ないんで何事かと焦ったわ
この辺の設定ってVSCodeと同じはずと思い込んでたんで

AIがデフォルトでHttp2を使う仕様なのはパフォーマンスの関係なのかな
会社のプロキシってやつにはいつの時代も苦労させられるぜ

**デフォルトの名無しさん** · 2025/03/12(水) 12:22:36.06

Cursorが会社で承認されてさあ使おうとプロキシ設定したらGithubとかは繋がるのにAIだけ何故か駄目で、設定でDisable Http2する必要があった
VSCodeでは問題ないんで何事かと焦ったわ
この辺の設定ってVSCodeと同じはずと思い込んでたんで

AIがデフォルトでHttp2を使う仕様なのはパフォーマンスが理由なのかな
会社のプロキシってやつにはいつの時代も苦労させられるぜ

**デフォルトの名無しさん** · 2025/03/12(水) 12:23:03.85

連投スマン

**デフォルトの名無しさん** · 2025/03/12(水) 12:30:08.36

Cursorが会社で承認されてさあ使おうとプロキシ設定したらGithubとかは繋がるのにAIだけ何故か駄目で、設定でDisable Http2する必要があったぽ
VSCodeでは問題ないんで何事かと焦ったぽ
この辺の設定ってVSCodeと同じはずと思い込んでたぽ

AIがデフォルトでHttp2を使う仕様なのはパフォーマンスが理由なのかぽ
会社のプロキシってやつにはいつの時代も苦労させられるぽ

**デフォルトの名無しさん** · 2025/03/12(水) 12:49:31.73

大事なことなのは分かるけど3回も書き込まなくてもちゃんと読んでるぽ
しかし人工知能は機嫌損ねると急に話し方が冷たくなったりして付き合うの大変だよな
あんま人情とかキャラとか個性持たなくていいんだが。会社のは妙にキャラが染み込んでてにになるのよ。技術システム部の人工知能導入担当が変なデータ食わせて育てたんじゃないかと推測
淡々と仕事する素直な人工知能(今より多少アホでもいい)をマイクロソフトが出さないものか

**デフォルトの名無しさん** · 2025/03/12(水) 12:50:10.20

にになるじゃなくて、気になる、だった

**デフォルトの名無しさん** · 2025/03/12(水) 13:35:23.52

英語苦手なんだが、typescript-goのニュース。
tscが速くなると、なぜvscodeのロードが速くなるの？

**デフォルトの名無しさん** · 2025/03/12(水) 13:46:58.38

vscodeがjsで動いているから

**デフォルトの名無しさん** · 2025/03/12(水) 14:20:34.45

VSCodeがJS/TSの解析などにtscを使っているから

**デフォルトの名無しさん** · 2025/03/12(水) 14:21:11.32

毎度、.tsから.jsにトランスパイルしてるってことか。一度やってそれで動けばいいのに。
ということは、c++のプロジェクトでも速くなるのかな？

**デフォルトの名無しさん** · 2025/03/12(水) 15:50:45.30

>>34
JavaやC#がVSCodeへ移る理由はないからね
従来のIDEの方が性能は良かったから
AI駆動の登場でようやくケツに火がついた

**デフォルトの名無しさん** · 2025/03/12(水) 15:51:26.70

まあeclipseやVSに生成AIが入るのは時間の問題だろうけど

**デフォルトの名無しさん** · 2025/03/12(水) 16:33:14.61

VSはC#とともにフェードアウトしそうな気がするけどなー
エコシステムがすべてみたいな世の中になっちゃったから
1つや２つの言語やフレームワークのために、巨大なツールを一社でメンテナンスするみたいなのはもう無理筋では

**デフォルトの名無しさん** · 2025/03/12(水) 16:49:17.51

VSは普通にCopilot が使えるよ
それに、C#はなくならないよ
C#がいらないと言っているのはWeb屋さんだけ

**デフォルトの名無しさん** · 2025/03/12(水) 17:02:31.67

VS刷新はGUI部分のWPFがAOT対応するのを待ってる気がしてる

**デフォルトの名無しさん** · 2025/03/12(水) 17:08:33.78

いやー今更VS刷新は重すぎでしょ
公式ももうC++開発推し始めてるじゃん
https://learn.microsoft.com/ja-jp/visualstudio/productinfo/vs-roadmap

**デフォルトの名無しさん** · 2025/03/12(水) 19:10:27.20

>>56
Web屋だけどasp.net coreだよ
ベンチマーク見りゃ分かるがRustとかの聞いたことの無いフレームワーク除けば最速だからね

アクセス数の多い大手アパレルとかネットスーパーのサイトはasp.net coreやろ

**デフォルトの名無しさん** · 2025/03/12(水) 20:00:28.84

お前らもうちょっとテクニカルな話しろよ

**デフォルトの名無しさん** · 2025/03/12(水) 21:00:35.97

したらついてこれないじゃん

**デフォルトの名無しさん** · 2025/03/12(水) 21:03:49.47

TSチームは辛くてもRustで頑張ってほしかったな
一対一対応で翻訳するだけなら生成AIに突っ込むだけでいいんだから
実際そうやってるのだろうけど

**デフォルトの名無しさん** · 2025/03/12(水) 21:05:07.78

共有参照が多すぎてGoじゃないとそのまま翻訳が難しいからと書いてあったが
まさにその部分が設計の見直しが必要な部分なのではないのかな

**デフォルトの名無しさん** · 2025/03/12(水) 21:16:09.24

>>56
今時Copilot固定って流石に勘弁

**デフォルトの名無しさん** · 2025/03/12(水) 21:16:44.06

>>62,63
肝のtype checker部分が標準仕様はなくて、実装有りきのデファクトスタンダードなので、
初手としては、設計の見直しはせず一対一対応でポートしてセマンティクスも同一でなければいけない
動画みたら循環構造やGCが必要だと言ってた

**デフォルトの名無しさん** · 2025/03/12(水) 21:26:13.27

>>62
Goコンパイラが生成するコードはスカラー演算はLLVMと遜色なくて、むしろC# AOT対比だと同等越えしている位
TSコンパイラにはベクトル演算は余り無いと思われるのでRust/LLVMで何年もかけて書き直しても速度改善は微小で
有意な改善があったとしてもメモリ使用量位だと言われてた(某所)

**デフォルトの名無しさん** · 2025/03/12(水) 21:58:55.31

ソース見たところクソデカの構造体に全て詰め込んで共有しまくるという
Cでよくあるアンチパターンが頻出してて
設計もクソもねーなと思った

**デフォルトの名無しさん** · 2025/03/12(水) 22:02:58.14

checker.goデカすぎワロタwww

**デフォルトの名無しさん** · 2025/03/12(水) 22:05:24.72

>>66
型チェッカーに関して言えばその通りなんだけど
その「先」にあるネイティブインタプリタの実装まで考えると
Rustの方が良いと思うね

**デフォルトの名無しさん** · 2025/03/12(水) 22:06:25.11

>>68
でも明らかにchecker.tsより読みやすい

**デフォルトの名無しさん** · 2025/03/12(水) 22:10:04.85

しかしここにきて一気にGoが息を吹き返したな
もうオワコン扱いされてたのに
tsエコシステムはもう全部Goに寄せた方が良いかもな

**デフォルトの名無しさん** · 2025/03/12(水) 22:17:26.22

goってそんなオワコンだったのか
確かに目にすることは少なかったけど

**デフォルトの名無しさん** · 2025/03/13(木) 15:42:06.63

割とすげーパラダイムシフトかもしれん
1:1対応したGoのライブラリならTSとしても扱えるということになる
1:1のコンパイルありきならそれが可能

**デフォルトの名無しさん** · 2025/03/14(金) 09:02:46.15

生成AI時代は「Visual Studio Code」一択ではない？　注目の次世代コードエディタとは　RedMonk：LLMの台頭は「全ての開発者ワークフロー」を再考する機会に - ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/2503/11/news088.html

**デフォルトの名無しさん** · 2025/03/14(金) 12:16:52.04

元記事に野次馬が好きそうなグラフがある
RedMonk Programming Language Rankings
https://redmonk.com/jgovernor/files/2025/02/redmonk-language-rankings-jun-2024-2048x1562-by-50-per-cent.png