ply VS go

Compare ply vs go and see what are their differences.


Painless polymorphism (by lukechampine)


The Go programming language (by golang)
Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
ply go
2 838
117 94,272
- 1.7%
0.0 10.0
almost 5 years ago 5 days ago
Go Go
MIT License GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of ply. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-05-05.


Posts with mentions or reviews of go. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-01-12.
  • /u/HeMan_Batman's based/cringe list for 2022-01-16
    1 project | | 15 Jan 2022
    (This list is automatically posted once every 24 hours to ensure I never break the Rule ever again. Bot written using Go and run using AWS Lambda)
  • GoGCTuner brought CPU utilisation down ~50%
    5 projects | | 12 Jan 2022
    I really hope that they will release this as a library. We're having the exact same challenges running Go in production.

    The biggest challenge with Go in production is that, as the article points out, Go doesn't have a maximum memory setting that can be used to tune the GC. If you run Go with a memory limit on Kubernetes, it's common for it to simply run out of memory rather than using the limit for backpressure.

    This is kind of surprising, since Go is so entrenched in the Kubernetes world (and both Docker and Kubernetes are written in Go). It's possible that Google itself doesn't develop that much stuff in Go, and that the Go team doesn't have a huge incentive to innovate in this area.

    There have been a few attempts at improving heap management, including an aborted attempt at respecting ulimit [1], a promising implementation of a SetMaxHeap() function [2], and a propsoal for dealing with backpressure [3], but these projects have mostly failed to get proper traction. It's a complex problem that needs a cohesive solution.

    Fortunately, there is now a proposal [4], which has been accepted, to add a soft limit to Go, which has a more thought-through design, though I'm not sure if it's being actively worked on. I'm also not sure if that proposal, when implemented, will make the Uber approach redundant, or if these are in fact complementary.





    5 projects | | 12 Jan 2022
    Weird to not see any references to /

    There's been a lot of back-and-forth on how to improve the tuning situation in go. See It seems like Michael Knyszek will be doing something about it for go 1.19.

  • Runtime immutability checks library
    6 projects | | 11 Jan 2022
    I've found this excessive allocating behavior when making a bunch of benchmarks for this project, so I decided to report it, but first I googled if anyone already reported something like that, and apparently, it was a known problem with an already existing proposal on how to fix it. Sometimes I read notes from this issue to be up to date with recent discussions and proposals.
    6 projects | | 11 Jan 2022
    This change Right now traversal of map items via reflect requires allocation for every key and value, but this change should help.
  • iter: Generic, lazy iterators for Go 1.18
    4 projects | | 10 Jan 2022
    Also, can anyone explain the error "instantiation cycle" to me? I have two methods commented for which this was occuring: Position in iter.go, and ZipEndo in zip.go, and I'm not sure what this error means, or why it occurs, since the corresponding function implementation (Zip) of ZipEndo has no such problem. I don't believe it's an implementation bug in the tuple package, since I was originally using my own simple 2-value tuple struct and the exact same error ocurred. The only thing I can find about it online is this post, but I'm not sure how the answer there applies to either of my cases...
  • Hey Rustaceans! Got an easy question? Ask here (2/2022)!
    9 projects | | 10 Jan 2022
    This issue appears to reflect the current state of things but doesn't go into much detail:
  • State of Valhalla: Part 1: The Road to Valhalla
    1 project | | 9 Jan 2022
    What does this mean? Say you have a sort algorithm that only promises to give you a la sorted array. If you implementation happens to be stable (maybe in only some cases when it's optimal, or maybe only now) it might be convenient to have the algorithm shuffle the array around before sorting for small enough inputs (or when testing) so users don't become dependent on sorting being stable when your never promised that. So this code goes out of the way to break assumptions. And whenever you see users making code that depends on the assumptions you do a "non breaking change" that breaks these users when the group is still small enough you can get away with it.
  • Saving a Third of Our Memory by Re-Ordering Go Struct Fields
    8 projects | | 9 Jan 2022

    > It seems fine to me for the spec not to guarantee anything about struct field order in memory. The spec doesn't operate at that level.

    > That said, no Go compiler should probably ever reorder struct fields. That seems like it is trying to solve a 1970s problem, namely packing structs to use as little space as possible. The 2010s problem is to put related fields near each other to reduce cache misses, and (unlike the 1970s problem) there is no obvious way for the compiler to pick an optimal solution. A compiler that takes that control away from the programmer is going to be that much less useful, and people will find better compilers.

    8 projects | | 9 Jan 2022
    But if I understand things correctly, go, the spec, doesn’t provide the developer a way to control field order. It’s only the (main) implementation that currently happens to keep field order matching the order in the source code.

    So, currently, there is no way to force memory layout, other than, as says

    “defining the type using [n]byte and modifying the fields using the encoding/binary package. On many processors the performance will be approximately the same.”

    Seems unsatisfactory to me.

What are some alternatives?

When comparing ply and go you can also consider the following projects:

Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies.

zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

TinyGo - Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.

golang-developer-roadmap - Roadmap to becoming a Go developer in 2020

RxGo - Reactive Extensions for the Go language.

gin-vue-admin - 基于vite+vue3+gin搭建的开发基础平台(已完成setup语法糖版本),集成jwt鉴权,权限管理,动态路由,分页封装,多点登录拦截,资源权限,上传下载,代码生成器,表单生成器等开发必备功能,五分钟一套CURD前后端代码。

Weaviate - Weaviate is a cloud-native, modular, real-time vector search engine

Gin - Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.

sqlc - Generate type-safe code from SQL

asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more

crystal - The Crystal Programming Language