Is Golang Still a Successful Programming Language?

[@MelkeyDev]

Subscribe if you want a Gopher

[@nexovec]

I have a pretty cool gopher plushie my grandmother knitted for me.

[@nimgol03]

I'm a Goblin 😆

[@esra_erimez]

I completely agree with you about Go error handling. It boggles my mind that people don't get it. Exceptions were invented to handle errors in constructors for object oriented languages. They never felt right to me.

[@umardev500]

That's what I think before know Go... After uses Go everyday I love the go error handler that best, it's flexible then any others language

[@tomasslavik1119]

I feel like exceptions are just hiding stuff. Golang error handling is explicit and I sometimes feel explicit things make code easy to understand. Longer to read but absolutely clear about "hidden mechanisms".

[@snorman1911]

Both have their pluses and minuses. To be fair, a large block of code where I want to handle any failure that comes up (a series of file writes, database operations, etc) looks way cleaner with an exception handler, and doesn't run the risk of someone adding a line of code and forgetting to add yet another error handler.

[@sergsergesrgergseg]

@@snorman1911 just make a little wrapper

[@michaelell389]

Golang is excellent because it's simple enough that an ape like me can write, readable, performant, refactorable code, and we can then crosscompile that code to run on anything.

[@einzelltuter2847]

same

[@lancemax857]

I'll use golang for backend development 9 times out 10.

[@esra_erimez]

10:11 It is a good thing that comments don't have audio because you'd hear me screaming in agreement with you at the top of my lungs. I wasn't against iterators being implemented but the implementation that they went was is the opposite of Go's own philosophy. They are anything but readable.

[@oleksiistri8429]

1:33 true, that is why i chose go for my project - simplicity!

[@hebozhe]

From a linguistics angle, the supposed syntactic ease of Python is almost completely canceled out by its lexical breadth (think COBOL) and permitted semantic obfuacation (think any dynamic PL).

[@dukeofnorfolk1842]

Some guy said it has the best minimum effort to performance ratio

[@belkocik]

And after 2015 Rob stopped contributing to a golang repo.

[@connormc711]

And most the contributions have been around optimizing and adding features like generics. Seems like he did a pretty good job :)

[@bpo217]

@MelkeyDev I think I remember you saying somewhere mid video that you think adding enums to Go is a good idea. I am just curious because I know you are a seasoned Gopher and I know you can accomplish the same thing with IOTA and a struct field in Go. Why specifically do you think this isn't enough I guess? Did you want the type safety and tooling support for narrowing the possible options in your current context? Genuinely curious! Did you have a video about this already?

[@lhd7105]

Was enum not added b/c entire sub-cultures of Golang enjoyers could create a rule to do it through some 3rd party way? Maybe like a 3rd-party compiler (Think Typescript)... Like does enum in Golang have to prove itself before being begudglingly added to official language? I think such a thing sort of happend to C++, like I seem to recall that Boost library was so helpful as a band-aid then C++ was forced to basically start to make boost a part of the language. By the way Melkey sensei I honestly could not understand the iterator example you screenshotted either and I know a dozen programming languages.

[@learningwithaaron]

i uses classes in javascript wen using express depending on the complexity of the project. It makes things cleaner and resuable

[@mjcgreatness]

This is my first time hearing anyone refer to python code as hard to understand. Looking forward to my first Go project to see for myself.

[@afterschool2594]

Go error handling is good enough although I love Rust one better, I am not a Rust users though. I think pattern matching any possible error would be better than just errors.New(msg) since we may one to handle a certain case of returned error. I know that we could just set global variable of errors but not every package in Go do that since it's not enforced.

[@lovekickerpk98]

i just have to say := this operator was a mistake. my code is inconsistent with whether to use = or := when reusing variables. happens alot when working with err's.

[@ebukaume]

A counter argument to having 1 way of doing things. It takes time for people from other languages to get used to :=.

[@WaseemAshraf]

Instead of using iterators I would use channels and go routines. Personally I don't think there was need of iterators but if they were being added a very simple syntax would've been appreciated.

[@austinraney]

I don’t think it’s that bad: type Foo []int func (f Foo)Iter(yield func(int)bool){ for _, value := range f{ if !yield(value){ // clean up return } } }

[@Myexpectationsarerealistic]

i can read assembly and C. No issues with literally any language other than Haskell and some weird Chimp Tier written Python.

[@tomasslavik1119]

I feel like Golang keeps the C like philosophy: features are not a part of language. Wanna hash table in C? Implement it. Wanna garbage collector? Implement it. Wanna monads? Implement. C and Go are just languages around computer primitives. Paradigms, design patterns, whatever is not a part of language, but no one prevents you from implementing.

[@Johanthegnarler]

I program in roughly 6 languages a week. Go has been replacing all of them lately

[@jamesfitzpatrick9607]

The adding of iterators and generics I think are a sign of what is to come. The syntax around the iterators is horrible. But that style of nested `func` is used in so many other libraries. The big one we are currently using is `lo`, and it makes the code so hard to read. But I had this though a year ago before the iterators and generics where there. It is a young language. By the time it is as old as java, python, javascript what feature will be added to it. Will it still be able to say it is a simple language? I don't think it will.

[@austinraney]

This reads as reactionary. Sure, iterators seem a little daunting at first glance, but after playing with them a bit, I think they are another example of the go team balancing performance and complexity in an extremely elegant way. Try implementing an iterator for a type instead of writing function that returns an iterator and I think that will at least make it click faster. But how? Go could not have introduced iterators using an interface (e.g. Next() (int, T)) b.c. that would have broken backwards compatibility. Code out in the wild could conform to the iterator interface but be completely oblivious to their existence. This is a huge problem and made it a non-starter. Plus, the interface design has really poor performance and lacks clear iterator clean up semantics.

[@jamesfitzpatrick9607]

@@austinraney If what I said was reactionary, it was not meant to be. I agree an interface would have being far nicer but breaking backwards compatibility is a non starter. I not going to pretend I know how that would have affected performance, but your not the first person I heard saying that so I will take your word. No clear iterator clean up semantics sounds like the language was not designed to have iterators. My argument is Go is still a young language at 15 years old and the adding of iterators and generics have made it more complicated. What other features will get added to Go by the time it is the same age as Java (29 years) and will we still be able to say it is a simple language. It's my belief that we will not be able to say it. Over the next decade the language will grow in features making it more complicated. Will it still be simpler than today's Java, I would say yes. But will it be simple, I don't think so. One other issue I see which I am not fully sure which side I am falling on yet, is the calling the language a batteries included language. Don't get me wrong I love the standard library, I love the idea of batteries included languages, but what other languages are know for this, Python. Currently Python is trying to remove dead batteries from the standard library for many reasons. There will be a day when Go will need to do the same thing. This is a problem which comes with age, and I am not sure if this is a real problem, but when people try sell Go based on the batteries included argument I am hesitant.

[@hamm8934]

I'm classing it now: options are going to come to Go before the end of this decade. Requests for options to me seem as prevalent as requests for requests used to be. People really dont like go's error handling (whether that's justified or not).

[@Bob-1802]

@@jamesfitzpatrick9607 And Python is adding new more complex batteries, just to satisfy professionnal programming. Its original philsophy was simplicity (can't remember when I heard that before 🤔🤭) for script purposes, not a full fledge language like Java. It seems that most popular programming languages are facing the same fate, trying to make everybody happy. Go is facing the same thing.

[@mscholzdev]

4:30 I think TS is the best by adding it to node for the same language in front and back end even if JSDOC can do typing but not transpiling

[@mscholzdev]

I use go now as backend btw (and arch, vim and dvorak (thanks to theprimeagan and Tj devries ((

[@darwinrc]

@@mscholzdevarch mentioned, Dvorak mentioned, theprimetime mentioned

[@mscholzdev]

@@darwinrc 🤣🤣🤣

[@JT-mr3db]

I’ve never used go without generics or iterators and keen to understand why you think they were not good features.

[@cabc74]

Go users have this mantravthat their language is simple. It is so simple tha makes simple things like iterating over avcollection a hard thing (until now). So they are mad that now the have a simple and standard way for it. Snobbery

[@jacilperez3441]

@@cabc74lol

[@Lemmy4555]

Not a fan of Go while i sometimes pick some takes from it and apply them in TS, however i think many times the Go maintainers are extremists, the case of enums is crazy, such a needed feature that is so obvious and yet they do not want to implement it and people resort in 3 or more different ways in order of solving that. that's the opposite of simplicity, that's a fight against windmills.

[@peterj.2114]

Considering that every project nowadays requires you to build something quickly and maintain it, Go is a no-brainer unless you are doing something hyperspecific where the ecosystem is already strong elsewhere. Having dealt with npm, Maven and a plethora of random bullshit theoretically-useful-but-actually-not-language-features in the past Go really just kinda clicked for me. Hoping it stays lean going forward. Iterators are definitely something I can't see myself using but don't know enough about their usage to comment on them.

[@nathanp3366]

I am gathering recently that this is not a unique take but I really don't like how in go to make something public you capitalize it. I just don't get the logic - the language prioritizes readability and simplicity to the point of being extremely verbose with some things but they don't want an export keyword or something?

[@MrWesopl]

I love and hate go. It's so damn fast, but still missing many language features. Every time I use go, I miss Kotlin.

[@Tantewillieja]

Nil pointer references and empty strucs, truly don't understand the design choices of go

[@ArturdeSousaRocha]

The problem with adding enums is what the zero value should be.

[@ebukaume]

I personally think it's a mistake to fallback to zero values for missing values. It's painful to deal with at several levels

[@cd-stephen]

@MelkeyDev - the hardest part of watching this video, is seeing the Advance360 as a decoration piece 🙂

[@MelkeyDev]

Good thing I have two. One is the piece you mentioned. The other is the one I use. Never make assumptions!

[@cd-stephen]

@@MelkeyDev yeah just messin... love your chan.

[@oleksiistri8429]

yeah, that func-yeild-func-yeild thingy sucks )

[@danielt8880]

And Now Go has generic. Lol

[@dukeofnorfolk1842]

Never used generics in my entire career

[@vitalyl1327]

I pity those who have to maintain your unreadable boilerplate code.

[@dukeofnorfolk1842]

@vitalyl1327 my code only does one thing, and it did well

[@armanrozika]

learn english first dude

[@muzzletov]

WHERE THE FCK ARE ARENAS??!?!?!?!??!

[@hamm8934]

shhhhhh that would make too much sense.

[@ebukaume]

Python and JavaScript used to be simple. Just saying...

[@SoftIceCreamMan]

Whatup GoGang?!

[@RoroZoro-lf4nz]

Everything about the language is good except the introduction of iterators. I don't even think 10% of go codebase benefits from the usage of those iterators. They are anything but simple, very hard to read and to write. I just don't see any benefit of using them. The language definitely lost a part of its simplicity with those iterators being introduced. Generics are ok but not iterators.

[@Guergeiro]

4:15 I've used TS for frontend and backend. I think the killer feature is type sharing at the boundaries of the system without much effort. Hands down, my favourite language is Golang, but even if i keep a correct OpenAPI spec for my http API and use a tool to generate the types for the frontend, this is a friction point and extra step. If backend and frontend are separate teams this isn't a problem, but if you're doing a fullstack, then it's unnecessary friction. And like you said, I guess TS gets you 80% there on the backend+frontend, so this is one of the key points for fast iteration.

[@Johanthegnarler]

I don't like JavaScript on the backend. And lately, I've been freed from JavaScript hell. I don't even fuck with NPM anymore except for a couple linters and semantic release. It's been so liberating simplifying my stack. I love Vue, but damn just reducing all the bloat from the over engineered front end for essentially the simplest forms of SPAs you can produce has been amazing.

[@MelkeyDev]

I know so many people say that same argument about type safety between FE and BE, and for the record, I agree. Having it all done with TS guarantee's that. But I think as a group, we've gotten too obsessed with strict typing. Throw it back to just sending JSON. IDK, it might be me, but I think it's okay

[@Guergeiro]

@@MelkeyDev tbh, it's good as in developer experience, but that's that. No more guarantees. And you can pretty much achieve the same thing with openapi schemas with a tool that generates types from that.

[@darwinrc]

Or better still, get rid of JS/TS and use HMTX

[@DM-pg4iv]

FYI JS is going to add structs as s feature who would've guessed this world happen

[@learningwithaaron]

node, scratch, pascal and python will forever be the simplest

[@statuschannel8572]

Node ? bro i spent hours and hours to setup a basic typescript project in node

[@michael1477]

@@statuschannel8572 bro its like 3-4 commands to run and then adjust tsconfig file according to personal preference. How did it take you hours just for this? it wont even take 5 minutes

[@oleksiistri8429]

nope!

[@vitalyl1327]

Pascal - yes (but Oberon is better). Still, Scheme is the best simple language out there.

[@ebukaume]

I think his point is that starting simple always result to pain later in language designs

[@thqthq9999]

C

[@mubashir3]

Please don’t use the shocked face thumbnail. It’s overdone and officially entered the annoying phase a few years ago.

[@MelkeyDev]

but sir

[@DrewryPope]

you're wrong about iterators and generics

[@DrewryPope]

if anything they should go even further

[@esra_erimez]

I respectfully disagree. I don't think generics should have been added to Go.

[@MelkeyDev]

im not wrong

[@esra_erimez]

@@MelkeyDev I love this response

[@davidbm873]

I see generics as type unions, and I like it :3

[@PaulSebastianM]

Go is not fun to read at all.

[@statuschannel8572]

yes its boring and boring is GOOD

[@ProfessorThock]

Why not?

[@vitalyl1327]

Golang is awful. It's a language built on the very wrong premise that language simplicity can somehow translate to solution simplicity - while in fact all this simplicity does is facilitating horrible boilerplate code and outright barring even a chance to solve complex problems in a simple way.

[@dukeofnorfolk1842]

@@vitalyl1327 It does things explicitly, it doesn't have cheap hacks just so your function can have 5 less lines of code. If your idea of simplicity is by how many lines of code, check out PERL and see how readable it is

[@mjcgreatness]

This is my first time hearing anyone refer to python code as hard to understand. Looking forward to my first Go project to see for myself.