HackerLangs
トップ新着トレンドコメント過去質問紹介求人

tapirl

871 カルマ登録 11 年前

投稿

Some (Real) Go Subtleties

go101.org
3 ポイント·投稿者 tapirl·9 か月前·0 コメント

コメント

tapirl
·12 時間前·議論
Performance alone doesn't always imply verbosity, but combining it with other goals—such as increased security and more power std APIs—often does.
tapirl
·一昨日·議論
Zig is indeed verbose in some aspects, but not overall. For example, its `try error-union` syntax eliminates a lot of boilerplate code.

The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is a worthy tradeoff.
tapirl
·9 日前·議論
Unlike Google, the AI wave appears to deliver positive revenue impacts for Microsoft.

The company does need to integrate the new AI-human-machine interface into its application development SDKs.
tapirl
·9 日前·議論
Thanks for the info. Updated.
tapirl
·9 日前·議論
Full List Of Open Source Physics Engines: https://www.tapirgames.com/blog/open-source-physics-engines
tapirl
·10 日前·議論
About Jolt, do you mean https://github.com/jrouwe/JoltPhysics ?
tapirl
·25 日前·議論
No specific examples. Just general GUI apps.
tapirl
·26 日前·議論
Slow means many: * long program launch times * inconsistent frame rates during runtime * noticeable lag in user interaction
tapirl
·28 日前·議論
web UI is slow, this is only reason when I don't it.
tapirl
·先月·議論
Having quick viewed all the chapters, the examples are too simplistic to fully demonstrate Zig's syntax and semantics.
tapirl
·先月·議論
[dead]
tapirl
·先月·議論
Yes, the sugar is just to make chain calls with parameter types possible. The sugar reflects the limitation of the basic of Go generics design. Now they would make the language even more complex for such a small need. In facts, there are more problems in Go generics need to be solved earlier than this: https://go101.org/generics/888-the-status-quo-of-go-custom-g...
tapirl
·先月·議論
Go's generics design is the most clunky one among popular languages.
tapirl
·2 か月前·議論
Are there any evidences which prove the process was done in a week?
tapirl
·2 か月前·議論
It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.
tapirl
·2 か月前·議論
> ..., comptime that is more powerful than Zig

It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
tapirl
·4 か月前·議論
> ... and perhaps `go fix` should add a check for this (

This is an impossible task. For a library function, you can't know whether or not the function is defer called.

Maybe this is not an important problem. But it would be better if the blog article mentions this.
tapirl
·4 か月前·議論
another:

   package main

   type T = [8]byte
   var a T

   //go:fix inline
   func foo() T {
      return T{}
   }

   func main() {
      if foo() == a {
      }
   }
filed: https://github.com/golang/go/issues/78170 and https://github.com/golang/go/issues/78169
tapirl
·4 か月前·議論
similar:

    package main

    //go:fix inline
    func foo[T [8]byte | [4]uint16]() {
        var v T
        var n byte = 1 << len(v) >> len(v)
        if n == 0 {
            println("T is [8]byte")
        } else {
            println("T is [4]uint16]")
        }
    }

    func main() {
        foo[[8]byte]()
    }
tapirl
·4 か月前·議論
Another example (fixable):

    package main

    import "unsafe"

    //go:fix inline
    func foo[T any]() {
        var t T
        _ = 1 / unsafe.Sizeof(t)
    }

    func main() {
        foo[struct{}]()
    }
Go is a language full of details: https://go101.org/details-and-tips/101.html