20/12/10 21:23:54.93 YXjbRyJb.net
今時サーバーサイドなんかJSON返すだけだろ。
何でもいいと思うが。
GoとかRustが速くていいんでない？
gRPCとか凝りだすなら知らん。
500:デフォルトの名無しさん
20/12/10 21:39:51.66 RJPTbGPf.net
サーバサイドは気がつくとschemeばっかり書いてる……。その辺がなんとかなるならGoとか書きます
501:デフォルトの名無しさん
20/12/10 21:48:43.95 S1lpljJp.net
>>492
作るシステムにもよるんだろけど
こちとらRDBから大量のデータとってごちゃごちゃ処理したり
百近くあるテーブルそれぞれのメンテナンスや照会をするわけですよ
フロントはリッチにしたい
サーバーサイドはかっちりやりたい
そして言語はフロントとサーバーで合わせたい…
502:デフォルトの名無しさん
20/12/10 22:04:23.50 A3Dq3Wf1.net
>>494
Denoですか？
503:デフォルトの名無しさん
20/12/10 22:18:31.69 TEgFYOMi.net
バックエンドはどうしても型安全、速度が求めらられる
もちろん速さのためにメンテナンス性、生産性を犠牲にもできない
C#はそのあたりのバランスが素晴らしいんだよな
504:デフォルトの名無しさん
20/12/10 22:32:00.98 ZI/7k9en.net
はいはい
505:デフォルトの名無しさん
20/12/10 23:00:49.22 YXjbRyJb.net
レス番飛んでるがC#、blazor、.NETあたりはNG放り込んどくと捗るぞ。
506:デフォルトの名無しさん
20/12/10 23:20:30.08 FjPnnhXu.net
都合の悪い事実から目をそらすなｗ
507:デフォルトの名無しさん
20/12/10 23:56:39.44 LnlNLdgj.net
スレタイから目を反らしてる荒らしが何か言ってらｗ
ムカつくから.netC#blazeraspスレまとめてうんこコピペ爆撃で埋め立て荒らしして仕返しするはｗｗｗｗｗｗ
508:デフォルトの名無しさん
20/12/11 01:26:46.25 ki/gtV8Z.net
酷いことしないでください！あんまりです！！
509:デフォルトの名無しさん
20/12/11 07:33:09.58 bazSVpRn.net
REST API 向けのフレームワークってお勧めある？
510:デフォルトの名無しさん
20/12/11 07:47:02.17 v5eQE/u2.net
フロントエンドやっててJavascriptが得意な人はサーバー側をJavascript系言語にしたい
バックエンドをやってたひとはフロント側を同じ言語にしたい（あえて具体的な言語は書かない）
そしてこの両者が相容れることはない！
絶対にだ！
511:デフォルトの名無しさん
20/12/11 08:39:35.36 XJ19VQ15.net
サーバー・クライアント共に同じ言語で書ければ楽なのは事実
ゆえにnode.jsとか流行ったけどでもやっぱりねぇ・・・
512:デフォルトの名無しさん
20/12/11 08:47:01.27 cqSkTkSV.net
言語一つしか遣えないというのは、
エンジニア的にいけてない。
view層と
model以下層とでは
使いやすい言語特性が異なると思う。
513:デフォルトの名無しさん
20/12/11 08:52:46.60 mgnhflNE.net
>>505
ならElmとか使ったほうがいいな
514:デフォルトの名無しさん
20/12/11 10:14:13.68 v5eQE/u2.net
>>505
いけてるいけてないの問題ではない
型の共有ができないほうがつらいだろう
HelloWorldだすだけならいいけどさ
515:デフォルトの名無しさん
20/12/11 11:48:07.83 cqSkTkSV.net
>>507
初心者さんかな
516:デフォルトの名無しさん
20/12/11 12:12:37.96 v5eQE/u2.net
>>508
この手の技術は初心者さん…
え、この考えっておかしい？
フロントでもサーバーでもTypescriptが使えると嬉しいですよね♪
とかブログやQiitaに書いてる連中はなんなの
みんな初心者なの？
517:デフォルトの名無しさん
20/12/11 12:12:39.58 6nQJWcQl.net
jsフロントしかやったことないと型の共有といってもピンとこないのかもしれない。
518:デフォルトの名無しさん
20/12/11 12:16:48.12 RI9UvvOD.net
>>502
Strapiおすすめ
519:デフォルトの名無しさん
20/12/11 12:35:47.16 7Npuzr8q.net
GraphQL使ってるから言語は違ってもいいかな
同じロジック使いたくなることはあるけど
520:デフォルトの名無しさん
20/12/11 12:55:05.83 cqSkTkSV.net
クライアントの接続先のほとんどはREST APIになっちゃったからね。
今の案件も接続先４ベンターとも全てREST API。
もちろん仕様書はOpen API準拠。
サーバーの開発とかそんな感覚はもう無くなってて、
ネットワーク上の複数のサービスに必要に応じて接続して要件こなす感じ。
521:デフォルトの名無しさん
20/12/11 12:57:29.67 bazSVpRn.net
>>511
ありがとう。
軽く調べてみたけどすごいリッチだな～。サクッとAPI作れるしGraphQLにもできるし
522:デフォルトの名無しさん
20/12/11 13:09:28.19 RI9UvvOD.net
>>514
リッチなのはもともとオープンソース版のcontentfulみたいなものを目指してたからかな。
しかしプラグインの拡張性がヤバイｗ
523:デフォルトの名無しさん
20/12/11 14:02:18.51 v5eQE/u2.net
>>513
サーバーサイドの開発の感覚がない
じゃなくて、きみがサーバーサイドを開発する機会がなかっただけなんじゃないの？
誰かがサーバーサイドの開発はしてるわけでしょ？
サーバーサイドもフロントサイドもバリバリこなしたうえで
型の共有なんて要らないと結論づけて
俺のこと初心者呼ばわりしてるんだと思ったら違うんかいな。
524:デフォルトの名無しさん
20/12/11 15:36:37.12 PpFv1GHN.net
スクリプト言語は規模がでかくなるとテストが遅くてたまったもんじゃない
525:デフォルトの名無しさん
20/12/11 16:35:03.58 /1hdqM5e.net
>>517
なるほど。
それが「ちゃんとしたプログラム」でスクリプト言語が使われにくい一つの理由か。
526:デフォルトの名無しさん
20/12/11 16:41:45.58 aaGWUZTk.net
はいはい
527:デフォルトの名無しさん
20/12/11 18:12:26.91 cqSkTkSV.net
自演ぽいな。
528:デフォルトの名無しさん
20/12/11 18:36:35.26 bazSVpRn.net
ぽいな。中間が欲しかったんだろう
529:デフォルトの名無しさん
20/12/11 18:50:56.14 WfwoqSO4.net
気に入らん意見はたとえ正しくても全部自演に見えるんだな
なんか哀れだな
530:デフォルトの名無しさん
20/12/11 18:55:08.47 /AL4j9WO.net
Ruby on Rails には、JSON を返す、API モードがある。
Postman でテストしてみましょうとか
GraphQL の動画もある
531:デフォルトの名無しさん
20/12/11 20:12:49.38 i7+Pb2PU.net
rubyやめてくだちゃい
532:デフォルトの名無しさん
20/12/11 20:27:11.97 RI9UvvOD.net
ろうそくに火を着けるのに戦車でホウゲキスルみたいな話ｗ
533:デフォルトの名無しさん
20/12/11 21:09:51.08 v5eQE/u2.net
>>525
ここにいる人たちはローソクに火をつける程度のことしかしてないとでも？
534:デフォルトの名無しさん
20/12/11 21:23:48.76 x5sg/wBh.net
JSONを返すAPIの話でしょ？ｗ
ローソクに火を着ける程度の話じゃんｗ
Pythonで言うならfastapi一発で片が付く程度の要件ｗ
535:デフォルトの名無しさん
20/12/11 21:37:12.39 /OH0bKMN.net
>>527
あ、そゆことか
失礼しました
536:デフォルトの名無しさん
20/12/12 15:41:12.04 tFV4re81.net
>>515
Auth周りも充実してるやん！
マジでリッチだなStrapi
537:デフォルトの名無しさん
20/12/13 02:21:52.47 1g8P/X2h.net
svel teでRSSリーダー作れましゅか？
538:デフォルトの名無しさん
20/12/13 09:17:06.39 guPhKJv6.net
お前には無理
539:デフォルトの名無しさん
20/12/13 18:56:38.39 aSLwtxd2.net
しどい人
540:デフォルトの名無しさん
20/12/13 20:28:38.03 B13w25Nu.net
RSSってCORSが面倒くさそうだ。
まず鯖側のロジック組んだら？
541:デフォルトの名無しさん
20/12/14 04:36:40.26 IikJWIXJ.net
ネイティブからVueに来たけど、React始める理由が見つからないのだよなぁ。やる気になる理由教えてほしい。
542:デフォルトの名無しさん
20/12/14 04:47:12.29 c/6hsi1I.net
なんか無理やり問題作り出してるね。
そんな人生歩んできたの？
Vueやってりゃいいじゃん。
目移りしてないで添い遂げなよ。
543:デフォルトの名無しさん
20/12/14 06:52:16.19 bO8KTObj.net
>>534
海外でフロントの基盤になりつつあるから、覚えてると次の技術に手を出しやすい、と思う。
あと、設計が洗練されてるから、勉強してて面白い。
そんなに気合入れなくても1,2週間くらいでわりと使えるようになるよ
544:デフォルトの名無しさん
20/12/14 10:24:11.07 KZ2ZzyjW.net
逆じゃね？徐々にnative離れしていってるだろ今
545:デフォルトの名無しさん
20/12/14 10:25:18.35 uneXzzPO.net
>>534
おれも両方やってるよ。
546:デフォルトの名無しさん
20/12/14 11:19:24.77 5GWU8eb2.net
要件次第
どっちも必要
547:デフォルトの名無しさん
20/12/14 11:27:15.61 1knwibYG.net
Vueってアプリ向けサイト向けのどっち付かずな位置付けだよな
548:デフォルトの名無しさん
20/12/14 14:49:45.13 uneXzzPO.net
VueやってReactもやったら
Reactの方がシンプルで簡単に感じた。
両方Typescriptで。
VueはTypescriptで苦労多かったけど、
Reactは何もトラブらなかったのは感動した。
Vueも今は
549:違うのかな？
550:デフォルトの名無しさん
20/12/14 15:49:59.66 c/6hsi1I.net
Vueはどんどんややこしくなってる
551:デフォルトの名無しさん
20/12/14 20:20:16.66 zTIoKfkk.net
じゃあSvelteでいいじゃん
552:デフォルトの名無しさん
20/12/14 20:25:40.72 c/6hsi1I.net
誰が悪いと言った
被害妄想か？
使えばいいだろ好きに
553:デフォルトの名無しさん
20/12/15 15:03:48.47 kY8gykeX.net
ありがとうございます。
エンジニアがメンテする方は時間みつけてReact版も作ってみようかな。Reactがいいって言う人もいるものね。
オペレータがメンテするほうはまだVueかなぁ。JS/TS入れると途端に手を出さなくなるっぽいから。
554:デフォルトの名無しさん
20/12/15 16:16:26.12 CQsY05jd.net
じゃあVurも手を出せないだろｗｗｗ
555:デフォルトの名無しさん
20/12/15 21:41:45.32 nhpRosQZ.net
VueからSvelteってのはわりとアリだと思うけどReactからSvelteはないんじゃないかな？なんとなく
556:デフォルトの名無しさん
20/12/17 15:08:18.56 S5hO0K8u.net
どんなに素晴らしいSPAフレームワーク使ってもお前らが作るゴミのようにダサい画面はどうにかならんの？
557:デフォルトの名無しさん
20/12/17 15:36:01.14 5gjmPPN4.net
548の顔よりマシだから我慢してる
558:デフォルトの名無しさん
20/12/17 19:02:27.94 KmOwmnZ/.net
モダンなデザインライブラリ使えば、よほど滅茶苦茶やらん限りデザインマシにならない？
559:デフォルトの名無しさん
20/12/17 23:26:55.34 S5hO0K8u.net
ならない
なぜなら生まれつき目ん玉腐ってるからどうやっても無理
560:デフォルトの名無しさん
20/12/18 12:49:47.76 7/WdPtmz.net
えっかわいそう
561:デフォルトの名無しさん
20/12/20 11:32:43.24 iHv9q4Jc.net
>>232
なるほど、言葉が足りなさすぎて四方八方とケンカするタイプだな
562:デフォルトの名無しさん
20/12/20 11:41:10.74 iHv9q4Jc.net
>>545
React以外生き残れないのでは？と思うわ
そのReactも10年先は闇
563:デフォルトの名無しさん
20/12/20 14:04:00.68 UVkg8Nt7.net
>>554
Blazorはマイクロソフトが面倒みるだろう
切り捨てるにしても今のマイクロソフトなら移行先はしっかり示してくれはず
564:デフォルトの名無しさん
20/12/20 14:40:27.53 UNBfVBp2.net
>>554
ネイティブDOMが流行ってたjQueryの機能の一部を取り込んだように、Reactの一部がネイティブDOMに取り込まれる時も来るのかな
565:デフォルトの名無しさん
20/12/20 14:44:58.50 wyinNDK0.net
それは無いな
566:デフォルトの名無しさん
20/12/20 15:32:40.50 NMs4Sv5l.net
Reactの一部というか仮想DOM相当が実装されて
直接DOM操作をしても速いってことにはなりそう
そうなるとReactを使うメリットが無くなるかな
jQueryの方がいいや
567:デフォルトの名無しさん
20/12/20 15:50:36.24 eC7CUhM2.net
仮想DOMはともかく、可及的速やかにTypeScriptをネイティブサポートして欲しい
568:デフォルトの名無しさん
20/12/20 18:57:12.56 1LcS4Wc6.net
意味不明。コンパイル時に型チェックして用が済んだ型情報捨てたらJSになるだろ。
ネイティブサポートとやらで何が出来るようになると勘違いしてんの？
569:デフォルトの名無しさん
20/12/20 18:59:17.57 4dBK3uKK.net
ネイティブサポートっていうのはすべてのブラウザで
TypeScriptをそのまま実行できるように
標準化してくれって意味だろ？
570:デフォルトの名無しさん
20/12/20 19:27:04.30 1LcS4Wc6.net
えっ…型チェックはいつやるの？
実行時にやったら意味ないじゃんｗｗ
571:デフォルトの名無しさん
20/12/20 19:32:36.87 4dBK3uKK.net
意味有るだろ
572:デフォルトの名無しさん
20/12/20 19:35:04.40 qlKs1YcD.net
>>560
頭わるいのかセンスないんだか...
573:デフォルトの名無しさん
20/12/20 19:35:27.83 gM7i2qLz.net
意味ないな
重くなるだけ
574:デフォルトの名無しさん
20/12/20 19:38:49.70 UNBfVBp2.net
tscの遅さからして、ジェネリクスとか型推論する事はコンパイルの遅さに繋がるから、ブラウザに乗ることは無いと思うな……
575:デフォルトの名無しさん
20/12/20 20:08:43.08 oCpDvsa6.net
>>566
静的言語として実装すればマシになりそう
576:デフォルトの名無しさん
20/12/20 20:34:21.19 A6h0ajNd.net
今ビルド時に行っていることを実行時にクライアント側で行わせるんだったら何のメリットもないな。
577:デフォルトの名無しさん
20/12/20 21:13:21.78 r+W+aFS5.net
>>560
ブラウザがって事じゃね？
578:デフォルトの名無しさん
20/12/20 21:15:24.60 UNBfVBp2.net
>>567
よくわからないな。そりゃCみたいにすればコンパイル速くなるけど
579:デフォルトの名無しさん
20/12/20 21:31:01.24 r+W+aFS5.net
>>570
それだと型推論なしの別言語が必要になる
580:デフォルトの名無しさん
20/12/20 21:40:56.78 UNBfVBp2.net
>>571
だよねぇ……
581:デフォルトの名無しさん
20/12/20 21:48:23.26 r+W+aFS5.net
てかWebpackでまとめてやってるけどtsだけの賞味の処理時間ってどんなもんなのかね？
582:デフォルトの名無しさん
20/12/20 21:55:07.85 eC7CUhM2.net
処理速度がどうこうというより、TSのコンパイル要らなくなればエコシステムの複雑さが多少緩和されて嬉しいというのが>>559の意図だった
583:デフォルトの名無しさん
20/12/20 22:04:21.56 gM7i2qLz.net
余計に複雑になるよ
584:デフォルトの名無しさん
20/12/20 22:35:46.90 ACHo5cdv.net
ブラウザ毎のTS対応の差異を吸収するために結局トランスパイルが必要になるというオチ
585:デフォルトの名無しさん
20/12/20 23:07:19.36 A6h0ajNd.net
ビルド時に静的にチェックできるのが嬉しいのにそれを実行時に持っていったら本末転倒
586:デフォルトの名無しさん
20/12/20 23:18:46.13 1l9Yd4/w.net
>>577
これだよなぁ
これわかってない奴がいそうなあたりフロント屋の限界を見た感じ
587:デフォルトの名無しさん
20/12/21 01:12:04.98 tdMG9IX+.net
動的型付け言語しか経験のない人が静型付け言語をtsで初めて触ったんだろうな。
インタプリタで静的型付け言語を動かしたい意味が分からない。
588:デフォルトの名無しさん
20/12/21 01:16:51.27 K4qAWeZh.net
やっぱC言語から教育せんとあかんな
589:デフォルトの名無しさん
20/12/21 02:24:29.25 p+huYkVo.net
実行速度がすべてじゃない
開発速度が上がる
実行速度が悪いのかと思ったら意外に良い
590:デフォルトの名無しさん
20/12/21 06:59:17.90 VinlekCu.net
>>578
それはいくらなんでもフロント屋を舐め過ぎ。単に経験不足なだけでしょ。
591:デフォルトの名無しさん
20/12/21 07:15:17.07 pPRPNU2Y.net
VSCodeとか使ってるとコンパイルする前に割とチェックしてくれるから
これならコンパイルいらないんじゃね？と感じたんじゃない？
592:デフォルトの名無しさん
20/12/22 00:43:04.59 eYYUdz4g.net
コンパイル済みの静的な言語の方が実行時も速くなるのでは？
593:デフォルトの名無しさん
20/12/22 01:23:33.30 7N4VeP0i.net
>>584
それはコンパイル時間が全体のどれだけを占めるかによる
殆どのサイトではソースコードの量なんてたかだか数MB程度なんや
そんなもん一瞬で終わるだろ？
594:デフォルトの名無しさん
20/12/22 05:37:59.16 10xc+AYD.net
>>585
？？？？？？？？？？？？？？
595:デフォルトの名無しさん
20/12/22 05:41:09.35 hQt91lH6.net
>>584
コンパイルするとファイルデカくなるからネットサーフィンに向かなくなるけどな
596:デフォルトの名無しさん
20/12/22 06:58:59.75 SSKDFZLr.net
結局はJS(TS)と一部Wasmの組み合わせがWebではベストでベターって事かな。ECMAとかの連中はホントよく考えてんな
597:デフォルトの名無しさん
20/12/22 17:03:10.07 zFMmoCN0.net
そういう面倒な事は全部フレームワークが吸収するのが今のweb開発環境だろう
下手に深入りせず感謝だけしてればいいさ
598:デフォルトの名無しさん
20/12/22 17:53:00.23 N3mlVNrO.net
blitz 使ってる人いる？
599:
20/12/22 21:41:17.94 reQ7ztpU.net
nuxtでPWAするって筋良い？
600:デフォルトの名無しさん
20/12/22 23:29:06.60 9S12l4Ic.net
SSRが必要な要件のサイトにフレームワーク使うかのが本当に正しいか？っていう命題
601:デフォルトの名無しさん
20/12/24 22:43:51.30 yxJlqEyC.net
最近フロンエンドの若手がnext.jsやnuxt.js使って俺たちサーバーサイドもいけるっしょ？感出しててきつい
サーバーサイドのこと何も理解して無さすぎる
お前らはrustもかけないしサーバーサイドも理解してない
フレームワーク以前にやることがあるだろう
602:デフォルトの名無しさん
20/12/24 23:09:50.47 ShlinYwD.net
シニアなサーバサイド屋がこんなとこに出張して来てグチってるのも大概キツいと思います
603:デフォルトの名無しさん
20/12/24 23:17:05.88 cDdTcWWQ.net
俺は最新技術おっかけてるイケてる若手だぜオーラ出してる後輩が簡単なアルゴリズムとデータ構造も知らなかったのには驚いた
結局のところ便利な開発ツールを使うだけのユーザーなんだよなああいう連中って
ツールを作るエンジニア側にはなかなか回れない
ハリボテの実力をアピールするのに必死だから基礎がなってない
604:デフォルトの名無しさん
20/12/25 00:44:33.03 lUAVm7Fr.net
スレタイ読めない基地外発見！
605:デフォルトの名無しさん
20/12/25 00:48:45.38 gC1vp0cV.net
とりあえずフロントエンドの思想をサーバーサイドに持ち込まないで欲しい
ただでさえこちらは複雑なのにサーバーサイドコンポーネントとか多少のパフォーマンスアップのために余計な世話を任せるのをやめて欲しいね
静的サイトジェネレーターとして利用するのは大歓迎です
606:デフォルトの名無しさん
20/12/25 01:39:52.86 qAP5BtZu.net
どうしたんだ
若者に対して危機感でも覚えたか
607:デフォルトの名無しさん
20/12/25 06:35:39.67 Iaqdi9AP.net
おじさん良かったね。SSG流行ってるから静的ファイルとJsonだけ吐いてれば良いよ。そのうちグチを履く場所も無くなるよ
608:デフォルトの名無しさん
20/12/25 09:23:34.07 JfQSa+1c.net
>>598
危機感はある
日本のIT業界の未来的な意味で
609:デフォルトの名無しさん
20/12/25 09:59:12.68 A1/o8gvx.net
>>600
君の狭い社会だけで決めつけるのは早計じゃないか？
日本中の若手エンジニア接したわけでもないのになぜ危機感を覚えられる？
610:デフォルトの名無しさん
20/12/25 10:02:57.01 y7Pao4Yd.net
そもそも若手だろ？
若手ごときにムキになるなって。
そりゃ20年も30年も経験が長い分、お前のほうが実力も知識もあるって。比べるまでもねえよ。
もっと自信もちなよ。
611:デフォルトの名無しさん
20/12/25 10:26:48.34 eQ1FygGo.net
ssrの機能としてはゴミレベルやな
612:デフォルトの名無しさん
20/12/25 12:00:49.20 JfQSa+1c.net
>>601
他社の若手とも交流があるし今はネットで見知らぬ他人とも話せる時代だ
613:デフォルトの名無しさん
20/12/25 12:36:02.99 lNkC3baX.net
ベテランがいちゃもん付けて若者の生産性を落とす事のほうがよっぽど日本の将来に害を成すかもよ？
614:デフォルトの名無しさん
20/12/25 12:48:43.86 9gJIelYH.net
今の若者って器が小さいけど派手に盛り付けるのが得意だから一見すると若いうちから凄い優秀な人材に見える
でも器が小さいから盛れる量が頭打ちになるのも早い
そうじゃなくて若いうちに地味な研鑽を積んで器を大きくしてほしいんだよね
器が大きければ盛るのに時間はかかってもそのうち器小さい奴を追い越せる
器ってのは基礎訓練で身につくもの
スクールに通って効率よく教わってキラキラした便利なサービスやツールを使えば盛るだけなら誰でも盛れる
でそれじゃ肝心の器がなかなか大きくならない
615:デフォルトの名無しさん
20/12/25 12:54:08.56 A1/o8gvx.net
>>605
彼は現実ではいちゃもんつけてないぞ。多分。
616:デフォルトの名無しさん
20/12/25 12:59:47.26 lNkC3baX.net
>>606
スクール上がりが糞なのはまぁ……その……確かに。
キラキラツール系は嗅覚が良いなって素直に認める。
ITが好きで自己研鑽できるタイプじゃないと、結局は自分から脱落してくでしょ。
>>607
そういう感じはするなw
617:デフォルトの名無しさん
20/12/25 13:04:26.32 uurLZNKt.net
若手を育てられなくなったら組織として終わりだよ
618:デフォルトの名無しさん
20/12/25 15:39:40.13 gC1vp0cV.net
>>599
SSRよりSSGが流行ってる理由分かってないみたいだね
619:デフォルトの名無しさん
20/12/25 15:59:47.26 euOV1ViA.net
SPA
SSR
SSG
ISR
SPA以外正直よく分かってない
620:デフォルトの名無しさん
20/12/25 16:03:02.39 cyV6b5qO.net
ISRだけ分からん
ちなみにDSLRとは「Digital Single Lens Reflex camera」の略で『デジタル一眼レフカメラ』の事
621:デフォルトの名無しさん
20/12/25 19:27:00.55 rgYdT80J.net
>>610
お、説明してくれるの？
622:デフォルトの名無しさん
20/12/25 20:59:57.79 gC1vp0cV.net
>>613
分かってないならいいよ
自分で調べろ
623:デフォルトの名無しさん
20/12/26 07:14:40.66 7X2rKI4N.net
スーパースーパーレアってアホっぽい
624:デフォルトの名無しさん
20/12/26 08:10:53.16 IHOdi7Vn.net
今はISRだよな
625:デフォルトの名無しさん
20/12/26 10:20:49.20 q2RopqqH.net
Incremental Static Regeneration だってさ。
SSRとSSGの合わせ技か。
SSGのデメリット消すためとはいえSSRの何分の一かのサーバリソースは必要になる、と。
626:デフォルトの名無しさん
20/12/26 10:58:25.99 nir8tHzM.net
相変わらずこの分野は迷走してんなぁ
もうそろそろMVC回帰のトレンドがくるよ
クラウドからオンプレに回帰
ミクロサービスがモノリスに回帰
トレンドってだいたい一周回って帰ってくるんだ
627:デフォルトの名無しさん
20/12/26 11:45:42.03 T66JFeJq.net
技術の進歩は螺旋である
あとjavascript系技術ってフロントがjavascriptでしか動かないから仕方なしにjavascriptでやってるんであって
そうでなければ選ぶような技術ではないと思う…
628:デフォルトの名無しさん
20/12/26 12:23:11.06 3y5CuLti.net
仕方ないと思うかどうかは人それぞれだな。俺は言語としてjs/tsが好きだけど。
個人的にはpythonの方が「仕方なく使ってる感」が強い。
629:デフォルトの名無しさん
20/12/26 12:41:09.33 UNoc468U.net
JSはVBAのようなもので、お金を頂いて開発するようなかっちりした製
630:品には向いていないんじゃないですかね。
631:デフォルトの名無しさん
20/12/26 12:50:41.74 UDiPG0nr.net
>>621
vbaとてもわかる…
jsみてるとvbaを思い出す…
チームでやりだすと途端に破綻する
しかしTypeScriptは素晴らしい。
みんな大好きマイ⭐︎クロソフトでした。
632:デフォルトの名無しさん
20/12/26 12:54:31.14 GU4nNxSM.net
マイクロソフトというかヘジたんが天才だった
633:デフォルトの名無しさん
20/12/26 13:03:44.34 BjZvExSE.net
かっちりしたとか、チーム開発となればTS(strict)の出現は大きな進化だった。
Pythonの型ヒントと違って、各種ライブラリにしっかり型があってstrictが現実的に使える
634:デフォルトの名無しさん
20/12/26 13:24:08.93 IF3PEEZe.net
C#を使える層はVBAを使える層を含んでいるが、名前にCが付いているから
C使いの一員になったと勘違いした挙句、C++を好んで使っている人をC#を
使えない老人呼ばわりするのがウザイ。
C#なんてC使えるやつなら誰でも使えるわ。
635:デフォルトの名無しさん
20/12/26 13:30:03.47 nir8tHzM.net
意外と使えん奴もいるから人それぞれ
Cなんて初心者の入門用言語だし
636:デフォルトの名無しさん
20/12/26 13:43:46.26 npenhvb8.net
C#はいい言語だよ。
C#使いもまともな人多いよ。
でもここにやってくるC#おじさんは使えない老害だよ
>>625
VB.NETとVBAをごっちゃにするのはちょっと……
637:デフォルトの名無しさん
20/12/26 13:45:40.20 T66JFeJq.net
C#使える層も大概おっさん扱いされてますが…
TypeScriptはよくできてると思うが、流石にサーバーで動かすのはやりすぎだった。
お手軽システム限定。
638:デフォルトの名無しさん
20/12/26 14:07:06.73 3y5CuLti.net
やりすぎって何が？
639:デフォルトの名無しさん
20/12/26 14:17:50.65 aXYrsBzh.net
無駄な処理をやりすぎて遅い
640:デフォルトの名無しさん
20/12/26 14:27:39.58 3y5CuLti.net
スクリプト言語でサーバーやるの全般がダメって言いたいのかな
641:デフォルトの名無しさん
20/12/26 14:38:05.10 YlcJBbhr.net
まあそういうことだね
642:デフォルトの名無しさん
20/12/26 14:41:07.66 UNoc468U.net
だれかKENTAさんからコメント取ってきてよ。
643:デフォルトの名無しさん
20/12/26 14:48:49.60 lsTpcoKT.net
DBを利用したRESTサーバでJSがボトルネックになる状況とかよほど酷いロジックでは？
644:デフォルトの名無しさん
20/12/26 14:53:04.50 nir8tHzM.net
DBとAPIがほぼ直のチュートリアルみたいなステムならNodeでもRubyでも何でもいいよ
業務でそんなシステムはなかなか珍しいけど
645:デフォルトの名無しさん
20/12/26 14:54:17.66 3y5CuLti.net
たぶん、ちゃんと測定したわけでもなくふわっとした印象で語っているだけだろう
646:デフォルトの名無しさん
20/12/26 14:58:20.42 Ii8YlEBO.net
ほんとゴミ情報だね。
647:デフォルトの名無しさん
20/12/26 15:02:00.45 bKK4ULgi.net
アクセス量多いとスクリプトはちょっとね
648:デフォルトの名無しさん
20/12/26 15:06:50.42 rNbO8nf2.net
スクリプトっていうか、動的型付け言語をサーバーサイドで使いたくない気持ちは分かる。
でも速度面を理由にするのは、よく分からない。
例えば負荷テストの結果が良くない等、具体的数字に基づいて言ってるのかな？
649:デフォルトの名無しさん
20/12/26 15:11:27.64 nir8tHzM.net
>>639
ベンチマークで遅いことはわかってるから候補から外れる
作ってからなんか遅かったですじゃ手遅れだからね
650:デフォルトの名無しさん
20/12/26 15:20:49.69 OUJQ/yeA.net
つまり、測定して無いんだ
651:デフォルトの名無しさん
20/12/26 15:42:31.72 IF3PEEZe.net
RubyやJSは起動が速いが、JavaやC#はどうなの?
クラスローダーやDLLのロードのためか、起動が遅い印象がある。
652:デフォルトの名無しさん
20/12/26 16:06:58.20 nir8tHzM.net
>>641
ベンチマークの意味わからない？
653:デフォルトの名無しさん
20/12/26 16:07:14.19 rNbO8nf2.net
>>642
サーバーの起動なんてリリースやメンテナンスのタイミングしか無いけど気になるか？
654:デフォルトの名無しさん
20/12/26 16:07:31.63 nir8tHzM.net
>>642
比較的遅いがバックエンドなら気にすることじゃない
655:デフォルトの名無しさん
20/12/26 16:17:10.36 IF3PEEZe.net
>>644
もしかして、起動したら基本的に終了せずに、イベントが発生するまで
待機してイベントを裁くような方法を使うの？
656:デフォルトの名無しさん
20/12/26 16:18:27.99 S13r8MyR.net
突然空気読まずにMVCとか言い出したと思ったらやっぱりC#おじさんか……。
スレ違いの話はやめようね
657:
20/12/26 16:26:29.04 IHOdi7Vn.net
rubyが早いとか何言ってんだろw
なぜtwitterがscalaで書き直したか知らないの？
658:デフォルトの名無しさん
20/12/26 16:32:44.71 3y5CuLti.net
>>640
性能要求を満たすかどうかは案件ごとに違うだろうに。
スクリプトだから、ベンチマークが遅いから、って一律で切るのはそもそもそういう検討をしていないんだろうね。
659:デフォルトの名無しさん
20/12/26 16:38:00.25 A5wLytvy.net
ベンチマークで遅いのと、実用になるかならんのかは全然別だと思うが。
コンビニに行くのにフルチューンのF1では行きたくないだろ。
660:デフォルトの名無しさん
20/12/26 16:39:34.59 T66JFeJq.net
スクリプト言語でサーバーサイドやる利点を是非知りたい。
パフォーマンス？生産性？流行りだから？
661:デフォルトの名無しさん
20/12/26 16:42:16.12 T66JFeJq.net
>>650
に書かれてた。やはりお手軽システム限定ってことか。
662:デフォルトの名無しさん
20/12/26 16:42:59.57 IF3PEEZe.net
>>651
ネット黎明期のころ、CGIはPerlで書かれたものが多かった。
Perlは文字列とASCIIコードの相互変換が混乱し易く、かつ、
関数呼び出しの参照渡しに問題が有ったのでRubyに置き換わった。
PerlとRubyは言語が違うだけでどちらもスクリプト言語で似た動作原理
を持っていたので移行しやすかった。
その後、SunがJavaをサーバーサイドを主目的として作った、と聞いた。
663:デフォルトの名無しさん
20/12/26 16:49:24.27 5ukh9MxR.net
>>651
雑に言うと
JavaでサーバーサイドやったらJVMの起動に時間がかかってパフォーマンス悪すぎ
TypeScriptでサーバーサイドやったらイベントループのおかげでパフォーマンス良すぎ。Javaのように書けて移行もしやすい
っていう記事を読んだ
664:デフォルトの名無しさん
20/12/26 16:50:07.93 A5wLytvy.net
>>652
お手軽システムと言うが、お手軽の定義が10年前とは違うぞ。
今の「お手軽ではない」って用途は、現代のCPUですらC++でゴリッゴリにチューンしたロジックをぶんまわさないと走らないと実用にならんシステムであって、ほとんどの物はここに入らん。
少なくとも、JITで瞬時にコンパイルされてる時点で過去のインタプリタ言語とは相当違う。
今の軽自動車であれば日本一周ぐらい余裕みたいな議論になる。
665:デフォルトの名無しさん
20/12/26 16:52:32.05 3y5CuLti.net
開発言語を選択する理由なんて様々だと思うが、逆に、サーバーに限定して
スクリプトとそれ以外に線を引いてスクリプトは向いてないと主張する理由が知りたい。
666:デフォルトの名無しさん
20/12/26 17:01:13.91 5ukh9MxR.net
日本人がGoでサーバーサイドやるという記事を読んだ
TypeScriptでやるというのは外人の記事
GoとTypeScriptのどっちがいいかの評価記事を読みたい
667:デフォルトの名無しさん
20/12/26 17:02:13.15 BjZvExSE.net
起動速度が重要になる場面はあるよね。Lambdaとかご存知無さそうだけど
668:デフォルトの名無しさん
20/12/26 17:08:32.45 A5wLytvy.net
>>657
物によるけど、俺はGoの方が好き。
デプロイが圧倒的に楽だから。
669:デフォルトの名無しさん
20/12/26 17:09:33.00 nir8tHzM.net
>>649
うーんいや
スクリプトにして生産性がぐんと上がるんならパフォーマンスをしっかり検討して許容範囲に収まるなら使ってみようって流れになる可能性はある
でもスクリプトにして生産性がそんなに上がるかっていうと上がらないし下手すると下がるからね
メリットないのにベンチマークで遅いとわかってる言語を選ぶ理由はないでしょう
670:デフォルトの名無しさん
20/12/26 17:16:03.34 nir8tHzM.net
>>650
それはF1カーの運用までが大変だからだろ
比喩表現としてまったく不適切だよ
C#はスクリプトに比べてパフォーマンス以外も楽だからね
楽で速いのだから答えは決まりだ
671:デフォルトの名無しさん
20/12/26 17:25:22.32 3y5CuLti.net
>>660
だから、言語を選ぶ条件なんて様々だろうに。言語自体の機能、開発しやすさ、環境、あるいは開発者を
集めやすいとか過去の資産の継承とか。
それらを踏まえたうえで要求を満たせる言語ならスクリプトとかそうじゃないとかこだわる必要はないと思うが。
>メリットないのにベンチマークで遅いとわかってる言語を選ぶ理由はないでしょう
そこでベンチマークという指標だけを特別視する理由があるのかということと、そもそもそのベンチマークの
成績がどれだけあればいいのかとか、そういう基準をもって選択しているのかと。
672:デフォルトの名無しさん
20/12/26 17:25:26.09 Y46mRX42.net
C#はJSの2倍程度しか早くないですよ。
Cなら一桁違う事もあるけど
673:デフォルトの名無しさん
20/12/26 17:26:02.76 nir8tHzM.net
>>654
JavaはポストCOBOLのポジションだからもう生産性やパフォーマンスを期待してはいけない
ちなみにC#は非同期処理が得意な言語の筆頭だよ
非同期処理を実用レベルの高生産性まで最初にもっていった言語はC#
JSやその他の言語がイベントドリブンのコールバック連鎖で気持ち悪い非同期処理をシコシコ書いてた時代にC#では真っ先にReactiveExtensionやAsync/Awaitを実装した
C#はライブラリの非同期対応も最も充実している言語の1つだ
JSやその他の言語では未だに非同期ライブラリがコールバックしかサポートしていないといったことも珍しくない
674:デフォルトの名無しさん
20/12/26 17:28:35.04 nir8tHzM.net
>>662
言ってることは間違ってないけどどの要素をとってもC#が最強なのでな
675:デフォルトの名無しさん
20/12/26 17:37:12.79 3y5CuLti.net
最初から「俺はC#が好きだ」って言ってればそこで終わってた話。
足りない頭でもっともらしい理屈をつけようとするからおかしなな話になる。
676:デフォルトの名無しさん
20/12/26 17:37:18.38 A5wLytvy.net
>>661
C#とJavaを引き合いに出したいのなら、ハマーぐらいかな。
確かに頑丈だしそれなりに走るけど、それが要るかと聞かれれば疑問符。
俺もC#はよく使うが、楽さは全然違うぞ。
Goとかと比べると、遥かにC#はめんどくさいし、そもそもC#は.net coreでAOTかけてても起動遅い。
677:デフォルトの名無しさん
20/12/26 17:40:22.14 abA8NdUG.net
>>667
Goも楽で速いがC#とは方向性が違うので共存できる
678:デフォルトの名無しさん
20/12/26 17:42:22.62 nir8tHzM.net
いずれにせよバックエンドでスクリプトを使うメリットは
ない
679:デフォルトの名無しさん
20/12/26 17:45:37.56 UNoc468U.net
ジャッジが居ないから結論が出ないんだよね。
・>>1が進行役のMCやる。
・MCがジャッジを三名指名する。
・棄権も許容して、ドローになる場合クラウドにゆだねる。
・MCは、クルーが大技を繰り出してきたとき、Yeah! や WoW! HoHo! など適切に合の手を入れる。
・7 to smoke ルールで、7勝した奴が勝ち。
680:デフォルトの名無しさん
20/12/26 17:49:44.17 vt3FfngW.net
おまえらphpもスクリプトだってこと忘れて議論してるな
メリットなかったら普及しないだろ
681:デフォルトの名無しさん
20/12/26 17:50:33.74 BjZvExSE.net
C#おじさんは狭い知識から屁理屈捏ねて勝利宣言繰り返すだけの人だから。お手本通りの老害
682:デフォルトの名無しさん
20/12/26 18:11:05.74 nir8tHzM.net
>>671
当時は高級言語の選択肢が少なかっただけだ
683:デフォルトの名無しさん
20/12/26 18:14:32.55 UNoc468U.net
Windowsで使えた、レンタルサーバで使えた。
需要にこたえていた。
我わ正義なり我に従えってRubyより流行ったのは当たり前だった。
684:デフォルトの名無しさん
20/12/26 18:22:33.03 A5wLytvy.net
>>669
使いこなせません、と言うことだな。
それはC#が好きなんではなくて、C#しかできないんだろ。
C#に謝れ。
685:デフォルトの名無しさん
20/12/26 18:30:08.64 bYNEuO+K.net
C#おじさん邪魔だからBlazorでも使ってろよ
686:デフォルトの名無しさん
20/12/26 18:35:47.28 T66JFeJq.net
Blazorスレと似たような展開だが、あっちはスクリプト系クソ
こっちはC#,Javaクソ
理由はどちらもパフォーマンスや生産性が～
これはもう宗教だな
687:デフォルトの名無しさん
20/12/26 18:41:30.60 abA8NdUG.net
>>675
使うメリットがないと言ってる
日本語わかる？
688:デフォルトの名無しさん
20/12/26 18:45:16.11 UNoc468U.net
Javaはライブラリの勝利じゃないだろか。
企業で使う場合、認証が一番厄介な部分だと思うけど、Javaはそこがしっかりしてた。
GlassFishを試用してみたけど、軽くは無かったな。
689:デフォルトの名無しさん
20/12/26 18:47:15.38 Xky1/n2X.net
C#は別にクソじゃないよ。一人で狂信者やってるC#おじさんがクソなだけ。
使ってる用語や説明の仕方に癖があるからわかりやすい
690:デフォルトの名無しさん
20/12/26 18:49:31.55 T66JFeJq.net
>>680
癖があってわかりやすいんですか！
691:デフォルトの名無しさん
20/12/26 18:53:53.93 A5wLytvy.net
>>678
メリットを知らない、と言うことだなって言ってるの。
逆に言えばC#のメリットも、本当に両方で作った上でメリットを感じた事があるかどうかすら怪しいもんだ。
知らない物は、無いに等しいわなって単純な話で、おっさんが哀れなだけだよ。
だからC#に謝れって言ってるんだが。
日本語わかる？
俺もC#好きで、それこそFW2.0の時に「良くも切り捨てやがったな…」とか恨んだレベルで年季入ってるけど、他の言語のメリットもちゃんとプロダクト出すレベルで使って判断できるつもりだぞ。
692:デフォルトの名無しさん
20/12/26 18:55:06.83 rNbO8nf2.net
>>646
そうだよ
693:デフォルトの名無しさん
20/12/26 18:56:22.81 abA8NdUG.net
>>682
メリットがないといってんだ
無いもんを知ってるわけ無いだろ
ないんだから
694:デフォルトの名無しさん
20/12/26 18:57:06.62 A5wLytvy.net
>>684
可哀想な人だな。
C#のデメリット言ってみ。
無いと言うならもう言う事は無い。
695:デフォルトの名無しさん
20/12/26 19:08:20.63 UNoc468U.net
1万円のBluetoothより300円の有線のほうが音良いからね。
696:デフォルトの名無しさん
20/12/26 19:12:49.05 8Nevj14A.net
C#おじさんBlazorスレでも鼻つまみ者じゃん……
697:デフォルトの名無しさん
20/12/26 19:16:07.29 UNoc468U.net
安くてもシャープはシャープ（腐っても鯛みたいな感じで）だけど、安いソニーはアイワだからね。
698:デフォルトの名無しさん
20/12/26 19:16:17.08 abA8NdUG.net
技術の話から逃げる連中ばっかりだなここは
699:デフォルトの名無しさん
20/12/26 19:23:32.52 T66JFeJq.net
C#のメリットデメリット
script系のメリットデメリット
向き不向きを知った上で正しい技術選択をすべきだな
Blazorは出来たてほやほやなので、フロントをやるとしたらjs系言語一択になるだろう。
サーバーもjs系言語にした方が技術者も集めやすいというのが一番のメリットだとおもう。
ただ、重ためのバッチ処理が入るような企業向けシステムには向かない。
エクセル管理してたものをWebシステム化する程度のものに向いている。
どうだ！
700:デフォルトの名無しさん
20/12/26 19:28:33.38 wnNA/ljl.net
>>689
お前さんが一番技術の話して無いじゃん
701:デフォルトの名無しさん
20/12/26 19:35:53.32 A5wLytvy.net
>>689
自己紹介ですか？
デメリットは？
702:デフォルトの名無しさん
20/12/26 19:42:12.23 BjZvExSE.net
685がわざわざ明確な評価基準出してくれてるのに無視してて草
>>690
> エクセル管理してたものをWebシステム化する程度のものに向いている。
それって個人の感想ですよね？
クックパッドがNext.js採用したそうですよ
703:デフォルトの名無しさん
20/12/26 19:47:23.61 Me3WzmOr.net
そういえばvueの人気が低下してきてせっかく抜いたangularに逆転されそうってマジですか？
704:デフォルトの名無しさん
20/12/26 19:53:47.56 T66JFeJq.net
>>693
個人の感想だよ
間違ってたら訂正してくれ。
クックパッドのサイトは条件に合うデータとってきて表示するくらいの要件だよね
あと個人が一件一件データを出し入れするだけの要件なら向いてる
裏で大量データの計算したり、帳票生成したりするのに向いてないのではなかろうか。
（個人の感想です）
705:デフォルトの名無しさん
20/12/26 20:01:15.31 A5wLytvy.net
>>695
帳票作成、最近うちはnodeベースのpuppeteerでPDF書き出すものを試験的に作ったけど、めっちゃ良いよ。
言うほど重くない上に、そこそこのクオリティの帳票が描ける。
というかクオリティに対する重さが極小なのと、帳票作成のしんどさが相当軽減されてる。
iTextSharpとか使ってたのが地獄だったかのような感じ。
ただどうやっても背景が透明ではなく、白い板になってるのがなんとかならんかなって思ってる。
706:デフォルトの名無しさん
20/12/26 20:05:37.15 BjZvExSE.net
>>695
でもクックパッドは凄いアクセス数を捌いてるよ？
> あと個人が一件一件データを出し入れするだけの要件なら向いてる
クックパッドのページ見てから語ろうね
というか貴方はC#のデメリットをちゃんと答えてあげなよ。Blazorが時期尚早なんて濁した回答してないでさ
707:デフォルトの名無しさん
20/12/26 20:16:33.93 BjZvExSE.net
>>696
puppeteerにそういう使い方あるのか。
スクレイピングと自動化にしか使ってなかったわ。
良いこと聞いた
708:デフォルトの名無しさん
20/12/26 20:22:06.40 q2RopqqH.net
JavaやC#はaws lambdaやgcp functionsのwarm startが遅い。ランタイム重いからね。
nodeはちょっぱや。
goは速くてしかもシングルバイナリだからgoというのは分かるがJavaやC#はダメダメだね。
709:デフォルトの名無しさん
20/12/26 20:22:56.55 q2RopqqH.net
立ち上げっぱなしだとaws lambdaやgcp functionsの意味ないからね
710:デフォルトの名無しさん
20/12/26 20:24:09.16 A5wLytvy.net
>>698
そうそう。特に単票はWeb版と同じAPIでHTML出して、帳票向けのcss当てて出力するだけだから、劇的に楽。
page.pdf()で完結。
悩むとしたら集計系とか、連続帳票のヘッダとフッタぐらいかな。
そのへんは小細工してcss書くのは諦めて、素直に複数ページ描画した。
手書きで心を込めた罫線の描画命令を書く必要もないし、クリレポ職人も要らないし、もちろんライセンスも要らない。
711:デフォルトの名無しさん
20/12/26 20:47:51.69 BjZvExSE.net
>>701
新しくAPI切ったりしなくて良いのは楽だなぁ。
前社で楽に帳票作るためにC#でxslxのテンプレートにデータ焼き込んでた怠惰な俺向きだわ
712:デフォルトの名無しさん
20/12/26 20:49:22.36 T66JFeJq.net
>>697
いやおれは要件が合えばscript系に移行することもかんがえてるC#erなんだよ
ていうかここのスレの意見聞いてたら弱点なんか全くないじゃないか
713:デフォルトの名無しさん
20/12/26 21:11:43.91 A5wLytvy.net
>>702
xlsxも綺麗に刷ろうと思うとCOMになるから、プロセスが落ちなかったりすると面倒だし、非UIのサーバアプリではやるなってのがMSの公式見解だしで、どうにかしようと行き着いたのがHTML帳票だった。
>>703
自分が知ってるC#の弱点は？
俺は色々思い浮かぶけど。
714:デフォルトの名無しさん
20/12/26 21:27:19.36 T66JFeJq.net
>>704
そもそもBlazorは未完成なのでSPAが作れないという感想
他は…
VisualStudioが重たい
.NETのサポートが短くなった
技術者を集めにくい
MSがフレームワークを作るだけつくって非推奨とか言い出す
言語というか、環境まわりだな
代わりにスクリプト系言語の弱点教えて
715:デフォルトの名無しさん
20/12/26 21:51:25.33 A5wLytvy.net
>>705
C#の弱点を聞いてて、Blazorの弱点を聞いてるんじゃない。
その全てはだいたいnodeと今時のJSのフレームワークで解決出来るんじゃないかな。
スクリプト系言語の弱点は、デプロイがちょっと面倒な事と、ランタイムが必要な事だと思う。
その辺はコンテナとか周辺技術で解決かな。
まあ、.net coreのSCDで解決しようとして未だに燻ってる所だよ。
716:デフォルトの名無しさん
20/12/26 22:12:05.25 Ii8YlEBO.net
>>656
彼が馬鹿だからさ！
717:デフォルトの名無しさん
20/12/26 22:24:59.74 T66JFeJq.net
>>706
C#の弱点はぱっと思いつかないな…
いろんな言語のいいところをパクって尚且つ非破壊だから
言語としてはひどい目にあったことはない
ADO.NETとかWebFormにはひどいめにあった
パフォーマンスや生産性がC#&ASP.NETと同等、それ以上なら前言を撤回する
以前どこかのスレに金融系のガチガチシステム、計算処理やエンドユーザー向けに大量の帳票吐く要件がある何十人ものメンバーでつくるようなシステムでスクリプト系言語使えるか聞いたらやめた方がいいって言われたことがある
718:デフォルトの名無しさん
20/12/26 22:29:52.08 aPjFRcaw.net
fastlyのcompute@edgeやcloudflareのworkersなどのエッジコンピューティングプラットフォームにC#でデプロイしてみなよ
719:デフォルトの名無しさん
20/12/26 22:36:31.82 A5wLytvy.net
>>708
いくらでも思いつくぞ。
GCがイケてない。
古いAPIが残りすぎ。
スレッドプールの使い方が下手。
最近ValueTaskが出てさらに無茶苦茶になった。
新機能がとことんシンタックスシュガーで、awaitするだけで暗黙のメンバ変数が生まれて寿命が長くなる。
いっぱいある。
それ以上だよ。少なくとも生産性に関しては。
既存資産という意味では。
規模が増えてきたら静的型付き言語でやりたくなるのはわかるけど、別に動的型付け言語でも普通にできる。
言われた事があるだけで、やってみて駄目だった訳じゃない時点でお察しだぞ。
まずは一人で、次はチームで、次はプロダクトでやって見ればいいじゃん？
720:デフォルトの名無しさん
20/12/26 22:59:58.77 T66JFeJq.net
>>710
ここに来てやっと有用な情報が出てきた…
どっちもやったことのある人の意見を聞きたかった。
スクリプト系総じてくそ！で終わらせる奴もいるし。
会社でそういう技術を試すにも理由がいるんでな。
充分選択の余地ありだな
ありがとう。
721:デフォルトの名無しさん
20/12/26 23:24:34.97 A5wLytvy.net
>>711
なんでこんなに試し試されるような会話をしないといかんか考えてよ。
みんなわかってて、批判してるんよ。
ちゃんと聞こうよ。
722:デフォルトの名無しさん
20/12/27 00:04:05.78 +391sGQI.net
またそのうちC#おじさん湧いてくるだろうけど、マジで不毛なんだよね。全く懲りない反省しない
723:デフォルトの名無しさん
20/12/27 00:24:48.94 V6kYHqJF.net
AWS Lambda には、Ruby も採用されている
マネージドサービスを使っていれば、環境構築運用など何も考える必要ない。
バッチ、Lambda、SQS・キュー、SNS・通知を、一杯つなげるだけ
724:デフォルトの名無しさん
20/12/27 01:08:11.82 pJh4CuO4.net
新規案件でSPA作りたかったらサーバーサイドもフロントサイドもC#選ぶ理由なんてないってことだ
725:デフォルトの名無しさん
20/12/27 01:34:36.12 muwPWXFk.net
>>708
VitualStudio使わなきゃいけないってのはサーバーサイドやるには結構面倒
726:デフォルトの名無しさん
20/12/27 02:16:33.08 Ezs6G331.net
>>716
なぜ使わなきゃいけないと思った？
727:デフォルトの名無しさん
20/12/27 02:17:11.17 sH9shL9g.net
C#おじさん全くスレと関係ないことを書き散らかして
自演改行しまくるから本当に迷惑
728:デフォルトの名無しさん
20/12/27 07:40:53.11 bUn1CAUk.net
自演がヒドイしとだから...
729:デフォルトの名無しさん
20/12/27 13:35:21.05 JDlKWc3Q.net
>>620
tsはまぁ分かるがjsはちょっと
pythonは古い言語だから記述のもどかしさは多いね
import周りは迷走しすぎ
730:デフォルトの名無しさん
20/12/27 16:30:32.33 xvZc4lDU.net
es3の頃のバッドノウハウを一旦リセットしてes2017とかやるとだいぶ違うよ。
同じ動的型付け言語でもpythonなんかより言語として洗練されている。
731:デフォルトの名無しさん
20/12/27 20:55:15.37 sH9shL9g.net
pythonも型書けるからねえ
tsはなんか型パズルしちゃう人が多くてよくわからん
表現力が強すぎるのも考えもの
732:デフォルトの名無しさん
20/12/28 20:26:09.84 KNPSf2Ws.net
>>710
>GCがイケてない。
JSを含む多くの言語がGCを持っている
それらのGC実装比較して具体的にどうイケてないと感じた？
>古いAPIが残りすぎ。
後方互換性は明らかなメリット
JSを含む他の言語ではそんなに簡単に後方互換性が失われて破壊的変更が頻繁に行われるの？
>スレッドプールの使い方が下手。
.NETのスレッド(を含む非同期処理全般)はうまく出来ていて最小限の労力で各環境毎に高い効果を見込めるようにできている
具体的にどういうところが下手だと感じた？
>最近ValueTaskが出てさらに無茶苦茶になった。
基本的にValueTaskを選んでおけばOKになったのでむしろスッキリした
どういうところが無茶苦茶になったと感じた？
>新機能がとことんシンタックスシュガー
シンタックスシュガーにすることによりランタイムのバージョンアップを回避して高い後方互換性を維持することができた
このメリットに対して変数のスコープが少し伸びた事によって具体的にどのようなデメリットが発生した？
733:デフォルトの名無しさん
20/12/28 21:29:19.32 8HD9KuQx.net
配点も書いてくれよ
734:デフォルトの名無しさん
20/12/28 21:49:29.10 gLlPtDZl.net
レスないからって自演かよ
735:デフォルトの名無しさん
20/12/28 22:08:20.13 KhSNASG/.net
お、屁理屈C#おじさんじゃん
736:デフォルトの名無しさん
20/12/28 22:18:18.18 KNPSf2Ws.net
なんだ
具体的に答えられないということは
やっぱり適当にそれっぽく言ってみただけか
737:デフォルトの名無しさん
20/12/28 22:27:42.95 KhSNASG/.net
まともに回答しても屁理屈で答えるか図星を突かれたら無視するような奴に、色々教えて介護してやる気は無いよ
738:デフォルトの名無しさん
20/12/28 23:18:38.63 KNPSf2Ws.net
>>728
そういうのはまともに回答できるようになってから言いなさい
739:デフォルトの名無しさん
20/12/28 23:19:49.01 0DUA8XV/.net
そもそも自演だし
740:デフォルトの名無しさん
20/12/28 23:22:09.77 or9XXg+k.net
い、一体どのレスとどのレスが自演なんだ…？
741:デフォルトの名無しさん
20/12/28 23:25:52.59 KNPSf2Ws.net
自演って言ってみたかっただけだろう
742:デフォルトの名無しさん
20/12/28 23:58:25.36 w2tkTAcI.net
GO + wasm じゃダメでしゅか？
743:デフォルトの名無しさん
20/12/29 00:52:45.33 hwRKbE5U.net
よい！
744:デフォルトの名無しさん
20/12/29 01:01:09.47 X0m1jPo1.net
wasm自体はGCサポートしてないからGC言語のGoやC#は辛いぞ。
少なくともGCをランタイムに積まないといけない。
そんなわけでwasmにはRustやC/C++ばっか使われるのだ。
C#なんかGCどころかコードをwasmネイティブにすることもできずにwasmでﾄﾞﾄﾈﾄの中間言語インタプリタ動かしてるだけだからなｗ
745:デフォルトの名無しさん
20/12/29 01:31:07.52 xrSERZg5.net
>>723
世代を超える時の扱いが雑。Goは敢えて世代管理しないという方向で行ってるが、ほぼパーフェクト。
そのせいでs
746:tackallocとか作っててワロスって感じ。 古いAPIを残してる分には良いだろう。 Obsoleteもついてないってどう言うことよ。 なんでhttpアクセスすんのにあんなに方法あんのよ。HttpClientは罠実装だし。 うまくできてない。ConfigureAwaitメソッドなんか要らない、と言えるようになってから言え。 ValueTaskを選んでおけばという発想がおかしい。 stackallocと同じ方向性の解決法。 選択肢は解決ではない。ちゃんとコンパイラがやれ。 ランタイムのバージョンアップを回避する必要性がわからん。必要ならしろよ。 それは後方互換性とは言わんでしょ。 個人的にはその寿命が伸びる件で踏み抜いたので割と嫌い。
747:デフォルトの名無しさん
20/12/29 02:30:03.59 c62SKept.net
また来たよ
もう金渡すから消えて
748:デフォルトの名無しさん
20/12/29 06:47:47.18 awsGRXp2.net
wasmにGC載せる計画はあるみたいだけど、そのGCはおそらくJSのGCと同一だろう。ChromeではwasmがTurboFan上で動くのと同様に。
これが移植上ネックになることもあるのかな、と上のを見ながら思った
749:デフォルトの名無しさん
20/12/29 06:50:26.39 awsGRXp2.net
あと、C#の話する時はC#って書いてくれ。NGするから
750:デフォルトの名無しさん
20/12/29 07:25:05.07 iWtJxFHh.net
WebAssemblyをNGわーどにしたら？
751:デフォルトの名無しさん
20/12/29 07:35:42.01 ZrXqpCJW.net
ワッチョイ付ければNG楽になるよ？
752:デフォルトの名無しさん
20/12/29 09:33:32.36 KX/n8CkP.net
一時期ﾜｯﾁｮｲｽﾚもあったけどなんか毛嫌いするヤツが多かったんだよな
753:デフォルトの名無しさん
20/12/29 11:29:58.07 b5xW7Gve.net
>>736
>世代を超える時の扱いが雑
どういうふうに雑だと感じた？
Goは世代管理をしないと言うがJSやその他の言語はどんな実装になってる？
>Obsoleteもついてないってどう言うことよ
高い互換性おかげで問題なく動作するから無理して修正する必要がないからではないかな
次期バージョンで消える可能性すらない安定したAPIになぜお節介にもObsolateを付けた方が良いと考えたの？
>なんでhttpアクセスすんのにあんなに方法あんのよ
複数の方法が共存するのは言語が後方互換性を維持しつつ順調に成長している証拠
君の考えかただと新APIだけ残して古いAPIは削除して後方互換性破壊することになる
唯一のAPIを残して他を削除すべきと考えたのはなんで？
>ConfigureAwaitメソッドなんか要らない
ConfigureAwaitはプログラム文脈から機械的に判断できないコンテキストの切り替えをコントロールするためのメソッドだ
これがないとプログラマはコンテキストの切り替えをコントロールできなくなってしまう
なぜコンテキストの切り替えをコントロールできないほうが良いと思った？
>ValueTaskを選んでおけばという発想がおかしい。
なぜ発想がおかしいと考えた？
>ランタイムのバージョンアップを回避する必要性がわからん
古いプログラムをそのまま動作保証するのに最も確実で安全で低コストな方法がランタイムをそのまま維持することだからだよ
なぜ破壊的変更が紛れ込む可能性があるのに変えなくてもいいところまでわざわざ変えたほうがいいと考えた？
754:デフォルトの名無しさん
20/12/29 11:47:10.79 awsGRXp2.net
その毛嫌いしてたのってC#おじさんじゃね？
755:デフォルトの名無しさん
20/12/29 12:02:26.55 Fq3XcUlo.net
TypeScriptも互換性維持のために同じ運命を辿るのだろうか
同じ作者だし
いまイケてる言語、フレームワークもいつかはレガシーに
ナウなヤングは気付いたらおじさんに
756:デフォルトの名無しさん
20/12/29 12:32:52.41 awsGRXp2.net
そのへんはある程度はしゃーない。
そうなったらいかにナウなヤングの邪魔をしないようにするか、いかに限られたリソースでキャッチアップするか考えるさ。
それまでに沢山経験積んどかなきゃ……
757:デフォルトの名無しさん
20/12/29 12:39:50.65 Fq3XcUlo.net
>>746
みたいなバイタリティある人はいいけど
大半の人間は潰しが効かなくなるだろうね
フロントサイドしかやってない人とか特に…
758:デフォルトの名無しさん
20/12/29 12:41:22.77 k23+wtCh.net
Cordovaは、iOS, Andoid, macOS でJSで書いたプログラムをWebViewを
使ってAppStoreやGooglePlayに登録できるアプリとして作製できるが、
iOS 11 以上だと、Wasmも実行できるらしい。Androidでは当然出来る。
そして端末の独自機能にJSやWasmからアクセスできる。
ファイルアクセスなども可能。
仕組みはJSと端末との間で通信するブリッジを用意している。
つまり、Wasmとして出力したプログラムは、Cordovaを使えば
モバイルOSで、ファイルシステムや端末の独自機能をフルアクセス
できるようになるらしい。
HttpServerなどを使ってJSとnative APIとの間が仲立ちされているので
JSからnative APIが全て使用できるだろう。
759:デフォルトの名無しさん
20/12/29 12:49:48.81 k23+wtCh.net
>>748
nativeアプリの仕組みはこうだ：
1. 時間や乱数を利用してパスワードの様なセキュリティートークンを作る。
2. Posix Socketを使ってLocal Http Serverを作る。ポート番号を5000とする。
3. WKWebViewなどのWebViewを使ってHtml+JSのプログラムを起動する。
4. 2 や 3 を起動するとき 1 のトークンを2と3の両方に渡す。
5. JSが端末の独自機能を使いたい場合、fetchやXmlHttpRequestを使って
URLﾘﾝｸ(localhost:5000)機能名?トークン&パラメータ
の様なURLでLocal Http Serverにアクセスする。
6. Local Http Serverは、トークンが正しい場合にのみ動作するようにする。
機能名とパラメータに応じてファイルの読み書きや端末の独自機能のAPIを呼び出す。
7. APIの結果は、Http プロトコルの response で JS 側に返す。
8. JSは結果を受け取る。
760:デフォルトの名無しさん
20/12/29 12:54:14.36 4hVd0nGl.net
wasmってブラウザだけじゃなくK8SでもIo
761:Tデバイスでも動くわけだし モバイルでも動かしたいって欲求も当然出てくるだろうな そうなるとストアアプリの実装言語も将来的に何でもありになるのかもね
762:デフォルトの名無しさん
20/12/29 13:29:33.29 xrSERZg5.net
>>743
nodeなんかはインクリメンタルではなかったっけ。
Javaはアプリの仕様に合わせて好きに選べる。
awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
ライブラリ関数ではゼロアロケーション意識しないといかんレベル(ライブラリ関数でgcが起きるとgen0がライブラリ関数で尽きるので呼び出し元がgen1にあっさり追い出される)
.net coreでやっとある程度柔軟にはなったものの。
無理して修正する必要はない。
逆だろ。処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん。
それ言い続けて、限界を迎えたら.net core？
アホかな。
後方互換性を維持しつつ順調に成長してるならば、関数が変わるよな。
実のところ、本館、新館、別館と建て増した温泉旅館だよ。
古いAPIは2世代ぐらいで殺すべきだろ。
なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
コントロールできない方が良いんではない。
コントロールする必要があるのがアホかなって言ってる。
UIスレッドだけ特別扱いしてるところからわかるだろ。
中途半端。
発想がおかしい理由がわからんならもう黙れよ。
古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が好きならちゃんと考えろよ。
763:デフォルトの名無しさん
20/12/29 13:57:14.43 Fq3XcUlo.net
すっげえわかる
MSってほんと最低な奴だよな…
764:デフォルトの名無しさん
20/12/29 14:21:44.49 xrSERZg5.net
ホントに他の言語やれと。
俺ずっとVue+JavaScript派だったけど、最近何周か遅れてReact+TypeScriptやってて、これはこれで確かにいいなと思ったりしてるぞ。
いろんな設計思想があるのは良いじゃん。最強で至高なんかねえよ。
めっちゃ叩いたけど、そのすぐ裏側はC#の良いところなのもわかってるからな。
765:デフォルトの名無しさん
20/12/29 14:36:53.53 EHaGj/ct.net
>>751
>Javaはアプリの仕様に合わせて好きに選べる。
結局のところアプリのメモリ使用特性に合わせて選択するのが賢いのであって特定の実装が良い悪いという絶対的な指針はないのだろうね
ではなぜ君は.NETのGCが絶対的に悪いような言い方をしたのかな？
>awaitで寿命が伸びる件と相性が悪いけど、あまりにも世代1に行き過ぎ。
awaitシンタックスシュガーで変数の寿命が伸びていたのは昔の話
少なくとも7年前には非同期を跨がない変数はキャプチャされなくなった
なお非同期をまたぐ変数の寿命が伸びるのは非同期処理の宿命でありawaitシンタックスシュガーは関係ない
なぜ君はawaitシンタックスシュガーが変数の寿命を伸ばすことを問題視したの？
>ライブラリ関数ではゼロアロケーション意識しないといかんレベル
C#のメモリ管理サポートは.NET Coreで急激に進歩している
他の多くの高級言語ではゼロアロケーションを意識しても難しいがC#ではそれほどでもない
これはパフォーマンス意識する上で非常に大きい
アロケーションを減らせるならGCの負荷も小さくなる
JSなど他の言語では機械的な最適化以外にメモリ確保そのものを大幅に減らす工夫はあるのかな？
766:デフォルトの名無しさん
20/12/29 14:37:48.66 EHaGj/ct.net
>処理系のバージョンアップ側にメンテナンスコストかかり続けるじゃん
いやいや処理系のメンテナスコストは低いよ
だって仕様が変わってないんだから
シンタックスシュガーのバージョンアップで変化するのはコンパイラのほうね
>それ言い続けて、限界を迎えたら.net core？
Coreへの移行はメンテナンスが累積して限界を迎えたから行ったわけではないよ
主な理由はマルチプラットフォームへの対応を迫られたから
>実のところ、本館、新館、別館と建て増した温泉旅館だよ。
>古いAPIは2世代ぐらいで殺すべきだろ。
その本館も新館も別館も安定稼働してお金を稼ぎ続けている
なのになぜむりやりお金をかけてまで閉じる必要があるのかな？
>なんで.NET FWがあんなに亀レベルでしか成長できなかったと思ってんの。
.NET FWというかC#の成長は速かったよ
いくつもの先進的な機能たとえばLinqだとかReactiveExtensionだとかAsync/Awaitだとかを生み出して
他の言語はC#を追いかけるように機能を模倣してきた
>コントロールする必要があるのがアホかなって言ってる。
コントロールする必要がなければデフォルトでいいよね
コントロールしたいときにできないのは大きな問題だとは思わないかい？
>UIスレッドだけ特別扱いしてるところからわかるだろ。
これは言語の問題ではなくOSアーキテクチャの成約ね
他の言語だってUIスレッドは特別なもの
もしコンテキスト切り替えをコントロールできない言語だと特別なスレッドのために他の関係ないスレッドがパフォーマンス上の不利益を被る
767:デフォルトの名無しさん
20/12/29 14:38:21.55 EHaGj/ct.net
>発想がおかしい理由がわからんならもう黙れよ。
わからないから説明をしてほしいのだけど？
根拠も理由もなく発想がおかしいというだけではまったく意見になってないよ
>古いプログラムをそのまま動作保証するために必要なのは、互換性ではなく、そのバージョンをLTSにしてちゃんとパッチ出してく事だよ。
.NET FWはそのあたり手厚いね
未だにWinアップデートで3.5のセキュリティパッチとか落ちてくるでしょ？
>で、SideBySideできるようにするか、コンテナにするかどっちかだろ。
.NETはSBSもサポートしているね
コンテナ化することをそのまま動作保証とは普通は言わない
>バージョンアップするけど(だいたい)互換性はありまぁすとか言ってるから、2020年なのに.NET FW 4以上に上げられん基幹系みたいな負の遺産を残すんじゃないか。
負の遺産ではなく未だに安定して利益を生み出す正の遺産だよ
負の遺産っていうのは言語のAPIが急にサポート切れになって大幅な改修を入れなければならなくなり開発コストで大損したみたいな場合ね
>お前が言ってることはC#というか.NETを何度もだめな言語にしてきた老害の発想だからな。
C#が駄目な言語になったことなんてないよ
VBという悲しい過去があるので.NET全体を称賛するわけにもいかないが
C#は常に成功してきたしこれからも成功する言語だと確信している
768:デフォルトの名無しさん
20/12/29 14:46:23.51 xrSERZg5.net
>>754
絶対的に悪い部分はあるだろ。
「挙動の変更不可」。
「GCの挙動が気に食わん」の解決法が「別のGCを選べる」というのは、GCの設計として正しい。
「気に食わんけど耐えるしかない or ワークアラウンドで対応」
これはなんの解決でもない。
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
769:デフォルトの名無しさん
20/12/29 14:54:23.36 xrSERZg5.net
>>755
高いよ。
お前あんまりミッションクリティカル系でC#使ってないだろ。
違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
特にPCL。あれで現に破綻しただろ。
安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
>>755
言語仕様は早かったな。
で、2016年まではawaitでキャプチャしてたとか、歪な形になってたわけだ。
その頃のアセンブリはもちろんその頃のまま。パフォーマンスもお察し。
さらに今のコンパイラでコンパイルしたものとILは異なるよな。
そのあたりで踏み抜くものが多すぎるんだよ。
コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
UIスレッドだけ特別視するのが悪いと言ってるんじゃない。
「UIスレッドはちゃんと勝手にConfigureAwaitできてるじゃん。お前らなんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
手動設定信仰過ぎるだろ。
770:デフォルトの名無しさん
20/12/29 14:56:52.79 EHaGj/ct.net
>>757
>「挙動の変更不可」。
.NETもパラメータである程度の調整はできるようだが…
アルゴリズムを手軽に差し替えるような解決策が用意されている言語はどれほどあるのだろうか？
非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの？
難しくないから、人間がやれば良い？
アホか？
じゃあGoみたく、ベンチツールにデフォでアロケーションカウンタついてるのか？
そうでもないだろ。
他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
771:デフォルトの名無しさん
20/12/29 14:58:38.03 xrSERZg5.net
>>756
ほう、4.0と同時に入れられる4.xがあるなら手厚いと言えるだろうな。
コンテナ化する事を動作保証と言うぞ。
というか、完璧に構成管理してやっと動作保証できるものであって、コンテナ化に関しては理想型だろ。
安定して利益を生み出す、で履き違えるな。
負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
言語のAPIが急にサポート切れ、な。
いつ誰がやらかしたかな？
772:デフォルトの名無しさん
20/12/29 15:05:12.04 xrSERZg5.net
>>759
焦って途中でレスすんなよみっともない。
ほかのすべての言語はできるがC#だけは出来ない、と言ってるんではない。
C#が得意な事とそうではない事があることは認識しろ、と言ってる。
他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#なら、C#でも、ってのは、そりゃ原理上可能だろ。可能じゃなかったらチューリング完全でない。
ただ、向いてるかって聞くと、それぞれもっと向いているものを知ってる人間は居るってことなんだよ。
ちょっと冷静に考えろ。
C#は好きだが、議論の道具として叩いてて、反対側にはメリットもあるのはわかってんよ。
773:デフォルトの名無しさん
20/12/29 15:10:39.54 EHaGj/ct.net
>>757
>「気に食わんけど耐えるしかない or ワークアラウンドで対応」
>これはなんの解決でもない。
GCの差し替えができないならそうするしかない
C#は他の言語と違って安全なメモリ管理サポートが充実しているので「耐えるしかない」ということはない
>非同期を跨ぐときに伸びるから問題なんだよ。
ずいぶん質問が多いが、なぜ、問題視しなくて良い、と言い切れるの
非同期を跨いで利用される変数のスコープが伸びることは必然だから問題じゃない
もし問題だというならそれはシンタックスシュガーのせいではなく非同期アルゴリズムの設計に問題がある
言語のせいではなく設計ミス
>他の言語を引き合いに出す前に「できるだから気合で解決」をまず減らせよ。
そうじゃない「他の言語でできないor難しいことが簡単に出来る」と言ってる
たとえばC#のref構造体やspanのように安全に低頻度のアロケーションをサポートするスクリプトが幾つあるだろう
774:デフォルトの名無しさん
20/12/29 15:24:29.79 EHaGj/ct.net
>高いよ。
>お前あんまりミッションクリティカル系でC#使ってないだろ。
処理系のメンテコストの話がミッションクリティカルでのC#利用経験の話になるのはなぜ？
>違うよ。マルチプラットフォームへの対応だけであればPCL、.NET Standard、あのあたり何だったことになる？
>特にPCL。あれで現に破綻しただろ。
PCLは確かにあまりうまく行っていなかった
うまく行っていなかったからこそだ
本格的なマルチプラットフォーム対応のためのCoreでありStandard
>安定稼働してお金を稼ぎ続けてるなら、3棟それぞれメンテしろ。
>お金をかけてまで維持するのとお金をかけてまで閉じるのは同じ話だ。
もちろんメンテナンスは続けてるだろ
古いコード新しいコード両方が安定して稼働するからこそ安価にメンテナスが可能となる
APIが急になくなったらちょっとしたメンテナンスでも大騒ぎだ
>そのあたりで踏み抜くものが多すぎるんだよ。
多すぎるというからには何かしら数字が出てるのだと思うけど示せる？
>コントロールしたいときに出来ないとかそんな事を言う時点で「スレッドプールとは」って話なんだよ。
すまん
正直意味不明なので説明を求む
>なんで他のコードでも同じように勝手に処理されるように、メソッドの属性とかそういうもので解決しなかったの？」という話なんだよ。
その属性をつけるのは結局手動だろう？
自動化信仰も結構だが世の中全てを自動化できるわけではない
手動で解決してる理由は機械的、自動的に決定できないからだよ
機械的、自動的に決定できないものに対して取れる最もマシな方法は昔から決まってて
事故が起こりにくい方をデフォルトにする
どちらも安全なら統計を撮って利用頻度で決める
775:デフォルトの名無しさん
20/12/29 15:34:45.80 EHaGj/ct.net
>>760
>コンテナ化する事を動作保証と言うぞ。
いや言わない
基本的に今まで動作していた環境で同じように動作することを動作保証という
新しくコンテナに載せ替えるかどうかは動作保証とはまったく別のベクトルの話であって関係がない
>安定して利益を生み出す、で履き違えるな。
>負の遺産と言うのは、現状利益を生み出しているかとは全く関係のない尺度だ。
技術的負債のことを言いたいのだろうけど
古いAPIが全て負の遺産であるような認識は典型的な間違いだぞ
たとえ古いAPIを使っていてもテストが整備されていて設計が美しく開発環境の準備が難しくないならそれは借金でもなんでもない
>言語のAPIが急にサポート切れ、な。
>いつ誰がやらかしたかな？
.NETでは幸いなことにまだぶち当たったことがない
776:デフォルトの名無しさん
20/12/29 15:40:20.23 Fq3XcUlo.net
なげーなー
C#はSPAには特化してない
歴史的な経緯があるからそのせいで扱いにくいこともある
SPA作るなら特化しているReact+ts使った方が幸せになれる
ってこと？
777:デフォルトの名無しさん
20/12/29 15:43:25.20 EHaGj/ct.net
>>761
>焦って途中でレスすんなよみっともない。
うるせえな寒くて手が滑ったんだよ
暖房つけたからもう大丈夫
>C#が得意な事とそうではない事があることは認識しろ、と言ってる
C#より上手く特定の分野を実装できる言語はあると思う
しかしC#は各分野で最高とまでいかなくとも何でも得意で
C#が特別に苦手なことというのはない
そういう成績オール5 or 4的なところが気に入ってる
>他の言語を選択するメリットは無い、と言い切ったのが破綻してることはもう充分理解できただろ。
C#を使えるなら他を使う「積極的」なメリットは無い
他の言語が特別に得意な分野がどうしても必要なときに仕方なくその言語を使う程度の塩梅でおｋ
778:デフォルトの名無しさん
20/12/29 15:49:41.14 EHaGj/ct.net
>>765
>C#はSPAには特化してない
SPAについてはまだまだ黎明期
>歴史的な経緯があるからそのせいで扱いにくいこともある
新規に開発する分には扱いやすい
レガシーがモダンと比較して扱いにくいことがあるがそれはレガシーなので仕方がないこと
レガシーが安定して動作するよう後方互換性とセキュリティパッチが充実しているので
レガシーのメンテナンスを最小化することができる
>SPA作るなら特化しているReact+ts使った方が幸せになれる
人による
現時点ではReact+TSのほうが支持者が多い
779:デフォルトの名無しさん
20/12/29 15:51:29.01 xrSERZg5.net
>>766
全部言い訳だわ。
GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
ケース知らなすぎるだろ。
他の事も色々間違ってるがもうそもそもおかしい。
C#は別になんでも得意じゃねえぞ。
オール3だよ。
C#でこれは4だなって思うのはLinqぐらいだ。それももう追いつかれた。
他の言語を知らんから、本当の5を知らんのだろ。
積極的なメリットは無い。知らないからそりゃそうだろうな。
それでC#が好きだとほざくな。
780:デフォルトの名無しさん
20/12/29 15:55:19.91 yginI0z/.net
・・・本当の5の言語って何や？
781:デフォルトの名無しさん
20/12/29 16:04:46.05 xrSERZg5.net
>>769
人とニーズによるだろうけど、Goの並行処理とか、
Erlangのメッセージパッシングとか、
F#の測定単位とか、
Lispのマクロとかかな。
JavaScriptも、あれはあれでとても良いと思う。
782:デフォルトの名無しさん
20/12/29 16:08:35.63 b5xW7Gve.net
>>768
>GC(メモリ管理サポート)に文句つけて、GCがあるから問題ないとか寝言言ってるのか？
大抵のことはGCで問題ない
クリティカルなところでのC#なら安全に比較的細やかにメモリ管理ができるので問題ない
>IDisposableなクラスでawaitで暗黙のメンバ変数になったらいつまで寿命伸びると思う？
当たり前だがDisposeするまでだろ
非同期挟もうが挟むまいが不要になった時点で速やかに破棄される
awaitを使ったからと言って必要もないのに無駄に変数の寿命が伸びることはないよ
伸びるのは非同期処理を実装するのに本当に必要な変数だけだ
>本当の5を知らんのだろ。
例えば？
783:デフォルトの名無しさん
20/12/29 16:11:47.13 Fq3XcUlo.net
>>769
5=GOなんだろ
ダジャレだよダジャレ
エスプリの効いたギャグをかましてくれたんだよ
784:デフォルトの名無しさん
20/12/29 16:24:08.58 Fq3XcUlo.net
>>770
これ特化してるところじゃん
あらゆる分野において平均以上かどうかなんじゃないの
ジェネラリストかスペシャリストか
785:デフォルトの名無しさん
20/12/29 16:24:33.75 b5xW7Gve.net
>>770
果たしてそれがメインの開発言語を乗り換えるほどの価値があるかどうかだよね
自分はとてもではないがそうは思えない
もし本当にどうしても避けられずそれが必要になったら局所的にその言語で実装してメイン言語から呼び出すって形にするだろうな
まあGoぐらいなら別にメインにしてもいいかなぁ…とは思うがね(実際にはしないだろうけど)
786:デフォルトの名無しさん
20/12/29 18:16:37.52 Hcyt9B7d.net
C#は素敵な言語だけどさすがにオール5は言い過ぎたねって話だね
787:デフォルトの名無しさん
20/12/29 18:29:46.92 Cpv18UIo.net
なんでこの人たちいつもC#の話してるの？
788:デフォルトの名無しさん
20/12/29 18:30:27.64 xrSERZg5.net
>>773
5ってのは、そういう事だと思うぞ。
4で、それが書きやすい、程度。
>>774
ニーズ次第じゃないかな。
789:デフォルトの名無しさん
20/12/29 18:44:00.86 awsGRXp2.net
オール5の言語なんてLispしかないよ！DSLで何にでも特化できるから！神はLispで世界を作ったんだぜ！（ぐるぐる目）
冗談はさておき、昔のJSはLispの匂いがして好きだった。今は（TSは）Lispの匂いほぼなくなって、万人ウケしやすい言語になったと思う。
790:デフォルトの名無しさん
20/12/29 19:19:37.56 xrSERZg5.net
>>778
ほんとにそれよね。JSはC構文のLispっぽくて好きだったけど、TSでどんどん静的な言語になってしまってる。
791:デフォルトの名無しさん
20/12/29 19:25:03.79 PuaagtBb.net
高階関数で関数型プログラミングの匂いはするがLispの匂いはしない
Lispって全部がリストになってるから
792:デフォルトの名無しさん
20/12/29 19:35:30.70 xrSERZg5.net
>>780
applyと分割代入あたりが、おおむね対応するんではなかろうか。
793:デフォルトの名無しさん
20/12/29 19:39:46.86 LSI+C1uB.net
C#をNGにしたら書き込み全部消えちゃった
794:デフォルトの名無しさん
20/12/29 19:41:55.81 xrSERZg5.net
まあ、作った人がScheme意識してるって言ってるからな。
URLﾘﾝｸ(brendaneich.com)
795:デフォルトの名無しさん
20/12/29 19:47:54.10 awsGRXp2.net
全部がListだったらそれはもう匂いがするどころではなくLispそのものだと思う。
Lisp脳だったのでTS始めた時は型演算そのものを(Lispみたいに)JSで書かせてくれと思ったよw
796:デフォルトの名無しさん
20/12/29 19:53:01.60 awsGRXp2.net
Lispの匂いといえばMozillaのlet式が没ったのは返す返すも残念だった。今はdo式に期待してる
797:デフォルトの名無しさん
20/12/29 21:12:55.98 LSI+C1uB.net
>>778
Lispのどこがいいんだ？
全てにおいて不便なだけな気がするのだが
798:デフォルトの名無しさん
20/12/29 23:06:44.05 awsGRXp2.net
Lispのデータとソースコードは全てListである。
Lispは主にListを操作してプログラムする。
Lispには文は無く、式だけがある。
LispのマクロはListであるLispソースコードの操作をLispで行う。
Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。あらゆるコードを抽象化できる。
スレ違いだからあとは調べてね。
これは個人的な所感だけど、
ありとあらゆる式文が作れる（抽象化できる）ってことはつまり俺ルールがまかり通って分断を招く言語って事だから、そりゃ一般向けじゃないやね
799:デフォルトの名無しさん
20/12/29 23:19:25.78 c62SKept.net
>>787
そのせいでクオートとか関数クオートみたいな邪悪な存在が生まれたのは無視かな？
800:デフォルトの名無しさん
20/12/29 23:26:15.08 Ba9B66hW.net
>>787
長々と書いてるがメリットってこれだけだろ？
> Lispのマクロはありとあらゆる式をList操作で作り出せるのでDSLが簡単にできる。
DSLを作りたいやつがどれだけいるか知らんが
DSLというのはただの関数に過ぎない
だからどの言語でも関数を作ることで簡単にDSLを作れるぞ
801:デフォルトの名無しさん
20/12/29 23:36:01.58 awsGRXp2.net
細かい反論はあるけど概ねご批判の通りだよ。
だから流行らない。俺は好きだけどね
802:デフォルトの名無しさん
20/12/29 23:38:23.99 Ba9B66hW.net
URLﾘﾝｸ(xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com)
> DSLは、大きく内部DSLと外部DSLに分類することができます。
>
> 内部DSL: 内部DSLは、汎用のプログラミング言語の書き方を工夫して、
> 見かけ上の構文を自然言語に近づけた言語です。
書き方を工夫するだけだからどの言語でも出来る
> 外部DSL： 外部DSLは、汎用のプログラミング言語とはまったく別の構文を持ったDSLです。
こっちはlispでも作りづらい
803:デフォルトの名無しさん
20/12/29 23:46:09.89 Ba9B66hW.net
内部DSLの場合、言語によって自然言語に近づけるといっても限界がある場合がある
えばC言語なら、 This("is", "a", "pen"); が限界だろう
これがRubyだと This "is" "a" "pen" となる
is とか a とか を定義すれば、This is a "pen" と書けるかもしれないな
だがシェルスクリプトであれば This 関数を作るだけで
This is a pen と書くことが出来る。
ダブルクォートでくくらなくても文字列として扱われるからだ
内部DSLを作るのに一番適した言語はシェルスクリプトだと思うが
それはそれとして、DSLを簡単に作れる言語の条件はリスト操作をしてるとかではなく
引数を () でくくらなくても良いとか最後にセミコロンがいらないとか
そういう言語ではないだろうか？自然言語は () でくくらないからな
804:デフォルトの名無しさん
20/12/29 23:52:22.87 Ba9B66hW.net
引数の区切りにカンマが不要ってのもDSLに適した言語の条件かな
805:デフォルトの名無しさん
20/12/30 00:05:32.15 TuVgzDLD.net
>>789
kotlinぐらいじゃないかな。
無茶めな構文が変わるレベルのDSLが作れるの。
S式として成り立ってればどんな構文すら作れるから、関数を作ることで作れるとか言ってるレベルじゃないぞ。
それが良いことかはおいといて。
806:デフォルトの名無しさん
20/12/30 00:08:13.49 Zk/FBUc0.net
どんな構文でも作りたいわけじゃない
「自然言語」に近い構文を「簡単に」作れるというのが条件
自然言語というのはシンプルで、単語を並べるだけなのだ
仮にkotlinでC言語の構文に対応できたとして
それはDSLとしてはふさわしくない構文
807:デフォルトの名無しさん
20/12/30 00:08:25.33 olxuh5fb.net
>>789
JuliaとRustはそこそこ無茶なこともできるしな
ASTレベルでの操作だし
Lispプログラム=実質的なASTと考えると何も変わらん
そこの優位性ももはやない
808:デフォルトの名無しさん
20/12/30 00:15:06.44 Zk/FBUc0.net
>>796
だからプログラム言語を作りたいんじゃなくて
DSL（自然言語風）を作りたいんだってばｗ
809:デフォルトの名無しさん
20/12/30 00:19:04.50 Zk/FBUc0.net
あと「簡単に」ってのも重要
作れるけど大変っていうのは簡単ではない
810:デフォルトの名無しさん
20/12/30 00:19:15.74 olxuh5fb.net
Lispは自然言語風ではないだろ
あの括弧なんとかしろよ
811:デフォルトの名無しさん
20/12/30 00:21:48.47 TuVgzDLD.net
DSLって別に自然言語に寄ってなくても良いんじゃないか？
ドメイン記述に便利な表記であればそれで良いかと。
昔ウィジェットツリーをそのまま書いたらマクロで展開されるとかそういうの書いたことあるけど、自然言語寄りではなかったな。
最近で言うとkotlinのankoみたいなやつ。
812:デフォルトの名無しさん
20/12/30 00:26:09.36 Zk/FBUc0.net
> DSLって別に自然言語に寄ってなくても良いんじゃないか？
それは正しいが「自然言語と異なる別のプログラム言語」を
覚え直さなければいけないのはナンセンスだろ
813:デフォルトの名無しさん
20/12/30 00:26:50.79 Zk/FBUc0.net
（なぜか「当分お断りしております。」が出たので分割して書き込み）
独自のDSLを作る場合、新たな言語を覚えなおさなくていいように
誰もが知ってる自然言語に近い構文にするのが普通
814:デフォルトの名無しさん
20/12/30 00:27:23.67 Zk/FBUc0.net
そうしないとDSLを使うことで
815:デフォルトの名無しさん
20/12/30 00:28:25.07 Zk/FBUc0.net
ぎゃくにこーどがわかりづらくなる
DSLの特徴である「ドメイン固有の処理を簡単に表現できる」に反してしまう
816:デフォルトの名無しさん
20/12/30 00:29:06.25 Zk/FBUc0.net
（なんで「ぎゃくにこーどが」を漢字とカタカナにしたら書き込めないんだ？）
817:デフォルトの名無しさん
20/12/30 00:30:13.27 Zk/FBUc0.net
「コ ー ド」をスペース抜いたら書き込めない
818:デフォルトの名無しさん
20/12/30 00:34:39.76 DCxLNcGT.net
こうやって言語機能そのものみたいな基本部分の重箱つついて、何かあるとすぐちゃぶ台返しして応用や発展的な話題出ないの最高に5chのプログラム板って感じ
819:デフォルトの名無しさん
20/12/30 00:35:42.82 olxuh5fb.net
そもそもすれ違いだぞ
820:デフォルトの名無しさん
20/12/30 00:41:11.57 Zk/FBUc0.net
>>807 そういうことじゃなくて「色々出来る言語」を過大評価しすぎってこと 簡単に目的を達成できる方が重要なのに 色々出来るんやでだからすごいっていう考えが古臭い
822:デフォルトの名無しさん
20/12/30 00:56:40.62 lXmFrXZN.net
コード
823:デフォルトの名無しさん
20/12/30 00:59:28.01 nb9M1V+x.net
>>810
どうやらブラウザ（ユーザーエージェント？）も関係あるっぽい
Chromeでは書き込めず、Firefoxなら書き込めた
その他の情報も見てる可能性があるな
IPアドレスは変えてもクッキー消しても意味はなかった
824:デフォルトの名無しさん
20/12/30 01:01:03.26 eKh3SvG1.net
スレ違いなネタでろくに知識もないのに平気で一人で盛り上がってる感じ、またC#おじさんかよ。NGすとこ