タグ

ブックマーク / zenn.dev/mizchi (6)

  • Zig 言語のファーストインプレッション

    Bun を読むにあたって、まずZigを抑える必要があると思ったので数時間学習してみた。チュートリアルを一通りやったのと、ちょっと手を動かした程度で、正直エアプの域は出てない。 自分の動機として wasm を吐くのに使う言語をずっと探していて、Rust も悪くないが正直学習コスト高すぎでしんどく、Zig がそれに足るか調査していたという感じ。 この記事を書くにあたっての細かい作業はこちら https://zenn.dev/mizchi/scraps/287b4414da2b29 Zig 言語自体のスタンス まず Zig 言語自体がなぜ D や Rust ではないかはこの記事がわかりやすい https://ziglang.org/learn/why_zig_rust_d_cpp/ 以下 Deepl で訳してちょっと修正したもの nostd 指向 標準ライブラリなしでもファーストクラスでサポート

    Zig 言語のファーストインプレッション
    hamamuratakuo
    hamamuratakuo 2022/07/24
    "結局自分が zig を使うかというと、エコシステムが充実して、LSP による支援が充実した段階で再検討という感じ。"
  • Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか

    Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho

    Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
  • 現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング

    オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドReact と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer

    現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
    hamamuratakuo
    hamamuratakuo 2021/01/22
    宣言的に書く=「MECE」が重要。処理の失敗は副作用がある部分(I/O→APIサーバからの応答遅延等)でのみ生じる。失敗した場合の例外処理(リトライ)が重要。圏論や集合論を土台にすればクラスの代わりに型を使える?
  • Re: Rails を主戦場としている自分が今後学ぶべき技術について

    この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

    Re: Rails を主戦場としている自分が今後学ぶべき技術について
    hamamuratakuo
    hamamuratakuo 2020/12/14
    WebのGUIは特殊。C/Sの結合点は単なるAPIと化し、C/Sの密結合を避ける。サーバーサイドにJSやAltJS(TS等)を持ち込む必要はない。DHHは間違ってない。Railsを置き換えるなら、APIを作りやすい言語やFWの採用を検討すればいい。
  • 2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを全部試した

    この記事は、Next.js Advent Calendar 2020 の6日目。 突然だが、2021年 は Fullstack Next.js 元年になる。 その理由として自分は以下のものがあると思っている。 ベストプラクティスとしての TypeScript のデファクト化 Next.js の Dynamic Routes による動的パス、 getStaticProps/getServerSideProps による使い勝手の向上 Vercel によるISRの発明 prisma の成熟 Vercel / Serverless / Cloudflare Workers / Cloudrun 等による Node.js サーバーの運用コスト減 参考: Frontend Study #1: 基調講演 - Frontend 領域を再定義する Blog - Next.js 9.3 | Next.js R

    2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを全部試した
    hamamuratakuo
    hamamuratakuo 2020/12/06
    WebでGUIを作るときのベストプラクティスがないので、いろいろなJSフレームワークやAltJSが試行錯誤されている?TypeScript≒C#の下位互換言語→Windows(C#)、iOS(Swift)、Android(Kotlin)のGUI作法~流儀も参考にするとGood?😅
  • プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法

    プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js(ただし暫く何も足さない)がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ

    プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
    hamamuratakuo
    hamamuratakuo 2020/11/13
    まとめ 初心者は N予備校、JS Primer でキャッチアップして、中級者以降は jser.info や GitHub Trending を眺めるのがオススメ
  • 1