go-sumtype
Vale
go-sumtype | Vale | |
---|---|---|
11 | 64 | |
403 | 1,677 | |
- | 1.9% | |
0.0 | 6.8 | |
about 1 year ago | about 2 months ago | |
Go | Scala | |
The Unlicense | Apache License 2.0 |
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.
go-sumtype
-
Small sum types in Golang
I find this implementation to be quite minimal and less clumsy than alternatives. Sure, you don't get nice exhaustive pattern matching. Also, type inference gets in the way when instantiating UserKey (though you can wrap it in constructor functions). But expressing your intent using types still makes your code much more convenient and easier to understand.
-
Switching from C++ to Rust
The call out to sum types is something I feel. I've been using Rust daily for almost 10 years now, and sum types are absolutely still one of the things I love most about it. It's easily one of the things I miss the most in other languages. I'm usually a proponent of "using languages as they're intended," but I missed exhaustiveness checking so much that I ported a version of it to Go[1] as a sort of lint.
[1]: https://github.com/BurntSushi/go-sumtype
-
Rusty enums in Go
A Google search for golang sum types currently shows my project as a second hit: https://github.com/BurntSushi/go-sumtype
-
Carbon Language: An experimental successor to C++
I've been writing Go and Rust nearly daily for about a decade now (Go is more than a decade, Rust is about 8 years). You are not going to teach me anything about the pros and cons of either language in a reddit comment. I do not need to be taught about the "iota mess" when I've written tooling for exhaustiveness checking in Go.
-
a go linter to check switch statements for default
https://github.com/BurntSushi/go-sumtype forces exhaustive type switches for interfaces specifically annotated to need that.
-
Go: Making state explicit using the type system
We can fix these two problems by relying on static analyzers such as go-sumtypes
-
Hacking sum types with Go generics
See also https://github.com/BurntSushi/go-sumtype
- What I'd like to see in Go 2.0
-
Upcoming Features in Go 1.18
go-sumtype[0] has completeness checking for sealed interfaces.
[0] https://github.com/BurntSushi/go-sumtype
-
I want enum more than generics
Pretty easy to achieve outside of the compiler: https://github.com/BurntSushi/go-sumtype
Vale
-
Vala Programming Language
Not to be confused with Vale[0].
[0] https://vale.dev/
-
Is Something Bugging You?
The article says they created a deterministic hypervisor that runs all pseudorandom behavior from a starting seed to enable perfect re-playability.
But that's all we know so far. I'm assuming there'll be some sort of fuzz testing, and static analysis or some defining actions that your software can perform.
Honestly it sounds a lot like it has a lot of crossover with what the Vale language is trying to solve: https://vale.dev/, but focused on trying to get existing software to that state instead of creating a new language to make new software already be at that state by default.
- Odin Programming Language
-
D Programming Language
Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.
Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/
- The Vale Programming Language
-
Flawless – Durable execution engine for Rust
Another relevant language might be Vale (https://vale.dev), which is aiming for "perfect replayability": https://verdagon.dev/blog/perfect-replayability-prototyped
-
Two Stories for "What Is CHERI?"
Interesting. Very low level though and C(++) centric. She there any thoughts on combining the hardware and OS features with rust or https://vale.dev ?
- Berry is a ultra-lightweight dynamically typed embedded scripting language
-
I've heard that "Rust's borrow checker is necessary to ensure memory safety without a GC" usually also implying it's the only way, but I've done the same without the borrow checker. Am I just clueless/confused?
Use a runtime memory management solution that's cheaper than garbage collection (see Vale)
-
Vale.sh – A Linter for Prose
This seems like a tool I'll be using, and this is an almost meaningless criticism, but why the name?
There's already the Vale programming language (https://vale.dev/), but moreover, I don't get the meaning of "vale". You could call it something like Englint which actually hints its purpose.
What are some alternatives?
go101 - An up-to-date (unofficial) knowledge base for Go programming self learning
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
enumer - A Go tool to auto generate methods for your enums
Odin - Odin Programming Language
go - The Go programming language
Beef - Beef Programming Language
hylo - The Hylo programming language
awesome-low-level-programming-languages - A curated list of low level programming languages (i.e. suitable for OS and game programming)
crubit
carbon-lang - Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
mo - 🦄 Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
awesome-programming-languages - The list of an awesome programming languages that you might be interested in