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
  • วิทยาศาสตร์และเทคโนโลยี

ความคิดเห็น • 199

  • @cowslaw
    @cowslaw 10 หลายเดือนก่อน +169

    Before i watch: enums i want enums

    • @cowslaw
      @cowslaw 10 หลายเดือนก่อน +27

      YES i was right, go’s specific choice to leave out proper enums I will never understand or forgive

    • @irfanfauzi8704
      @irfanfauzi8704 10 หลายเดือนก่อน +8

      And pattern matching

    • @cowslaw
      @cowslaw 10 หลายเดือนก่อน

      iota? why iota use another fucking language

    • @cowslaw
      @cowslaw 10 หลายเดือนก่อน

      @@irfanfauzi8704 yes!!

    • @rosehogenson1398
      @rosehogenson1398 10 หลายเดือนก่อน +3

      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.

  • @dc0d
    @dc0d 10 หลายเดือนก่อน +13

    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

  • @Deagle2751
    @Deagle2751 10 หลายเดือนก่อน +21

    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.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน +2

      ikr. they've basically just recreated the same conditions that led to modern java.

    • @CYXXYC
      @CYXXYC 10 หลายเดือนก่อน

      @@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)

  • @diego.almeida
    @diego.almeida 10 หลายเดือนก่อน +29

    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.

  • @kuhluhOG
    @kuhluhOG 10 หลายเดือนก่อน +39

    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).

    • @cowslaw
      @cowslaw 10 หลายเดือนก่อน +17

      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

    • @kuhluhOG
      @kuhluhOG 10 หลายเดือนก่อน +1

      @@cowslaw tbf, I normally configure it to 8 width anyway

    • @cowslaw
      @cowslaw 10 หลายเดือนก่อน +1

      @@kuhluhOG average tab user

    • @kuhluhOG
      @kuhluhOG 10 หลายเดือนก่อน

      @@cowslaw It's nicer on the eyes in the long term

    • @TheNewton
      @TheNewton 10 หลายเดือนก่อน +2

      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.

  • @ThePandaGuitar
    @ThePandaGuitar 2 หลายเดือนก่อน +3

    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.

  • @llIlllIIlIIlllIlllIl
    @llIlllIIlIIlllIlllIl 10 หลายเดือนก่อน +3

    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
    }

  • @dealloc
    @dealloc 10 หลายเดือนก่อน +19

    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.

  • @SaHaRaSquad
    @SaHaRaSquad 10 หลายเดือนก่อน +9

    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".

    • @alexanderdaum8053
      @alexanderdaum8053 10 หลายเดือนก่อน +2

      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.

    • @SaHaRaSquad
      @SaHaRaSquad 10 หลายเดือนก่อน +1

      @@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.

  • @akshay-kumar-007
    @akshay-kumar-007 10 หลายเดือนก่อน +40

    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

    • @alexanderdaum8053
      @alexanderdaum8053 10 หลายเดือนก่อน +8

      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.

  • @asdqwe4427
    @asdqwe4427 10 หลายเดือนก่อน +4

    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.

  • @lukaszmatuszewski
    @lukaszmatuszewski 10 หลายเดือนก่อน +1

    I have not thought about it before, but maybe they could allow enum (proper or not) tagging for serialization like structs.

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน +1

      that is what _should_ happen

  • @metaltyphoon
    @metaltyphoon 10 หลายเดือนก่อน +14

    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

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน

      basically odin minus the concurrency model

    • @metaltyphoon
      @metaltyphoon 10 หลายเดือนก่อน

      @@raianmr2843 really? Maybe i should check it out

  • @withmarko
    @withmarko 10 หลายเดือนก่อน

    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?

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน +5

      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

    • @joelie83
      @joelie83 10 หลายเดือนก่อน +3

      myThing (number[]) ends up with a string in it "420". That's indeed quite crap.

    • @oscarljimenez5717
      @oscarljimenez5717 10 หลายเดือนก่อน

      @@ThePrimeTimeagenbut in typescript they're different, but one inherint from the other.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน

      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.

  • @AK-vx4dy
    @AK-vx4dy 10 หลายเดือนก่อน

    @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 ?

  • @vorant94
    @vorant94 10 หลายเดือนก่อน +1

    how does JSON.parse resulting in any is making string unions unsafe? It does suck, but it is totally another issue

  • @0dsteel
    @0dsteel 10 หลายเดือนก่อน +1

    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.

  • @Diego-Garcia
    @Diego-Garcia 10 หลายเดือนก่อน +4

    The name is Thegruggen

  • @brentsaner
    @brentsaner 4 หลายเดือนก่อน

    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.

  • @kartikyt5367
    @kartikyt5367 9 หลายเดือนก่อน

    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.

  • @disguysn
    @disguysn 10 หลายเดือนก่อน

    ... 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).

  • @georgehelyar
    @georgehelyar 10 หลายเดือนก่อน

    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.

  • @recarsion
    @recarsion 9 หลายเดือนก่อน +2

    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...

  • @user-hk3ej4hk7m
    @user-hk3ej4hk7m 9 หลายเดือนก่อน

    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

  • @bigbodge
    @bigbodge 10 หลายเดือนก่อน

    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

    • @CYXXYC
      @CYXXYC 10 หลายเดือนก่อน

      rust does both with same enum syntax, since enums are tagged values you just assign which number is the tag after the equals sign

  • @GearsDatapacks
    @GearsDatapacks 10 หลายเดือนก่อน

    Type unions is something I really miss when using go

  • @stokedfool
    @stokedfool 10 หลายเดือนก่อน +1

    (1.) Snatching *_victory_* from the jaws of *_defeat_* .
    *** vs ***
    (2.) Snatching _DeFeAt_ from the jaws of _ViCtOrY_ (!?)

  • @raiguard
    @raiguard 10 หลายเดือนก่อน

    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.

  • @TechBuddy_
    @TechBuddy_ 10 หลายเดือนก่อน +1

    - Sum types
    - try ( zig ) or ? ( rust )
    optionally pub keyboard and I will ditch rust instantly

  • @FnordSho
    @FnordSho 9 หลายเดือนก่อน

    What are your thoughts about crystal? is it easy and logical and nice like go? could it become golangs rival in its domain?

  • @DreanPetruza
    @DreanPetruza 10 หลายเดือนก่อน

    Tabs ARE consistent whitespace.

  • @cyko5950
    @cyko5950 9 หลายเดือนก่อน +1

    i really enjoy backspacing 4 times to get rid of a fake tab
    literally my favorite part of programming

    • @angelcaru
      @angelcaru 3 หลายเดือนก่อน

      it's a shame modern editors can remove all 4 with one keypress. only 1/4 the fun!

  • @rosehogenson1398
    @rosehogenson1398 10 หลายเดือนก่อน +2

    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

    • @wagslane
      @wagslane 10 หลายเดือนก่อน

      That's true, but what I meant was the definition of the type really is the same. It's still all ints

    • @rosehogenson1398
      @rosehogenson1398 10 หลายเดือนก่อน +1

      It's definitely a leaky abstraction. Go will let you add two Colors just fine 😅

  • @amrojjeh
    @amrojjeh 10 หลายเดือนก่อน +1

    I definitely agree with the article

  • @cheebadigga4092
    @cheebadigga4092 9 หลายเดือนก่อน

    Well there's hope for Go version 2 to do this lol

  • @jaskij
    @jaskij 10 หลายเดือนก่อน +3

    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.

    • @wagslane
      @wagslane 10 หลายเดือนก่อน

      I am selfish.

    • @jaskij
      @jaskij 10 หลายเดือนก่อน +1

      @@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.

  • @DylanMatthewTurner
    @DylanMatthewTurner 10 หลายเดือนก่อน +2

    One of the best things C++ added to C was enum classes for sure.

    • @lucass8119
      @lucass8119 9 หลายเดือนก่อน

      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.

    • @theoaway
      @theoaway 9 หลายเดือนก่อน

      ⁠​⁠​⁠@@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

    • @lucass8119
      @lucass8119 9 หลายเดือนก่อน +1

      @@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.

    • @theoaway
      @theoaway 9 หลายเดือนก่อน

      @@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.

    • @lucass8119
      @lucass8119 9 หลายเดือนก่อน

      @@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.

  • @daltonyon
    @daltonyon 9 หลายเดือนก่อน

    Go is awesome to build tools and build everything, easy and already many great native libs

  • @onrir
    @onrir 10 หลายเดือนก่อน +6

    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.

    • @nikanikasept
      @nikanikasept 4 หลายเดือนก่อน

      Are you trolling?

    • @onrir
      @onrir 4 หลายเดือนก่อน

      @@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

  • @slpwrm
    @slpwrm 10 หลายเดือนก่อน +5

    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

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน +1

      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

    • @rosehogenson1398
      @rosehogenson1398 10 หลายเดือนก่อน

      You don't like container/heap 😭😔

  • @connormc711
    @connormc711 8 หลายเดือนก่อน

    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

  • @adrianorocha-dev
    @adrianorocha-dev 10 หลายเดือนก่อน +1

    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.

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน +3

      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

    • @adrianorocha-dev
      @adrianorocha-dev 10 หลายเดือนก่อน

      @@ThePrimeTimeagen Yeah, the (number | string)[] example is really good to showcase that.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน

      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.

    • @adrianorocha-dev
      @adrianorocha-dev 10 หลายเดือนก่อน

      @@raianmr2843 I agree that JSON.parse, as well as the .json method from the fetch response, should all return unknown instead of any.

  • @olamilekanadeleke6806
    @olamilekanadeleke6806 9 หลายเดือนก่อน

    Poor filp😂
    I feel for you man 😅

  • @terrencemoore8739
    @terrencemoore8739 10 หลายเดือนก่อน

    LSP tells you what each value is in the iota

  • @hsider
    @hsider 10 หลายเดือนก่อน +6

    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.

  • @lucas_badico
    @lucas_badico 10 หลายเดือนก่อน

    Oh, I just wish to have rust enuns and pattern matching, but it totally against goway

  • @SatinderSingh71
    @SatinderSingh71 10 หลายเดือนก่อน +4

    Go is missing immutability. Anyone can change a pointer struct field within function encouraging side effects

    • @user-ux2kk5vp7m
      @user-ux2kk5vp7m 8 หลายเดือนก่อน

      So what? Mutability is not bad, only Rust and Haskell coomers think that

  • @shakibrahman
    @shakibrahman 10 หลายเดือนก่อน

    I'm #1 wise grug fan as an un-wise young grug

  • @rudde7251
    @rudde7251 10 หลายเดือนก่อน

    What about the absolutely insane way they format dates in go?

    • @KevinInPhoenix
      @KevinInPhoenix 10 หลายเดือนก่อน

      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.

  • @0dsteel
    @0dsteel 10 หลายเดือนก่อน

    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.

  • @squrler
    @squrler 10 หลายเดือนก่อน +2

    What do we want?? FLIP HAVING ENOUGH MONEY TO EAT!!! When do we want it??

    • @flipmediaprod
      @flipmediaprod 10 หลายเดือนก่อน

      i’ve only eaten bushs baked beans (the kind with the little bacon bits) for the last 3 months

  • @emjizone
    @emjizone 10 หลายเดือนก่อน

    5:47 Well, this is *not even a **_Vim_** thing.*

  • @TalesMarinho
    @TalesMarinho 7 หลายเดือนก่อน

    I didn't understood your last comment in typescript

  • @DrorNir
    @DrorNir 10 หลายเดือนก่อน +2

    You did an ad but it's good content so it's ok 😊

  • @Relepega
    @Relepega 9 หลายเดือนก่อน

    color #3 exists, and it's name's alpha

  • @bitskit3476
    @bitskit3476 10 หลายเดือนก่อน +1

    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.*

    • @nikanikasept
      @nikanikasept 4 หลายเดือนก่อน

      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.

  • @WillEhrendreich
    @WillEhrendreich 10 หลายเดือนก่อน +1

    You know.. If they would just take a look at an ML Lang.. Fsharp and Ocaml for the win.

  • @disruptive_innovator
    @disruptive_innovator 10 หลายเดือนก่อน +1

    ooh, sponsorships!

  • @GiovanniCKC
    @GiovanniCKC 10 หลายเดือนก่อน

    10:31 me currently trying to set up river instead of sway with voidlinux ;-; (WHY DOESN'T IT WORK DARNIT)

  • @ManThermos
    @ManThermos 10 หลายเดือนก่อน +14

    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.

    • @AdroSlice
      @AdroSlice 10 หลายเดือนก่อน +5

      Its not null its nill höhöhöhöhöh
      I kid.

  • @emjizone
    @emjizone 10 หลายเดือนก่อน

    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.

    • @GrantGryczan
      @GrantGryczan 10 หลายเดือนก่อน +1

      What?

    • @emjizone
      @emjizone 10 หลายเดือนก่อน

      @@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.

  • @TheNewton
    @TheNewton 10 หลายเดือนก่อน +1

    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.

  • @c9der
    @c9der 4 หลายเดือนก่อน

    Soy Dev Here (I use React(JS) & Angular(TS) at work).
    My question is :---> why I didn't find anything wrong with JS/TS?

  • @AlexanderBorshak
    @AlexanderBorshak 5 หลายเดือนก่อน

    @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)?..

  • @cpuccino
    @cpuccino 10 หลายเดือนก่อน +4

    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.

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน +5

      it doesn't make sense
      no amount of copium makes sense. number[] and (number | string)[] are two different types. plain and simple

    • @cpuccino
      @cpuccino 10 หลายเดือนก่อน

      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]

    • @jt....
      @jt.... 10 หลายเดือนก่อน +2

      ​@@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.

    • @cpuccino
      @cpuccino 10 หลายเดือนก่อน

      Oh yeah nice catch, forgot about that.

    • @oscarljimenez5717
      @oscarljimenez5717 10 หลายเดือนก่อน +2

      @@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!!!

  • @lowkeycode
    @lowkeycode 9 หลายเดือนก่อน

    Wait a sec....this seemed like an ad.....

  • @grumpylibrarian
    @grumpylibrarian 9 หลายเดือนก่อน

    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.

  • @zaneearldufour
    @zaneearldufour 10 หลายเดือนก่อน

    The lack of `max` is enough reason to include generics, IMO

  • @Sam-cp6so
    @Sam-cp6so 10 หลายเดือนก่อน +3

    In these comments: hateful rust elves with no go experience

  • @zuowang5185
    @zuowang5185 10 หลายเดือนก่อน

    Couldn't you create a .Valid() function for your custom type and call it instead of writing the switch case at consumer code?

    • @DevCasey
      @DevCasey 9 หลายเดือนก่อน

      That doesn't get us compile time warnings :(

  • @iamworstgamer
    @iamworstgamer 8 หลายเดือนก่อน

    go does not need to do union types once you understand interfaces

  • @petery6775
    @petery6775 9 หลายเดือนก่อน

    yeah.. im grug developer for sure!

  • @bitmasked
    @bitmasked 9 หลายเดือนก่อน

    Before I watch: they’ll fix it in Go 2 don’t worry.

    • @GreyDeathVaccine
      @GreyDeathVaccine 9 หลายเดือนก่อน

      "We do not want to break the ecosystem. Go 1 and Go 2 code must be able to interoperate in programs with ease."

  • @polyscone-en
    @polyscone-en 10 หลายเดือนก่อน +8

    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

    • @tiko-
      @tiko- 10 หลายเดือนก่อน

      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.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน +1

      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.

    • @polyscone-en
      @polyscone-en 10 หลายเดือนก่อน +1

      I'm not missing the point, but thanks

  • @BinaryReader
    @BinaryReader 10 หลายเดือนก่อน +1

    Better, less verbose error handling, obviously

  • @kubre
    @kubre 10 หลายเดือนก่อน +1

    Gotuber

  • @AlessandroStamatto
    @AlessandroStamatto 10 หลายเดือนก่อน

    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.

  • @JuusoAlasuutari
    @JuusoAlasuutari 10 หลายเดือนก่อน

    I'd change it to C

  • @IIllIlIllIlIllIlIlI
    @IIllIlIllIlIllIlIlI 4 หลายเดือนก่อน

    The issue is one false move and the language is "ruined"~ endless nitpicking for eternity

  • @francis_the_cat9549
    @francis_the_cat9549 9 หลายเดือนก่อน

    Odin = Go - GC + Enums + [...]

    • @GreyDeathVaccine
      @GreyDeathVaccine 9 หลายเดือนก่อน

      Minus great concurrency :D

  • @josephchen8738
    @josephchen8738 10 หลายเดือนก่อน +1

    100% Agree. I love Go but I hate the way you do enums in Go...

  • @eminvesting
    @eminvesting 10 หลายเดือนก่อน

    Brother in Christ
    number[ ] | string[ ]

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  10 หลายเดือนก่อน

      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

    • @eminvesting
      @eminvesting 10 หลายเดือนก่อน

      @@ThePrimeTimeagen Nah I know the pain man, just messin around and pumping the algo fo ma boi

    • @oscarljimenez5717
      @oscarljimenez5717 10 หลายเดือนก่อน

      @@ThePrimeTimeagenyou can create a utility type for that, never worry again.

    • @jkjoker777
      @jkjoker777 10 หลายเดือนก่อน

      @@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

  • @Spiun666
    @Spiun666 10 หลายเดือนก่อน +3

    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.

  • @AScribblingTurtle
    @AScribblingTurtle 10 หลายเดือนก่อน

    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); //

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน +2

      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) //

    • @AScribblingTurtle
      @AScribblingTurtle 10 หลายเดือนก่อน +1

      ​@@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
      }

  • @kotchu
    @kotchu 6 หลายเดือนก่อน

    I would change err != nil

  • @rzyr
    @rzyr 10 หลายเดือนก่อน

    Java has nice enums

  • @himurakenshin9875
    @himurakenshin9875 9 หลายเดือนก่อน

    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.

    • @mage3690
      @mage3690 9 หลายเดือนก่อน

      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.

    • @brinckau
      @brinckau 5 หลายเดือนก่อน

      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.

  • @vitiok78
    @vitiok78 10 หลายเดือนก่อน +2

    PHP has great enums. It's embarrassing...

    • @GreyDeathVaccine
      @GreyDeathVaccine 9 หลายเดือนก่อน

      But that's recent addition to language.

    • @vitiok78
      @vitiok78 9 หลายเดือนก่อน

      @@GreyDeathVaccine So what?

  • @ttuurrttlle
    @ttuurrttlle 9 หลายเดือนก่อน

    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...

  • @sinamobasheri
    @sinamobasheri 10 หลายเดือนก่อน +1

    ads let's goooooooooooooooo

  • @chigozie123
    @chigozie123 10 หลายเดือนก่อน +4

    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.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน +1

      two subpar ways go devs are meant to cope with the lack of comptime 😂

  • @hashtagPoundsign
    @hashtagPoundsign 10 หลายเดือนก่อน +2

    Tabs are better, especially when going down 8 steps at a time.

  • @fennecbesixdouze1794
    @fennecbesixdouze1794 10 หลายเดือนก่อน

    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.

  • @rosehogenson1398
    @rosehogenson1398 10 หลายเดือนก่อน +5

    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.

    • @maparaccoon350
      @maparaccoon350 10 หลายเดือนก่อน +5

      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.

    • @raianmr2843
      @raianmr2843 10 หลายเดือนก่อน

      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.

  • @DN-fr2ez
    @DN-fr2ez 9 หลายเดือนก่อน +1

    JVM lamguages did enums the best

  • @constantinegeist1854
    @constantinegeist1854 2 หลายเดือนก่อน

    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.

  • @TheMrKeksLp
    @TheMrKeksLp 10 หลายเดือนก่อน +5

    Definitely top three:
    * ADTs
    * No Nil
    * No zero values

  • @EmmanuelLambertCanada
    @EmmanuelLambertCanada 6 หลายเดือนก่อน

    Change the gopher

  • @FrankGehann
    @FrankGehann หลายเดือนก่อน

    c# enums ==

  • @asdqwe4427
    @asdqwe4427 10 หลายเดือนก่อน

    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