Go Kind Of Sucks

Summary

このスクリプトは、Go言語に関する個人的な不満と改善点を掘り下げた議論です。デフォルトでnilのマップ、airラッピングの問題、インターオペラビリティの難しさ、特定のヒープタイプに対するガベージコレクションのパフォーマンスなどが指摘されています。また、goroutineの優先度の問題、チャネルの扱い、デフォルトのnilインターフェースの危険性などについても議論されています。しかし、言語の欠点だけでなく、どのようにそれらを回避し、より良いコードを書くかのアドバイスも提供されています。Go言語を始めとするプログラミング言語はそれぞれに欠点があると同時に、それらを克服するための方法も示唆しています。

Takeaways

• 🧵 Go言語のデフォルトnilマップは便利な反面、エラーハンドリングが困難であると感じる人もいる。
• 🔄 空振の回避とエラーハンドリングはGoでの開発で重要な要素であり、プログラマの責任で行われる必要がある。
• 🔌 Go言語のインターオペラビリティが弱いと感じる開発者もいるが、実際にC言語と連携した経験がない人もいる。
• 🚦 Goroutineの優先順位付けができないことが、スケジューラに依存してしまうと感じる人もいる。
• 🚮 特定のヒープタイプに対するガベージコレクションのパフォーマンスが問題であり、Arenasが提案されていたが現在は却下されている。
• 🔄 コンカレンシープリミティブの多くはチャネルを使用し、その改善が期待されている。
• 🔒 Mutexを持つ構造体は、特定のメソッドで排他制御を行い、全体をMutexでラップする必要がない。
• 📈 Go言語のメモリ確保の制御が難しすぎると感じる人もいるが、他の言語でも同様の問題が存在する。
• 🚫 nilインターフェースのチェックが初心者に陥らせる問題であり、エラーハンドリングの難しさがある。
• 🛑 Panicはエラーが発生した時にプログラムを停止させるためのものであり、不適切な使用は避けるべき。
• 📝 Goのフォーマットツールの改善が期待されており、一部の開発者には問題があると感じられている。

Q & A

Go言語におけるデフォルトでnilのMapはどのような問題を引き起こす可能性がありますか？

デフォルトでnilのMapは、空のMapを扱う際のエラーハンドリングが困難になる可能性があります。また、nilのMapに対するアクセスが適切でない場合、ランタイムエラーを引き起こす可能性もあります。

ポインタの振る舞いに関するGo言語の欠点は何ですか？

ポインタを使用すると、非常に複雑なデータ構造を作成し、ガベージコレクションのパフォーマンスに影響を与える可能性があります。特に、ポインタが多数含まれる構造体は、ガベージコレクトが難しくなることがあります。

Go言語におけるgoroutineの優先順位に関する問題とは何ですか？

Go言語ではgoroutineには優先順位がなく、スケジューラによって実行が決定されます。これにより、特定のgoroutineが生成するガベージの量に基づいて、実行順序が変動する可能性があります。

Go言語におけるチャネルの欠点は何ですか？

チャネルは便利ですが、V2版が欲しくなるほどの改善点があります。チャネルはバッファリングされていない場合、デッドロックに陥る可能性があります。また、チャネルを閉じる際には、適切なエラーハンドリングが必要です。

Go言語におけるインターフェースのnilチェックはなぜ困難ですか？

インターフェースはnilである可能性があり、かつそのメソッドを呼び出すとpanicが発生するため、nilチェックが忘れられがちです。これは開発者がエラーを適切に処理できていない場合に問題を引き起こす可能性があります。

Go言語におけるメモリ割り当ての制約に関する問題とは何ですか？

Go言語では、開発者がメモリ割り当てを適切に管理できない場合、メモリリークが発生する可能性があります。特に、複雑なデータ構造を頻繁に作成する場合、ガベージコレクトが追い付かずメモリ使用量が増加する可能性があります。

Go言語におけるエラーハンドリングの欠点は何ですか？

Go言語のエラーハンドリングは明示的であり、エラーが発生する可能性のあるすべての場所でエラーをチェックする必要があります。これはコードの冗長性を招く一方で、エラーの発生時にプログラムを適切に停止させることができる利点があります。

Go言語における並行性プリミティブの問題とは何ですか？

Go言語ではgoroutineとチャネルを用いて並行性を管理できますが、それらを適切に管理することは困難であり、デッドロックや競合状態を引き起こす可能性があります。

Go言語におけるテストの安定性に関する問題とは何ですか？

並行性を含むGo言語のコードは、テストの安定性に関する問題を引き起こす可能性があります。テストが実行される順序やタイミングによって、テスト結果が変動する場合があります。

Go言語におけるパフォーマンスの欠点とは何ですか？

Go言語はガーベージコレクションを行うため、特定の種類のヒープに対してパフォーマンスが低下する可能性があります。また、チャネルやgoroutineを使用する際にもパフォーマンスへの影響があります。

Go言語におけるデフォルトのnil値に関する問題とは何ですか？

Go言語では変数を宣言した際に初期値としてnilが設定されるため、nilの値を適切にチェックしなければならない点が問題となります。これは開発者がnilポインタ例外などのエラーを引き起こす原因になる可能性があります。

Go言語におけるインターオペラビリティの問題とは何ですか？

Go言語は他の言語との相互運用性において制限があり、C言語などの他のコードとの連携が困難になる場合があります。これは外部関数インターフェース（FFI）を扱う際に問題が発生する可能性があります。

Go言語におけるデバッグの難しさとはどのようなものですか？

Go言語ではデバッグが困難であると感じることがあります。特に、並行性やチャネルに関するバグを追跡することは、デバッグの複雑さを高める要因となります。

Go言語におけるパフォーマンスモニタリングの問題とは何ですか？

Go言語ではパフォーマンスモニタリングが難しい場合があります。パフォーマンスのボトルネックを見つけるためには、適切なツールやメトリックスを使用する必要がありますが、それらが常に利用可能であるとは限りません。

Go言語におけるエラーの返却に関する問題とは何ですか？

Go言語では複数の値を返却するため、エラーを適切に処理する必要があります。しかし、エラーが返却される順序や方法によっては、エラーの特定やハンドリングが困難になることがあります。

Go言語におけるデフォルトのnil値が引き起こす問題とは何ですか？

Go言語では、変数が初期化されていない場合にデフォルトでnilが割り当てられるため、nil参照エラーが発生する可能性があります。これは開発者がnilを適切にチェックしなかった場合に問題を引き起こす原因となります。

Outlines

00:00

📝 Go言語の欠点と改善点についての個人的な意見

スクリプトではGo言語に関する個人的な不満と改善された点を探求します。特に標準的な批判ではなく、実際の問題点について議論します。マップの初期値がnilであることや、エラー処理の冗長性、他の言語との連携性、ゴルーチンの優先度の問題、ガーベージコレクションのパフォーマンスなどが挙げられます。また、改善された点として、特定のヒープタイプの問題がアリーナによって解決される可能性があることが触れられています。

05:00

🔄 Go言語における並列性とエラーハンドリングの議論

第2段落ではGo言語における並列性の問題とエラーハンドリングのアプローチが議論されています。チャンネルの使い方、データ競合、ゴルーチンの終了管理、テストの不安定性などについて言及され、Go言語における並列性に関する様々な課題が指摘されています。また、エラーハンドリングにおいては明示的なエラー処理が行われることが強調されています。

10:01

🛠 Go言語におけるメモリ管理とエラー処理の難しさ

第3段落ではGo言語におけるメモリ管理の問題とエラー処理の難しさが述べられています。インターフェースのnilチェックの重要性、パニックの使用、構造体のフィールドの返り値の使い方などについて触れられ、Go言語での開発における注意点が詳細に説明されています。

15:03

🔍 Go言語における構造体のミューテックスとエラーハンドリング

第4段落ではGo言語における構造体とミューテックスの使い方、エラーハンドリングのアプローチが議論されています。ミューテックスを構造体に持たせることの利点、エラーが発生した時のプログラムの停止、Rustにおけるエラーハンドリングとの違いなどが説明されています。

20:04

📚 Go言語におけるコード管理とリソース管理の問題点

第5段落ではGo言語におけるコード管理とリソース管理の問題点が挙げられます。構造体のフィールドの返り値の使い方、ゼロ値の有用性、エクスポートされた構造体フィールドのメソッドの問題、コンテキストの使い方などが議論され、Go言語での開発における注意喚起事項が詳細に説明されています。

25:06

🤔 Go言語の欠点と学習曲線についての個人的な感想

最後の段落では、Go言語の欠点と学習曲線についての個人的な感想が述べられています。言語ごとの特性や欠点を理解し、それらを経験することで問題を回避することができると強調されています。また、どの言語にも独自の問題点があることを認め、Go言語をおすすめする意気込みが示されています。

Keywords

💡Golang

Golangは、Googleによって開発されたプログラミング言語です。その特徴はシンプルさとパフォーマンスであり、特にネットワークやコンカレンシーに適しています。ビデオではGolangの欠点について議論しており、言語の選択肢として推奨されていることからも、ビデオの主題と密接に関連しています。

💡エラー処理

エラー処理は、プログラムが異常を検知し、それを適切に処理する方法を指します。Golangでは、エラーを明示的に返す方法が一般的ですが、ビデオではエラー処理が煩わしいと指摘されています。これは、言語の欠陥として捉えられており、ビデオのテーマに沿った重要なポイントです。

💡nil

nilは、Golangにおける値の欠如を表す特殊な値です。ビデオでは、nilをデフォルト値として使用する際の問題について触れられています。これは、言語の設計に関する議論と関連しており、ビデオの核心的なトピックの一つです。

💡インターオペラビリティ

インターオペラビリティとは、異なるシステムや言語が協調して働く能力を指します。ビデオではGolangが他の言語との連携が困難であると述べられており、これは言語選択時の重要な検討ポイントとなります。

💡ゴミ収集

ゴミ収集は、プログラムが使用していないメモリを自動的に解放するプロセスです。ビデオではGolangのゴミ収集のパフォーマンスに関する議論があり、特定のヒープタイプでは問題が生じる可能性があると指摘されています。これは、言語のパフォーマンスに関する重要な側面です。

💡goroutine

goroutineは、Golangにおける軽量のスレッドです。ビデオではgoroutineの優先順位付けの欠如や、それによって生じる可能性のある問題について触れられています。これは、並行性とパフォーマンスの議論において核心的なトピックです。

💡チャネル

チャネルは、Golangで並行性を実現するための主要な機能です。ビデオではチャネルの利便性と欠点を評価しており、言語の並行性モデルに関する重要な議論ポイントです。

💡コンカレンシー

コンカレンシーは、複数のタスクが同時に実行されることを意味します。ビデオではGolangにおけるコンカレンシーの実装とそれに伴う問題について議論されており、言語の設計とパフォーマンスに関する重要な側面です。

💡パフォーマンス

パフォーマンスは、ソフトウェアがタスクを実行する速さと効率を指します。ビデオではGolangのパフォーマンスに関する様々な議論があり、言語の選定と使用において重要な検討事項です。

💡メモリ管理

メモリ管理は、プログラムがメモリを効果的に使用し、不要になったメモリを解放するプロセスです。ビデオではGolangにおけるメモリ管理の課題について触れられており、言語のパフォーマンスとリソース使用に関する重要なトピックです。

Highlights

Maps being default nil can lead to issues with error wrapping and stack races.

Poor interoperability with other code, such as difficulties in interacting with C.

Goroutines can't be prioritized, leading to potential performance impacts.

Garbage collection performance may be improved with Arenas for specific heap types.

Complex data structures with pointers can hinder garbage collection efficiency.

Difficulty in converting IO buffers or readers into channels.

Verbosity in Go is considered a downside by some, especially with error handling.

Try-catch error handling is criticized for being verbose and hard to manage.

Go's explicit error handling is seen as verbose but also as a feature that ensures explicitness.

Concurrency primitives like channels have their drawbacks, such as difficulty in closing channels properly.

Go routines don't require lifetime management, which can be a double-edged sword for new developers.

Writing games in Go can be challenging due to garbage collection and other language affordances.

Panic is seen as a useful feature in Go for handling fundamental program errors.

Mutex in a struct can be a design choice to protect specific data or operations.

Defer is criticized for causing issues in large codebases and for its use in cleanup.

Go's tooling like go format and go vet could be improved for better code management.

Every programming language has its own set of challenges and pain points.

Transcripts

what sucks about goang I saw a post this

post in r/ Russ and wanted to ask about

goang too not the basic criticisms the

veros verbosity Telemetry uh but what

are your personal uh bug Bears uh the

things that let's see the things that

are getting better Etc I think I have a

couple I have a very simple one I hate

Maps being default nil air wrapping is

really really nice but it also can be a

pain I'd like to make sure to always

have really good stack races sometimes

just like you know when you get an air

and you don't have it w properly

sometimes it's kind of it's going be a

you know you do have to rely on the

programmer to really be very very very

consistent in its air wrapping and so I

find that to be really one of go Link's

R you know what I mean air equals nil

doesn't actually bother me honestly air

equals nil never has bothered me all

right I'm continually editing the list

poor interoperability with other code I

don't know what that means like you

can't interact with C easily if that's

the case then I guess I've never had ffi

as something I've had to do so I don't

really have like I have I it's just a

black box to me I've literally never

done it myself I've used it obviously

like you know when I use Lua and I'm

calling into Vim I'm calling into to see

functions like I get that I get the

concept I've just never done it and so I

don't really understand what it means by

poor uh uh poor interoperability I don't

know I've just never had I've never just

had that experience right uh I don't

know what SEO is means let's see me

let's see means something important PPR

function it is lost like I understand

all those words individually including

CPR I don't know SEO uh but I but I

don't get that okay unable to prioritize

certain go routines go routines that

generate no garbage can be uh be

impacted as much as those creating more

garbage okay okay I I could see that

being it's an interesting take at least

can we agree that that's an interesting

take you have no prioritization of go

routine so therefore you're kind of just

you're sub subjugated to the the whims

of the scheduler and that's that I'd say

that's fair that's fair

uh let's see poor garbage collection

performance with specific types of heaps

may be addressed by Arenas now well

Arenas have been you know have been

largely said no to I really hope they

come back with a new proposal I'm

curious what this means does anyone know

what this means does anyone like Judo do

you know what that means what is what

does it mean to have poor poor

collection for certain types of of

objects on the Heap like is there

something that I I don't understand is

it just when you have like strs with

pointers with strs with pointers isn't

green thread prioritization and anti in

concurrency my assumption is that it's

almost impossible to get right that's my

assumption yeah he he means certain

allocation patterns okay so I assume

what what he means by this one is uh is

going to be a struct with pointers that

those pointers are structs with pointers

and so then you just get this like if

you want to see if you can collect this

thing you have this like whole graph

walking experience that you have to go

on to is is my assumption of what that

means is that is that fair I mean I

could I could see that being uh I could

see that being a negative but at the

same time it's like I don't know you

also create I mean what do you want you

create an extremely complex data type

with lots of pointers and a lot of you

know following and then it doesn't

perform well with a generic garbage uh

collector yeah and I think adras Arenas

would clearly address this but still

it's like you kind of get what you get

you know if you have really complex data

structures and you make them really

really frequently you can also pull them

so they just don't get collected and

then you just don't have that problem

right like that could be nice uh many

gotu with concurrency Primitives closing

channels yes I do agree that the

channels though wonderful just I feel

like a channels V2 would be fantastic

gof Funk closure data races the

attraction for newbies to buffer

channels arbitrarily unnecessary use of

concurrency mechanism because they're

the first class citizens go routines

don't require lifetime management I'm

not sure what this this means like you

don't need a context to be passed into a

go routine so it doesn't get killed is

that what that means I think that's what

they're trying to say is that you don't

need reading this list it sounds like

something coming from a Game Dev

perspective Ah that's very interesting

yeah I would say that if you're choosing

go playing as as the language to write

games in like you're you're you're

you're fundamentally in an uphill battle

I think that's fair to say because

anytime you're in a garbage collected

language you get certain affordances

which make writing programs easier but

that certain affordances Mak certain

types of programs by definition hard

right so garbage collection is a

fundamentally hard activity to have when

you're writing games you can write

pretty solid games but you're not

writing Starcraft or factorio and go

yeah yeah yeah I think there's things

that I think there's things to love and

go but there's also like the four things

that make go or the three things that

make uh uh channels difficult I do agree

like one thing I really dislike is that

it's very hard to take an IO buffer or

an IO reader and turn it into a uh

Channel I don't know the way to do it

other than like you have to it's very

hard to do the conversion between the

two you have to you have to create your

own little reader and that then pumps

out into a channel and it's just like

you know I just don't love it

I just don't love it why would you do it

because sometimes you just want to you

want to channel you don't you don't want

to have to do the reader writer I feel

like go is stupidly verbose I haven't

really hit the verbose level yet right I

I haven't I'm writing a very complex

program in go and I do not have any

problem with the current verbosity it's

verbosity and air handling I don't think

it's verbose and air handling I think

that's just the difference between I

think most people that state that are

used to tr catch styled air handling

I think if you're used to tr catch

styled air handling airs as values feel

verbose but airs as values are are

inherently nicer right they're

inherently nicer uh TR catch is evil I

generally think TR catch is evil I I

generally think that uh shiting control

flow is really hard I think that it's

it's very hard to get TR catch to be

right you know also people uh also

people that consider uh that typesafe

code never handles errors properly yes I

mean I mean it's the it's like my big

gripe about typescript I've said it a

bajillion times so I don't need to like

beat a dead horse but typescript isn't

type safe because it it just isn't type

safe but B it also just has really poor

error handling because JavaScript is

poor error handling right it's just it

is poor it's not it's not as good as

erors as value erors as values will

always be the best like every single

time it's oh it's always awkward it's

super awkward in uh it's okay to fail

situations and so what I mean by that is

you have a call and if it fails that's

okay you can just go to the next thing

so then you have this like TR catch

where you have to define the variable

outside the tri catch scope block and

then set it through through it and then

on the outside then you have to check it

like it becomes these really long

verbose like activity what should I try

instead of try catch so when you so I

can tell by the way you're asking this

you could have you could have dropped

this as a a newbie programmer and just

asked this and I would have actually

known try so you have to try a different

language you can't really I mean you can

technically get the experience in

typescript by using effect um or other

error result handling objects but the

problem is is that you have to call

every function with it because you don't

know when a function like if you use a

library you don't actually know if that

Library will throw you just simply

cannot tell you cannot tell in

JavaScript if something will explode you

just don't know and so you kind of have

to wrap everything in a TR catch because

you just don't know whereas when you're

using something like go if it airs it

airs every time in a certain way and so

you like no you're like okay if I call

this function 100% of the time I know

this function could ER therefore I need

to handle it and do something about it

which is that's why people say that go

air handling is verbose it's verbose

because it's explicit it's not verbose

because it's verbose now rust has kind

of better err it's kind of I only say

kind of because remember you have to

lift out values and so you still have

these big decision points that happen

Zig might be the most convenient of them

all I think go is really really good not

much different than fpus yeah yeah

either Mo ads result objects either the

same the same same thing right anyways

all right let's keep on going uh many

gotas with concurrency I do agree with

this there is definitely some of that uh

this I don't really get but I assume it

means you you don't have context

required so that go routines get

terminated when your context is done but

that's kind of more of a skill issue but

I do agree it'd be nice to just have

autom magic handling right I think we

could all agree that it'd be nice to

have automagic handling of retains flaky

test because of assumptions that don't

hold up with current current code I mean

again that's your own that's that that's

just skill issue that's pure skill issue

if you write code in such a way that you

have flaky test because of concurrent

code that's your fault like real real

talk here's a good example of it I'm

going to jump over here I'm going to

open this up and I'm going to go Doom

test uh right here so I wrote the Doom I

wrote launching Doom from go and I did

this right here

you see what this does right here this

forces synchronization so all doom

programs once they read their header

will let you know when they are

ready okay I am now ready and I'm

running but I will let you know when I'm

ready so I have a forced synchronization

point so I so I know that rows and

columns are now defined I know

everything about the program and so it's

like yeah I can I can kind of go through

and do uh I I can I can think through

the concurrency problem so when I see

this thing that uh flaky test that's

appear your bad right it's your

bad synchronization blocking during IO

channels not as performant as people may

expect well I mean it's a mutex dog

right there's a mutex in a in a channel

so yeah I mean I

mean I mean you can't use channels for

everything right spawning a bunch of go

routines is lightweight cheap according

to everything you read but really go

does have a of again of course but the

cost is pretty lightweight it's no

different than like say Tokyo right or I

assume it's much not different than

Tokyo it it probably it's within the

same operating Paradigm as Tokyo which

is just anytime you have uh green

threads they come with a necessary cost

because there's always a runtime

associated with it uh and if you don't

understand that I I feel like

that's I mean for me that's more like

skill issue like they're

cheap they are lightweight Che like

that's proper to say cuz what's the

alternative to does anyone know in chat

I know there's a lot of newer people

does everybody know what the alternative

is to a green thread OS thread yeah yeah

exactly and those things are effing

heavy like those things aren't

lightweight like you're not you're not

getting you're not getting a lightweight

experience doing those a yellow one

right so so it's like when they say

lightweight you got to remember that

lightweight is is a relative term you

know your mom your mom's a thread CH

dude chat is a chat chat a little silent

today chat's a little weird today chat's

always a little weird today you know it

just is okay Iota use a numer you say uh

when your whole data structure fails to

unmarshal uh on unknown values I mean

that's true in any that's true in any

strict uh type language right so rust

does the exact same thing if you have if

you have missing values and things if

you if your definition does not match

what comes in it just blows up and it's

just like can't do it I guess I don't

know what they mean by this maybe they

mean that if there's an extra value then

it can't decode if that's the case then

yeah that' suck I just thought it would

drop it I'd have to check that out uh

Iota I agree Iota and enumerations are

largely

dumb no ability to have a static map you

can create a function that returns a

constant map but then you lose control o

uh over it going on the Heap often

resulting in package level map that can

be modified fighting resisting m

mutability in general fair fair fair

fair take Fair take many apis and

packages don't give the caller control

of memory allocations I mean it's a it's

not a

managed it's not managed memory you know

difficult to constrain memory

allocations sure you can Benchmark and

eliminate hotspots or add Telemetry slm

monitoring you can also pull I've never

found a good way to keep the lid on it

at compile time you can pull right uh

pooling is probably one of your best

options here some unit tests can be

written to check allocations but those

rely on existing uh code

paths I mean I'd say that

here's what I got to say I'd say that if

you have a hard time creating new memory

you're probably going to have a hard

time creating new memory in any language

I I'm not sure is there is there like I

don't really get that critique in the

sense that if you can't constrain how

much memory you're creating in go I

don't think rust or any other language

solves that right does any does does

anything actually

solve does any language solve this I I I

don't think so

because you still if you have to create

the objects you're creating them no

matter what C does not solve it you

still have to free it right it's kind of

strange thing to see Zig allocators but

you're not actually I mean the thing

about Zig allocators is you get Arenas

so cleanup is really easy right you

could have your own little Arena

cleanups and all that so yeah yeah yeah

I I I get that

but it well it can stop it can't stop

you from being an idiot exactly like

that's what I'm seeing is

that you constrain memory allocations by

manually constraining memory allocations

and whether you're in rust or Zig or or

C or go if you create a million objects

you create a million objects there's not

there's not really there's not really

two ways around it a nits a foot gun

agreed I I don't use it I've never seen

anything good from use it yep just never

use it uh nil interface checks are a

gotta to almost every single newbie at

some point I got got by this one so I

think that this is the the the fact that

you can call a function on a nil I think

is a fundamentally bad decision the

error from is absolutely bizarre and it

takes you a long time to realize what's

happened I think that that is by far

Go's single greatest mistake yeah I'm

confident in that I'm absolutely

confident in that right uh panic I think

Panic is fine I I like panic I in fact

dude dude dude dude last night I decided

to do this I got a little frisky okay in

my antsy parser I decided to give it the

ability to decide how wide you want your

bite do you want your bite to be 8 bit

8bit resolution or 16bit resolution for

how big it is or even larger 32bit

resolution so I made this idea of these

bite iterators and bite writers to be

able to go through and write at differ

sized widths right which was going to

cause like a gigant I I got to quit

saying the word right it's going to

cause like all these giant headaches but

I was smart

enough s and madams to do this is that I

heavily assert my code and I heavily add

in a bunch of state to my asserts so I

have this notion in my asserts that uh I

can add assert data that prints it out

at the end and so what I did here is

that I created a single state object and

then I passed that single state object

into my assert so when I fail it

naturally will cause um a nice assert

pattern so check this out so let's go

back to my little writer uh let's go

back to my RGB writer and I have this

whole uh there we go this is what I'm

looking for right there I'm going to

take this out for just a second and just

go like this all right cuz that's what I

had at one point and I'm going to go

here and I'm going to go go run uh go

test there we go I think this should

work out bam look at that we got

ourselves a nice little beautiful we we

failed on something but I don't think

that that's what I want to do is it an

parser or is it go run hold on what's

what am I trying to do oh yeah I've made

changes dang it I made changes um can I

go like this add add uh ccz give me that

little czz uh go like this and let's go

like that plus one there we

go wait hold on sorry hold on I just oh

my goodness why are you lying to

me dang it what did I do working example

of this

thing hold on hold on

oh my

goodness I forgot that I had uh I forgot

that I had uh

had forget about it forget about it

forget about it you know what forget

about it forget about it I don't even

want to show you anyways I it was so

good I wish I could show you but it was

so good but effectively the

get checkout Master uh get stash pop

okay anyways the general idea was that I

was able to take I was I was able to see

exactly where my parser failed because I

panicked the program and the idea is

that no matter what I do you'll see

aerts everywhere like if I try to

produce a frame and my current row isn't

the length and my current index isn't

the length of the data uh holding it in

like if I'm not perfectly at the end my

exact data that I expect I should the

whole program should just stop working

and I'll print out the current state of

everything and so it's i i find I

absolutely love like I love that I love

panic panic is fantastic Panic is one of

the greatest things ever ex that ever

exist bad use of panics not good Panic

is hot yeah there's also the range bug

but they fix that one two two yeah a

Define bad use if you just panick

because something didn't go the way you

wanted it to that's not good you panic

when the when the program fundamentally

um you panic you panic in code when when

the fundamental assertion about the

universe is wrong your Universe of

course right it's like expect well you

don't have unwrap you have expect though

in

Rust right right and so like when you're

here and you go like this when you go

like if you're in Rust and I had like

food. expect you know blah blah you know

uh let you know let V equals this right

like I'm saying something about the

universe this could never break right so

if Fu was a mutex and I did this in

Rust like this should always work if it

doesn't work

then you have like fundamentally broken

the universe and your program no longer

works anymore and you should just crash

the whole thing like get the hell out of

here it's broken forever

right I panicked in my interview today

oh don't panic in your interview Jeremy

let's see mutex in a struct no idea what

it's meant to

protect yeah I actually like this I

actually like this the reason why I like

mutex and instruct so this is so you can

tell this person does a lot of rust uh

uh the reason so the thing about rust is

that rust if you have a value that is

shared across uh threads right whatever

this value is you always have to wrap it

in an arc mutex whatever this value is

so you have to wrap like an entire

struct in an arc Comm mutex or if or if

you want like you always have to wrap

the top level whereas with go let's say

that you had a struct that almost all of

its operations required no mutex anyone

from anywhere could call it except one

place then you have a mutex that hangs

off of a struct definition right

and you know mutex uh sync uh sync uh

what is it mutex there we go and then I

have this one mutex that exists right

here right I'm doing an inline one right

there we go this thing right here I now

have this one mutex that when I call

this one particular function I then can

lock and unlock which I think is a much

better way to do things it's yes it's

more air prone for sure but it allows

you to choose when lock happens mutex in

instruct makes sense yeah I think it I

think it's the better way uh is there a

case where a mutex lock being error

wouldn't be we would crash the whole

program I do not know when that would

happen to me if my mutex I got a

poisoned lock like that whole thing is

just done various readers and uh a

single writer is a good example of this

exactly like you don't need you don't

need this super complex like I don't

need my whole struct wrapped into mutex

to access because then if you just want

to access a read value and you have

rights coming in you have you can do

readwrite Locks but still you have to

like interweave them or you could just

have a bunch of methods that that do a

bunch of reading and then one uh than

one that does that uh mutex uh in a

struct feels like a design smell it

doesn't feel like a design smell to me

at all it feels like you're designing a

program you're designing a program that

makes perfect sense right and to me

that's just I I like that I like it I

like it I like it uh go routine

lifetimes are important to manage but go

gives you uh context context and says

good luck yeah I mean you already made

that you made that point earlier up here

I think um I'm not sure I I don't know

how I feel about context yet I'm still a

newbie when it comes to passing around

context and really taking that into

consideration my program I'm still a

noob so I don't have a I don't have like

a good feel for that yet seemingless

endless PR comments this function method

constant struct field return value is

unused uh this is great I love that uh I

also hate it but I love it did you mean

to initialize this struct something uh

something zero values are

useful uh are zero values ever useful I

don't know maybe uh don't export this

mutch struct field method yeah I mean

but you just didn't export it come on uh

something to do with uh constraining

mutability okay that's fair I get it

that go lets you have more mutability so

it is harder so I I do I do understand

that import ordering I've never had that

as a problem uh things from effective go

that could be built into tooling okay I

mean that's just a a tooling issue maybe

but that's if effective go is considered

the the deao standard uh other notables

defer almost makes me let's see makes

the suck list for me in a large codebase

it's frequently cause contributing a

contributor to

issues I feel like I I want to say I

agree with this one I do want to say I

agree with this one I do want to say I

agree with this one just because it is a

pain in the

ass to deal with defer why is my cursor

flickering it flickers only over HDMI I

don't I don't know

um because I've been bit by the defer

many many times s like it's it's weird

to me to have a

server that you have to

close when it's when the program ends

like that's one thing I like about rust

is the Drop Like drop closes the server

you know what I mean like Drop closes

the server so it's like why why do I

have to deal with with that drop is a

trait in Rust I know and so I love I I

like that defer makes a foray yeah yeah

it's not about having to close it it's

about clean up since there are no

destructors yeah exactly I don't know

how I feel about that like destructors

are interesting shall we say I I know

they're a pain in the ass and there's so

many like the the inverse ordering of

destructors and all that stuff could be

a huge like a huge source of bugs but

they're also really nice but defur is

used for so much more than closing

connections I know it's used for closing

files it's used for a lot of things ass

mentioned so much ass being mentioned um

I don't know I'm not sure how I feel

about it yet I'm sure there's some good

cases that I'm missing but defer I can

find that to be it's both really really

fantastic and it's a really big pain in

the ass go format and go vet could be

much better yeah I mean that's a

personal opinion thing I do agree like

me personally the fact that like

something that I will never like about

this there's nothing you can convince me

to like this

uh like uh sorry wrong casing to screw

off all right

uh like this

um oh I can't even format right

now like that there you go that's the

one I'm looking for like that I hate

that I hate that I hate that I hate

that I swear there's sometimes where it

it puts the plus sign right next to it

as well but I hate that I hate I hate

that it takes away the spacing like it's

not that I dislike it it's that I hate

it which is much different

there's a huge differ a huge difference

between me just like it's actually

anyways that's like one thing I hate so

yes I I I I do agree with that one

statement I hope you never need to check

the return value of timer uh time timer

stop I didn't even know there was a

return value uh future you will

appreciate if you start passing context

in time as an argument starting today

okay I don't understand the time part

but okay a context I know I need to

start using it more but I don't uh but

that's more like just creation uh your

time will come where you don't capture a

loop variable that's gone that's a gone

one you know what I mean this is no

longer a problem one 122 solves that one

122 actually properly uses it some of

these might uh let's see some of these

things might not be things that suck

about ghost specifically I wrote what

first came to mind okay I mean I like

this list I like some of the lists some

of them I don't like overall pretty good

critiques the thing is is that every

language sucks they just suck it just

sucks all the time and anyone that

thinks that that there's actually some

sort of Silver Bullet to make

programming nice dude someone's selling

you something you know what I mean

someone has

officially someone has officially sold

you something wait we got coffee again

me this account is such a troll account

this is such a troll

account they're mean to me um anyways

you just got to choose what you you just

got to choose what you saw dude look at

this you guys want to see something

that's totally messed up they're now

following me again that was nice of them

uh they quit following me for an

afternoon just to mess with me uh look

at that it just unfollowed me who does

that who does that who does that Adam is

so toxic I think that's the thing is

Adam is so nice on the internet because

he can be so toxic I did that yeah Adam

gets to be so toxic via terminal do shop

that he that he gets to be nice on the

internet and then just alt accounts

that was me look there's even Adam right

here I want the credit turd just a turd

okay yeah good list good list overall uh

follow terminal shop they'll probably

not follow you back uh the

name the name is the prime engine I do

like ghost I still highly recommend go

by the way I I've enjoyed it I've had no

problems with it I think it's just a

fine language I think any I think I I I

honestly think the biggest critiques

about go They're not they're they're

definitely not great it's definitely a

language that you learn with exper

experience and as you have experience

you avoid most of these problems um I'm

just trying to think of a language where

I I I don't have the same thing it just

looks different you know like honestly I

don't I don't know of a single language

that doesn't have the exact same

problems JavaScript has the same things

um rust has the same thing like rust

most certainly has it like you will find

yourself refactoring add infinitum like

forever you will you will refactor

continuously in Rust if if you don't if

it's the exact same thing you have to

know how to do the the the rust thing

right so like each one of them is is is

this you know each each one of them has

their own pain points so whatever the

name you know what the name is