Go: 1 Thing I Would Change
ฝัง
- เผยแพร่เมื่อ 17 ส.ค. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Thank you for the support!!!!!
Sponsored by Boot.dev: Learn backend development in Python and Go on boot.dev
Use code PRIMEAGEN for 25% off first payment
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - วิทยาศาสตร์และเทคโนโลยี
Before i watch: enums i want enums
YES i was right, go’s specific choice to leave out proper enums I will never understand or forgive
And pattern matching
iota? why iota use another fucking language
@@irfanfauzi8704 yes!!
There's a reason for leaving out enums though (I also haven't watched the video yet)
In a language with real closed enums, there's no way to add a new value to an existing enum with a lot of uses through a large codebase. You have to rely on documentation to tell people to always include a default: when they pattern match on your enum, or resort to hacks like __DONT_MATCH_ON_THIS_VALUE as one of your enum values, if you know you want to be able to extend in the future.
Go takes the position that enums should be extensible by default. This means the compiler can't check for exhaustive switch statements by design.
just something about type aliases
type Color int is literally a new type. type Color = int is a type alias. In the first case it can have methods. In the second case it's plain int.
if we have
type Color int
and we have
var x Color
you can not put every integer inside x
you have to convert it to color
like so
x = Color(someIntVal)
in the second case: type Color = int
yes, you can put every integer inside a variable of that type
but one might ask, why in the first case (with type Color int) I can write x = 10? despite the fact we defined x as var x Color
the reason is, here 10 is NOT an integer. it is a numeric literal. it gets its type from its usage - if we use it as float64, it becomes float64
Go is such a chad language. Finishes work early, go grab drinks and enjoy life.
Everybody else dancing with cannot borrow as mutable because it is also borrowed as a donkey.
The issue with generics in go wasn't that I wanted to use them myself, but that their absence COMPLETELY FUCKED UP APIs provided by the go standard library like sync.Pools.
ikr. they've basically just recreated the same conditions that led to modern java.
@@raianmr2843 that aint modern java bro, modern java is sealed interfaces with switch expression pattern matching (yes, java has sum types, hello), but if we are talking about generics, modern java isnt out yet even (see project valhalla)
This is exactly what I commented on another video, enums is the feature I miss the most in Go. It would make the language so much better and even allow for better error handling. Sometimes I think the Go creators went too extreme down the 'simplicity' path.
7:55 Quite frankly, you will notice that using tabs for indentation is better than spaces as soon as you start to work with programmers with sight disabilities (that aren't colour weaknesses).
I think tabs would be more popular if it wasn't a width of 8 spaces by default (I understand there's history here but whatever). w/ an editorconfig it doesn't matter but seeing it in the web without tab-size configured is very, very jarring, especially with 2-4 spaces being most common nowadays
@@cowslaw tbf, I normally configure it to 8 width anyway
@@kuhluhOG average tab user
@@cowslaw It's nicer on the eyes in the long term
Just need more tooling that just flips to tabs during builds, compiles, or commits, like how git will do line-feeds with very little effort.
If it's not on my work surface I don't care if it's tabs or spaces.
Like when doing web-dev two spaces is ideal to keep things from going offscreen.
tab indentation just gets to be too much even when doing things like giving element attributes their own line.
I'm pretty sure somebody using Go have considered some variant of the visitor pattern, so I'm curious on how it goes along with Go. Something like (typescript):
interface ColorMatcher {
onRed(): T
onBlue(): T
onGreen(): T
}
interface Color {
match(m: ColorMatcher): T
}
I mean, you could also use Git repos as dependencies with Cargo-they are compiled with your code statically anyway.
NPM is a bit flakier, if the repo doesn't contain pre-built JS files, because source code would need to be bundled/transpiled/compiled with all sorts of toolsets and scripts before you can consume it. At that point you may as well self-host an NPM registry.
When I first saw how Go does enums I thought it was a joke. It's like the moment you learn there's actually a language called Brainfuck.
Whenever I get interested in learning the language I just google how to solve a specific problem in it and see a code snippet that just makes me scratch my head and then go "nah I'm good".
Go enums feel very similar to enums in C, but without a keyword. In C (not C++), enums are also just named integer constants and provide no safety.
@@alexanderdaum8053 Yes, but at least their syntax is consistent with the rest of the language and doesn't have a magic keyword called iota somewhere in the middle. If they want it to be just constants in a trenchcoat then they should at least commit to that.
My wish list in order
- Sum Types
- Fix error boilerplate
- Remove casing visibility
- Allow private file variable (aka c static)
- Simpler dev dependencies like Rust.
- Better C interop
basically odin minus the concurrency model
@@raianmr2843 really? Maybe i should check it out
Scala has sealed traits. This states that there can never be more implementations of the trait than the author intended. In the same way as rust enums, there is no need for a default case.
I used to hate case sensitive visibility. For me Go wanted to be implicit where I didn't want it to be(I consider Go as a language, which asks you to be explicit and I like that), but now I that I'm used to it, I appreciate it. I don't have to worry about if its private or protected and seeing whether I'm in the same package or a different one
But that's just the because it only provides two levels of visibility: public and private, not because its case sensitive. Replacing the case sensitive rule by a single keyword pub (but no protected keyword) for public identifiers would provide all the advantages in simplicity and just make it more explicit.
The name is Thegruggen
12:00 The typescript union type with the function foo and MyUnion is not crap. MyUnion as a type is a subset of the (number | string)[] type. If foo was a pure function, this would be perfectly valid to do. What am I missing?
number[] and (string | number)[] are different types. every language since the dawn of time has seen that.
the fact that you have to add conditions under which the programmer should program means that you have created a bad type system.
"if you would just program pure functional programs" - copium
myThing (number[]) ends up with a string in it "420". That's indeed quite crap.
@@ThePrimeTimeagenbut in typescript they're different, but one inherint from the other.
It doesn't seem like total crap to you because you're more used to structural typing. In TS's point of view, number[] is acceptable because it fulfils the (string | number)[] contract. But the only reason TS chose to be this way is because it's hosted on JS. This is essentially a type system compromise that almost no other typed language has to deal with.
I have not thought about it before, but maybe they could allow enum (proper or not) tagging for serialization like structs.
that is what _should_ happen
Iota is the "minimal syntax comptime" in go 😅.
Also writing a switch statements with a panic detonating by default is a sorry excuse for enum+match with lsp support.
I'm all about proper enums in Go, but iota has a particularly valid use case: bitflags. You can bitshift an iota on the first line of a const block and all subsequent consts in the block automatically repeat the bitshift, which makes runtime bitwise comparisons *really* easy to manage.
For enum serialisation, numbers are nice for protobufs, but strings are better for json.
Of course protobufs are usually better than json anyway, but one thing I hate is using a json api or reading an openapi spec where it tells me the possible values are 1, 2, 3.
If you use numbers you also have to be careful with versioning. Protobuf is versioned anyway but json is usually backwards compatible and changing an enum with auto incrementing numbers can break things. Semantic versioning and explicit numbers help here, as well as just not making the breaking changes if you don't have to, but I have seen it catch people out.
Tagged unions is exactly what I'm missing in Go, especially in error handling, and also the greatest strength of Rust. Just looking at everything else I'd choose Go over Rust 99% of the time but damn, I want my enums...
@13:13 If any element can bo number of string so any type of array wich contains numebers or string should pass.
However i can agree that should be possible to do some restrictions, but as i know TypeScript has analogue to Rust Where ?
Go has no proper data structures algorithms on std, that's not really less = better (cuz simple). It's just less = incomplete, so you do the rest.
I fail to see this as an advantage of go, even tho a vast majority of the people praise this and other aspects as go's shining simplicity.
This becomes so painfully obvious when doing leetcode exercises, true, they don't really truly represent real world, but it does display core weaknesses.
The language remains simple, but as the code grows more complex, the simplicity just creates more complex code again
i am unsure if i purchase this as truth that because go isn't the best leetcode program means that hidden complexity grows. go has a weakness, rust has weaknesses, typescript has weaknesses
You don't like container/heap 😭😔
Go's syntax is so simple, C has better error handling once you write a couple macros. As for the article itself... I don't know Go, never used it, but at three minutes in this just sounds like the author is selfish. Sure, his application code doesn't need generics, but I'm sure there are many developers writing libraries, some of which he uses, who appreciate having generics. Why did Go only introduce max() in 1.21? Because you can't do it sanely in a statically typed language without generics.
I am selfish.
@@wagslane and that's good. We all need to be, to a degree. I do agree with you that simplicity beats complexity, just disagree as to what kinds of complexity are necessary, or maybe just exceptions to the rule. Generics, simple generics, not something crazy like C++ has, are in my mind a necessary feature of statically typed languages.
Python suffers from a similar issue in terms of mutating generalized types. They "solved" it introducing a distinction between covariant and contravariant type parameters. Imho the real answer is to allow your language to specify immutable arguments, that way you don't have to worry about a generalized functions pushing incorrect items into it. Also ts doesn't have a "isinstance" function, which complicates things
- Sum types
- try ( zig ) or ? ( rust )
optionally pub keyboard and I will ditch rust instantly
how does JSON.parse resulting in any is making string unions unsafe? It does suck, but it is totally another issue
I'd much prefer proper enums than unions. In the given example it makes complete sense, but what if you want to use ints to represent a colour instead. At that point you have to communicate elsewhere (I guess a comment would do it) that 0 = red, 1 = green and 2 = blue
rust does both with same enum syntax, since enums are tagged values you just assign which number is the tag after the equals sign
... don't all decodings have to do runtime checks somewhere? The thing with Typescript is that you don't get language/library support for that check for free (developer effort).
I am currently writing a language server in Go, and the lack of sum types makes the LSP protocol super annoying to work with. There's so much runtime reflection going on and I hate it. If Go had sum types, it would almost be my perfect language.
(1.) Snatching *_victory_* from the jaws of *_defeat_* .
*** vs ***
(2.) Snatching _DeFeAt_ from the jaws of _ViCtOrY_ (!?)
What are your thoughts about crystal? is it easy and logical and nice like go? could it become golangs rival in its domain?
Type unions is something I really miss when using go
I would really love a video on setting up project with golang, Like how to setup PATH variables when working with different directories with different projects, where to install the deps for each project. I was learning golang, and had to stop becoz of this fuck, Becoz i could not understand where my modules went and which modules have been installed.
Its not true that "type Color int" makes a type alias. That would be "type Color = int"
"type Color int" does really make a new type. Thats why "Color(5) + int(5)" is a compile error
That's true, but what I meant was the definition of the type really is the same. It's still all ints
It's definitely a leaky abstraction. Go will let you add two Colors just fine 😅
i really enjoy backspacing 4 times to get rid of a fake tab
literally my favorite part of programming
it's a shame modern editors can remove all 4 with one keypress. only 1/4 the fun!
I definitely agree with the article
Go is awesome to build tools and build everything, easy and already many great native libs
TLDR: "new" types are just type conversions.
Not sure, but there might be some tension between enums and something in go's fundamental design: untyped constants.
User defined and even some basic types are type interfaces with a builtin type under the hood (boolean / numeric / etc)
The builtin types are the only ones with a specified set of valid "untyped" constants.
Developers are allowed to explicitly convert these constants into custom types, but *creating* untyped constants at compilation which true enums would require, were probably not in the conversation for the spec. (Not sure if something like that is possible, maybe there exists a workaround with generation, never tried)
Preventing hidden implicit conversions was the main goal, and go accomplishes that.
No comptime was a deliberate decision.
He is missing how go leverages its strategy of everything has default values (except maps which you also hate) type alias + iota sucks but it does enforce the idea that go types are simple memory models and always can be initialized with a zero state
Tabs ARE consistent whitespace.
Well there's hope for Go version 2 to do this lol
Even PHP has successfully implemented enums, better than typescript and go. In PHP enums are just a class that can have its own methods, traits, more like a struct in Go.
One of the best things C++ added to C was enum classes for sure.
Enum classes, std::array, vector, and string, namespaces for god's sake! Hot take: you should never program in C. Namespaces ALONE is enough of a reason to choose C++. If you don't like all the other stuff C++ brings to the table then don't use it.
@@lucass8119Damn chill out lol. For low level purposes (embedded, os etc), C is still preferable in many cases. Most of C++’s additions aren’t useful in those environments and the rest aren’t worth the added complexity to the tooling
@@theoaway Its really not preferable, because even if you remove 99% of C++ there's still huge additions there.
Could you even begin to imagine how much cleaner the Linux source code would be if it utilized namespaces? No more confusing names!
Or enum classes. They're literally just C enums but... typesafe and readable. Just a direct upgrade.
There is exactly one reason only to still develop in C: interop. C binds to other languages with very little effort because its the super old standard. This is why GTK has bindings for everything under the sun and Qt has... python only.
@@lucass8119 I’m glad you brought up the ABI, because that’s only one part of the portability issue which is where C wins every time. C is much simpler than C++ and the language spec is far less ambiguous, so you get far more portability and flexibility across different compilers. This is especially important for more obscure hardware where there is likely no reliable C++ compiler, if one even exists in the first place. This is a big drawback especially for memory constrained environments where you’ll basically just be writing C anyway with a few additions. The tradeoff just isn’t worth it for many, especially since a lot of your arguments are about readability which is very subjective. You personally might find the linux kernel more readable if it were to use namespaces, but many kernel developers would be less than thrilled.
@@theoaway I think the kernel developers would be less than thrilled, because of the negative associations with C++. But the thing is people hack together C++ solutions in C all the time, using macros. Its incredibly unsafe and error-prone, but they still do it.
Going back to GTK, they have an entire object system written in C macros. It's not a stretch to say that is MUCH less readable than simply using a language that includes those features, namely C++.
In fact for GTK it was SO unreadable they implemented their own language, Vala, as a wrapper around their C OO system.
It seems to me most complex C systems long for the features of C++ but refuse to adopt it. Instead, they opt for implementing generic data structures with macros (C++ templates), polymorphism with void pointers as struct member (C++ virtual), inheritance with Macros, and on and on.
It's all very perplexing to me. Surely C is a simple language. And yet, it is used and abused with hacks just to achieve simple built-in features of C++. And the cost is great. Debugging is now SO much harder, because your source code changes without you knowing through macro abuse. Side effects happen when you can't see them, objects inject themselves into scopes when there's no assignments, simple function calls can fail with a seg fault.
For me, I would change the surrounding libraries. I think one of the things that makes JavaScript as powerful as it is now is that it's libraries are extremely simple.
Yes maybe that does mean giving the developer less options, but more often than not you don't need as many options as you get with 3rd party Go libraries.
Are you trolling?
@@nikanikasept you don't know how much bs each function provides because of the shit docs right? Yeah I would want to change that asw
case sensitivity is the bully of the text formatting world, and another shin kicker for new learners, or end users of systems that adopt that specificity over humanity.
It's too easy in many languages to make a simple typo mistake that gives no feedback leading to inscrutable bug hunting.
case sensitivity requirements should be behind a STRICT flag , keywords or strict compares ( 'error' !== 'Error')
In loose mode build/compile remind you things are loose, or just linters whine about some convention.
casing/formatting/linting should be encouraged as a finishing process, not a forced position during the forging.
Oh, I just wish to have rust enuns and pattern matching, but it totally against goway
Personally, I don't see enums as types. I see them as numeric literals. I mean, it's in the word. To *enumerate* a set of things is to assign numbers to them. The real crux of his argument is that Go doesn't have *sets.*
That makes more sense to me. It bugs me that people ask for some kind of concept that is not enumerating, but a definition of a set with its possible values. And they have an audacity to call it "real enums", go has real enums.
Go is missing immutability. Anyone can change a pointer struct field within function encouraging side effects
So what? Mutability is not bad, only Rust and Haskell coomers think that
I don't wanna be the "well, akshually" dude, but...
Aksually, the problem with the typescript function that you showed was not in the union type, but in the JSON.parse function, because it returns any and essentially disabled type-checking. Don't get me wrong, it still sucks, but it sucks for a different reason.
you don't have to use JSON.parse to get the issue
you can just const a: number[] foo = [1, 2, 3]; and then pass it into a (number | string)[] function
on top of that, JSON.parse just makes everything much harder
@@ThePrimeTimeagen Yeah, the (number | string)[] example is really good to showcase that.
You're missing the point. JSON.parse shouldn't return *any*, it should be *unknown* instead. TS has many such escape hatches to silently turn off the type checker or even develop false deductions. If you don't consider these to be the flaws of a typed language then I don't know what to say to you.
@@raianmr2843 I agree that JSON.parse, as well as the .json method from the fetch response, should all return unknown instead of any.
I'm #1 wise grug fan as an un-wise young grug
You know.. If they would just take a look at an ML Lang.. Fsharp and Ocaml for the win.
Poor filp😂
I feel for you man 😅
What do we want?? FLIP HAVING ENOUGH MONEY TO EAT!!! When do we want it??
i’ve only eaten bushs baked beans (the kind with the little bacon bits) for the last 3 months
LSP tells you what each value is in the iota
color #3 exists, and it's name's alpha
You did an ad but it's good content so it's ok 😊
i thought it was too
Null safety. How can you even treat it seriously if a language made after the 90's doesn't have null safety. Crazy and insane.
Its not null its nill höhöhöhöhöh
I kid.
5:47 Well, this is *not even a **_Vim_** thing.*
The lack of `max` is enough reason to include generics, IMO
Just be cautious to not overuse Generics, or let it be used in libraries.
Data Structures are great, interface{} is horrendous for the type of value stored.
All programmers ask for the same thing without necessarily knowing it: Évariste Galois' math !
When you have it, you finally know what you're doing. And as long as the language don't let you have it, you're screwed.
What?
@@GrantGryczan
- en.wikipedia.org/wiki/%C3%89variste_Galois
- en.wikipedia.org/wiki/Group_theory
Easy and crystal clear management of *composable groups* and automated reduction at compilation is all you need from a programming language. Everything else is whim.
Soy Dev Here (I use React(JS) & Angular(TS) at work).
My question is :---> why I didn't find anything wrong with JS/TS?
@ThePrimeTime After using expressive languages, like Rust, aren't you annoyed with all those flaws in Go design - poor expressiveness (no expressions, statements only); lack of first-class support for your collections (you can't use make() or for .. range for your own-created collections); and half-implemented language abstractions with ends "sticking out" (like when you have to care about new reference returned from append(), when mass of other languages just care of such things on its own)?..
100% Agree. I love Go but I hate the way you do enums in Go...
What about the absolutely insane way they format dates in go?
Unique is not equal to insane. I programmed a CDC Cyber-170 mainframe and had to remember to "rewind" my source code files after each compile before I could edit them. This was unique but not insane.
The issue is one false move and the language is "ruined"~ endless nitpicking for eternity
ooh, sponsorships!
I don't understand why some programming languages don't have enums... I mean I *sorta* get how you could consider them a bit unnecessary like syntactic sugar for very dynamic languages especially, but still. If you've implemented classes in your language, you're not reaching very far to also add enums...
Also, I am offended that go would include iota and not enums. Because iota is 100% syntactic sugar, but that's somehow more valid to include than enums...
In these comments: hateful rust elves with no go experience
I didn't understood your last comment in typescript
go does not need to do union types once you understand interfaces
Before I watch: they’ll fix it in Go 2 don’t worry.
"We do not want to break the ecosystem. Go 1 and Go 2 code must be able to interoperate in programs with ease."
10:31 me currently trying to set up river instead of sway with voidlinux ;-; (WHY DOESN'T IT WORK DARNIT)
This is not the worst one though. The worst are putting backticked strings in struct fields which are used for json serialization and deserialization. There is no safety at all. It may also not give errors on runtime and you have to double triple check if your serialization or deserialization works as expected because go will assign zero value to that field if it cannot find during deserialization from json to go struct.
I cannot really understand why Go is so much celebrated. It has also many footguns but no one tells. Interface type is one of famous footguns you have to use many times.
Probably Go isn't absolutely pounded into the ground over its foot guns because everyone who loves it (which is likely 90% of the people who use it) come from C. Now, I'm new to programming in general, but C is already famous to me for being a foot cannon. Or perhaps an entire leg cannon, if you're feeling particularly adventurous.
Simplicity, speed, no BS. It feels like a relatively simple high-level language that executes as fast as a low-level language. Maybe that's why it is praised.
Better, less verbose error handling, obviously
The typescript one makes sense though? You’re basically pushing to an array that can either have number or string (number | string)[] as opposed to (number[] | string[]) (which probably equates to never) so why would it throw a warning when you pass it a number array?
I’d say the more appropriate solution that would be more inline to how other languages works is to use generics and add constraints to either number or string arrays, but then again, typescript don’t have proper types XD (generics aren’t runtime) - there are some workarounds like type guards or using class wrappers for the specific code that you wrote, but at that point, i’d rather just invert the argument so that it accepts the primitive instead which could be type checked and casted to the proper type before pushing.
Also for json parse, there are libraries out there like zod that should be used literally for anything with an any data type (ex: http requests) (Would be good if it was built in tho). This basically allows you to define the schema of what you expect the data to be, and throw an error otherwise, just like a proper serializer.
Also, the casing thing for go is one of the worse decisions I’ve ever seen XD, kills me every time I have to write them.
it doesn't make sense
no amount of copium makes sense. number[] and (number | string)[] are two different types. plain and simple
You kinda can-ish lol - dotnet for example
typeof(List).IsAssignableFrom(typeof(List)) this would work but not using "is" (so basically runtime still but ey)
But yeah I do agree I wish the type system could be better, more strict and more intuitive, but ey, still better than JS XD
Besides once you kinda get used to the fact that TS basically treats them as a subtype of the union instead of as another type, it's not bad. Feels icky tho when you're in a position where you need to jump between languages.
I honestly can't believe python has better typing than TS now lol
List[Union[int, str]] != List[int]
@@cpuccinothat doesn't work? List is invariant over T. IEnumerable for example _is_ covariant because it only supports reads and not writes. In general, any datatype supporting both reads and writes should invariant, so widening number[] -> (number | string)[] shouldn't possible, but number[] -> ReadonlyArray -> ReadonlyArray should be.
Oh yeah nice catch, forgot about that.
@@ThePrimeTimeagen In typescript
(number | string)[] is a array of string or number, number[] pass that validation
if you wanna make that only you can pass a full array of string or full array of number do this:
```ts
const a: (number | string)[] = [1, 2, 3, "sd"];
function example(arg: string[] | number[]) {}
// Argument of type '(string | number)[]' is not assignable to parameter of type 'string[] | number[]'
example(a);
```
This will error!!!
I agree that Go needs sum types, but he's wrong about iota.
I guess I can see where they're coming from if they only use it for this poor excuse of an enum, but it is actually useful.
First, you use iota when you don't really care what the value is, but you need a value anyway.
This would be the same with an actual sum type; you don't care how it's represented, you just want a value.
Second, you can use it with other operators.
A simple example is defining bitflags, such as:
const (
Foo MyType = 1
agreed. it's great for defining flags and stuff. the entire point of iota is you can't care about the actual number it is (e.g. serialize it). if you want the max number for validation add something unexported to the bottom of the iota. this being said i 100% agree Go needs sum types.
You're missing the point. It's like saying C++'s switch construct is great because it lets you do this this and this when Rust's match expression is clearly a better designed and safer construct. Iota is a subpar excuse that only exists because Go lacks a straight forward means for compile time code execution. These issues aren't noticeable to people who've only written code in the language being criticized. In languages like Rust and Zig you don't *need* iota to achieve this. Iota sticks out like a sore thumb in Go's attempt to be a language with a finite set of universally applicable constructs with more than one use, which is ironic because this is the same point they bring forward when dismissing worthwhile proposals to the language from the community.
I'm not missing the point, but thanks
Odin = Go - GC + Enums + [...]
Minus great concurrency :D
Couldn't you create a .Valid() function for your custom type and call it instead of writing the switch case at consumer code?
That doesn't get us compile time warnings :(
Tabs over spaces, bro. I gotta side with Richard on this one:
th-cam.com/video/SsoOG6ZeyUI/w-d-xo.html
The extra dig at Vim was just a bonus.
Wait a sec....this seemed like an ad.....
WAIT A SECOND
I really don't agree that Go can be Rust. Simple things like accessing a Go built in map concurrently from multiple goroutines will cause a program to crash due to a data race. Alos before generics, you couldn't implement a threadsafe (and typesafe) map yourself at all so you had to wrap access to a regular map in a mutex any time you wanted to access it concurrently. If you forget, program crashes.
If all your problems are really simple, Go is great and will carry you well. Once complexity increases past a certain threshold, Go will drop you onto the ground.
yeah.. im grug developer for sure!
I'd change it to C
PHP has great enums. It's embarrassing...
But that's recent addition to language.
@@GreyDeathVaccine So what?
Gotuber
When people claim to be on board with "grug brain" and then ask for more complicated type systems for simple stuff that go:generate and go linters already have well-covered, or complain about AMAZING grug-brained features like iota and case-sensitive visibility, I have no idea what they mean by "grug brain". I don't think you guys understand what simplicity means.
Java has nice enums
I'm using Go 1.20 and the article seems either outdated or full of crap.
Go will not let you compile the following code, so "type" definitions are not just a simple alias. They are indeed checked.
package main
type Color uint8
const (
Red Color = iota
Green
Blue
)
const NotAColor uint8 = 128;
func giveMeAColor(c Color) {}
func main() {
giveMeAColor(Red);
giveMeAColor(NotAColor); //
There seems to be a misunderstanding. Go has types *and* literals. Your version of the code throws an error whereas this will gladly be accepted by the compiler:
package main
type Color uint8
const (
Red Color = iota
Green
Blue
)
const NotAColor uint8 = 128
func giveMeAColor(c Color) {}
func main() {
giveMeAColor(Red)
giveMeAColor(128) //
@@raianmr2843 Good point, I did not think of that, since the point of Enums would be to not input raw values.
I guess you could combine the approach of not using iota to define the enumeration.
And then make the function parameter a pointer, that way you cant put in literals and the compiler still can handle the type checking.
Not ideal, but far of from the mess and huge overhead, that the article describes.
package main
type Color uint8
var (
Red Color = 1
Green Color = 2
Blue Color = 3
)
var NotAColor uint8 = 128;
func giveMeAColor(c *Color) { }
func main() {
giveMeAColor(&Red);
giveMeAColor(&NotAColor); // Throws error as before
giveMeAColor(128); // also throw error, since you cant take the adress of litteral like that
}
Brother in Christ
number[ ] | string[ ]
i hear you, but that isn't always an option.
have you ever worked with a type that is a union of several other events, `Event`.
the next thing you know your LogEvent array has a VideoFrameDecodeEvent in it. much sadge
@@ThePrimeTimeagen Nah I know the pain man, just messin around and pumping the algo fo ma boi
@@ThePrimeTimeagenyou can create a utility type for that, never worry again.
@@ThePrimeTimeagen but from the function's perspective, there's nothing wrong with this except not being able to optimize.
if the function is making the requirement that the param should be any array that includes strings or numbers and a caller passes in an array exclusively with numbers , from the function's perspective it was already going to have a logic fork if it did anything specific on those types.
this makes sense in javascript to me.
in rust of course i would expect these types to be completely different types. and you would also have guarantees as the caller in rust about mutation. but since typescript has no such mutation guarantees, and many other reasons you know of, typescript will never be rust. and that's definitely okay
for example , this TS function changes dramatically with slightly different function signature
ex.1
const foo = (args: (number | string)[]): (number | string)[] => {...}
ex.2
const foo = (args: readonly (number | string)[]): (number | string)[] => {...}
the former implying that this function might add a string into the caller's Array
I would change err != nil
2 things:
iota can be incremented by more than just 1. Want to increment by 2? Use iota * 2. Want to increment by 3? Use iota * 3, etc.
Finally, to avoid boilerplate of writing String() method for your constants, use the stringer library from go-tools and go generate, will take care of the rest.
two subpar ways go devs are meant to cope with the lack of comptime 😂
ads let's goooooooooooooooo
Tabs are better, especially when going down 8 steps at a time.
I hate iota. Imagine you have an error in production and you have value "7". Then you have to mentally count all enums to figure out what constant has value 7. So I'm always explicit and don't use iota.
There's a reason for leaving out enums though
In a language with real closed enums, there's no way to add a new value to an existing enum with a lot of uses through a large codebase. You have to rely on documentation to tell people to always include a default: when they pattern match on your enum, or resort to hacks like __DONT_MATCH_ON_THIS_VALUE as one of your enum values, if you know you want to be able to extend in the future.
Go takes the position that enums should be extensible by default. This means the compiler can't check for exhaustive switch statements by design.
I disagree with this. With closed enums and exhaustiveness checking, you have the option for whether or not you want to use that feature. If I'm matching/switching on an enum, then I want to handle each case explicitly, and if a new option is added to the enum later, I do not want the program to compile until I've gone and handled this new case. In most of my use cases, the program has a bug if I don't do this, and so I need the compiler to tell me where to go and handle these new cases. If there's a situation where I don't want this exhaustiveness checking, then I can just use an if statement.
In a language with a good type system, compiler errors are not a burden. They're a tool. It really is a great feeling when you can make a change, fly around the code base like a caveman squashing all the resulting errors, and the result just works.
just have something like struct embedding for this hypothetical union type. that kind of weird and misleading extensibility was the main reason they left out inheritance and chose embedding for implementation sharing.
JVM lamguages did enums the best
Change the gopher
Definitely top three:
* ADTs
* No Nil
* No zero values
c# enums ==
I don’t get your point about ts union types at all. Decoding from json will be unsafe even in rust, no? Sure the error type is far better than a try catch, but still, these unions are a lot better than raw strings. I absolutely can’t see how they would hurt