シャドーイング練習: Go’s Big Mistake - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

各モードは全画面の練習ルームで開きます。

207 文

文が短すぎたり長すぎる場合は、Editをタップして調整してください。

It's been no secret that I love Go, okay?

I have spent many an hour programming on Go.

I built an entire whole, like, Doom, where a thousand people could play Doom all at the same time via Go.

I have been a big fan of Go for a very, very long time.

It was one of my go-to languages

that I would reach for whenever I'd want to build anything that kind of interacts with the command line, anything that needs to interact with the system.

Very quick, very simple, and honestly, I just have a lot of warm feelings about it.

But I do know it's a simple language.

There's nothing about it that was complex.

There was nothing about it that you could do or represent in a complex way.

And that's honestly been a huge appeal for me is

that I could do so much because all I would care about it,

all I would focus on is writing about the problem as opposed to solving the kind of ancillary problem.

And this has been the Go mantra for a long, long time, which is like you go into any Go project, pretty quickly you can feel at home.

Everyone uses the same formatter.

Every function effectively looks like you would write it to, everything is pretty constrained in the exact same way because there's really only one way to write Go.

But those days, they're changed.

And we're going to be doing a lot of yapping here.

So I hope that you're prepared because this is one of those passionate yaps where it's like, I feel like my childhood's being ripped away from me.

Okay.

Now, before we kick off this whole Go apocalypse that I'm going to be yapping about, I do want to kind of give you my first introduction to Go.

I think it was right around 2015, 2016.

I started writing Go a little bit more seriously.

And of course, I became so kind of go pilled

or go brained that there are certain phrases that I couldn't understand about other languages.

If you said it to me, like I wouldn't land on me.

A good example is I was at Facebook interviewing.

Yes, I interviewed for the performance team.

And during that time, they asked me a simple question, which was, hey, how do you return multiple values in JavaScript?

Now me personally, I'm in go land.

And I'm like, bro you can't do

that okay go has multiple return values javascript doesn't have multiple what the hell are you talking about

and of course then the person's they thought i was an idiot

because they're like you return an object to dummy or an array

and i'm like but that's one value and i just remember being

so offended by that that was just

so go pilled i couldn't hear what he was trying to say you get the idea i failed the interview

so massively on such a stupid thing anywho so my go days have been long.

I've really enjoyed it.

I've used it for quite a few years.

And I'd have to say, it's been one of my favorites.

Now, before we begin, I'd like to say thank you to the sponsor and a quick word.

Hey, do you like waiting?

Yeah, neither do I.

With Blacksmith, you get speed, 2x faster hardware, 4x faster cache downloads, and 40 times faster Docker builds.

So stop waiting around.

Use their migration wizard to easily transition your repos onto Blacksmith today.

Thank you, Blacksmith, for sponsoring this video, and you, check out the links down below.

All right, so welcome back.

It turns out that now go and go 1.27.

You can do generics even on method receivers.

For those that don't know, for a long time and go, you could only do it in functions.

If you don't know what a method receiver is, effectively, you can create a struct and something that looks like a function hanging off the struct would be a method receiver.

It'd actually be a function that's associated with some data, just like an object or a class.

And you could never do generics on that.

You can only just do it on freeform functions and that's it.

But now in our new world that we live in, you can now do it on everything.

So you can actually see right here, here's a result object, right?

And it can have a value V or an error error.

And I have an is okay function like, hey, are you okay if the error equals nil?

Yes, you are.

Okay, awesome.

You're okay.

And this is generic over the value V, which means I can also do things like this.

I can return a result of type foo, which means it has an error.

And then I can go in here and do all of this beautiful code where now I have a results object, which means I can write code that looks a bit more like this, I can convert a read operation into a result,

I can then string a fight from bytes, and then I can parse it, unwrap it and print it right here.

If my file contains an error, it's going to let me know, hey, there's an error in whatever you're attempting to parse.

If I jump back over here, go in here, jump this thing and say, turn it into 69.

Nice.

Rerun this thing.

You'll see right here.

Hello, 69.

Everything parsed fine.

So I know at this point, people are looking at this and going, hey, I kind of like that style of code.

This would be nice code for me to work on with going.

I do hear you.

This is generally nice code, but you have to kind of take a step back and understand go from the very beginning.

The very mantra of goes that there's one way to do anything.

Do you think that this is going to lead to one way to do something?

Or now you're going to have a cornucopia of different ways in which you're going to do stuff, you're going to jump into code bases and have no idea how they work, you're going to have to go through layers of abstraction

and whole new ways in which to express things in

which is just going to be like every other language just without all the conveniences.

A good example of that is if you wanted to do a you can't do like a generic convert function, where I can convert any function with any length of arguments into a result type.

So instead you have like convert one, convert zero, convert two, convert three.

I've tried many times to get some version of this working

and I could not seem to get this version of this thing working right here.

Whereas something like this in TypeScript, very easy to do, right?

Like, okay, there you go.

You can convert any amount of arguments into this.

And so it's like the actual genericism that Golang is providing is in fact not that good, but then on top of it,

It's just gonna make every code base completely different.

And this was the entire argument, by the way, as to why they were not going to do error handling.

Error handling has historically always been the butt of a joke for when it comes to Go, because if you wanted to do something like this,

print some you'd have to take the two strings coming in convert the first string into a number

which could result in an error because that makes sense right

if i try to convert hello into a number well it's not a number it's an error actually and

so there we go we have an area i convert b

that's into an error then i can finally print it then i can finally return

100

so that means this is air handling code air handling code air handling code

101

that means there are one two three lines of actual code,

102

whereas there's one, four, seven lines of code dedicated to air handling.

103

And this has always been the big problem.

104

Now, I personally have enjoyed this kind of air handling because that means every single time I do something that could air,

105

I know it and I have to explicitly handle it.

106

Now, granted, there could be some more ergonomics around it.

107

But nonetheless, I've actually really appreciated that about Go.

108

And the reason why they said no, hey, we're not doing fancy air handling, Okay, we're not going to be throwing in tries.

109

We're not going to be throwing in some sort of extra error capture up here.

110

No, we're not going to be throwing in little question marks like we're Rust.

111

Okay, we're not doing any of that shit, brother.

112

Okay, we're going to keep go, go, the end.

113

And honestly, you may not like that.

114

But to me, that is okay.

115

Because that is one thing I've appreciated about it.

116

Every code base is the same.

117

Now we have a whole new set of problems.

118

We now have iterator.

119

So now you're hiding what's actually happening.

120

Again, another thing I loved about Go.

121

everything you did, you understood the cost.

122

When you need to iterate over a list, you could understand what's happening.

123

Now, all sorts of stuff could be hidden from you due to iterators.

124

We now also have generics.

125

And in fact, this has led to a very good article called Go's evolving in the wrong direction because here's the deal.

126

If you want a fancy type system, don't use Go.

127

So now that they're adding all these features, you still get all the crappy type system of Go

128

that was good because of the way it was an unabashed procedural language, right?

129

It is purely imperative.

130

Nothing about it was fancy.

131

But instead, it's like you get Rust Lite.

132

You get kind of like the worst version of Rust or the worst version of TypeScript Brother.

133

If I wanted those, I should just go and use those other languages.

134

They have significantly better items to offer if this is what I was going for.

135

I used Go for what it was, not so that it could look like every other language just with the new set of syntax.

136

This is the thing that really bothers me about Go.

137

Go knew what it was.

138

And that's one thing that was very special about Go.

139

A strong standard library, a very simple language.

140

Now, yes, could they have made error handling better?

141

Absolutely.

142

Could they have made enums of any kind?

143

Absolutely.

144

And I think that would have dramatically made people's life better.

145

But they didn't.

146

They have chosen to actually add to the language ways in which make it so that

147

every code base is going to be so bespoke now and so much different.

148

It's going to be so much more frustrating than it used to be.

149

Go is no longer the language I like.

150

I don't want to use Go anymore.

151

In fact, I kind of found its spiritual successor.

152

So Odin right here, the language that you see right behind me, this thing I've actually really enjoyed because it reminds me so much of Go.

153

It has package level or directory level packages.

154

So everything inside a directory now shares all the types.

155

I really prefer that over file level modules.

156

I like package level modules or package level directories.

157

Oh, so much better.

158

It also has explicit overloading.

159

I really, really like that it does do some polymorphism, parametric polymorphism and all that.

160

But honestly, I rarely even feel like I need that.

161

I just program the problem.

162

And it works.

163

The language looks good.

164

It gives you complete control over allocations and how memory works.

165

And it's just so straightforward.

166

Absolutely lovely to work with.

167

And that's because Odin knows what it wants to be.

168

It's an unabashed, simple, C-like programming language designed and geared towards games and graphics and that kind of nature.

169

Go used to be the same thing.

170

It was a simple kind of system level, server level language that was designed to sit in this intersection.

171

Instead of being like complicated Java land, you would have something super simple.

172

The build tool, the formatting tool, the how you run it, all into one.

173

It was a self-contained, self-packaged language with a very minimal package management system built into it such

174

that you didn't actually overrun your project.

175

Like it knew what it was.

176

But now for the first time, I feel like Go is having its spiritual crisis.

177

It doesn't know what it wants to be.

178

Now apparently it wants to be Rust.

179

It wants to like, okay, I guess we have C++ Lite now.

180

Fantastic.

181

That's all I've ever wanted in life, right?

182

I just wanted another thing in which I can have massive abstractions

183

and find myself tight masturbating all day instead of actually solving the problem at hand.

184

Thanks, go.

185

Anyways, I say all this because I'm just getting all fired up

186

because it's like one of the languages that I found very appealing due to how different it was from everything else.

187

Like I knew that when I used it, I was solving a specific problem.

188

And it was like the best tool for the job.

189

Like it had this very nice kind of one to one reach.

190

And now like Odin, it feels like that too.

191

It's a very, it has this very defined purpose.

192

And I feel like I can just reach for it when I need to solve a certain problem.

193

I don't feel that anymore with Go.

194

And it just makes me feel a little bit funny.

195

I don't know.

196

Well, hey, you know, I'm supposed to do this as a YouTuber.

197

Yo, hey, bro.

198

Hey, what's your opinion on this?

199

Honestly, I'll read them.

200

Lay me down some opinions.

201

Maybe smash that like button in the subscribe or something like that.

202

I haven't asked for this in a long time, okay?

203

I haven't asked for this in over 130,000 subs.

204

So why don't you just do it?

205

For old time's sake, okay?

206

Me and you, we're going to feel better together.

207

The name is The Primogen.

アプリをダウンロード

流暢に話すために必要なすべて

AI発音採点文ごとに採点

IPA練習すべての音をマスター

単語学習自分の単語帳を作る

単語ゲーム遊びながら覚える

QRをスキャン

Download on theApp Store Get it onGoogle Play

同じチャンネル

FOR YOU

文脈と背景

この動画では、Goプログラミング言語に対する著者の情熱と、それに伴う経験についてのストーリーが語られています。彼はGoを非常に愛しており、特にそのシンプルさや使いやすさを強調しています。彼の日常におけるプログラミングの一部として、Goがどのように役立ったか、また特定の技術的な質問に対して自分の視点がいかに影響を受けたかについても触れています。このような背景を理解することで、英語スピーキング練習において彼の言葉がどういった意味を持つのかが明確になります。

日常コミュニケーションのための5つのフレーズ

「私はGoが大好きです。」 - 自分の好みや興味を表すフレーズ。
「Goは簡単な言語です。」 - プログラミング言語の特徴を説明する時に使える。
「多くの時間を費やしました。」 - 時間の使い方について話す際の表現。
「同じ方法で書くことができます。」 - プロセスや方法の一貫性を強調する表現。
「私は面接に失敗しました。」 - 経験を共有する時に適切なフレーズ。

ステップバイステップシャドーイングガイド

この動画の難易度に取り組むための具体的な手順を示します。英語スピーキング練習や英語シャドーイングを通じて、リスニング力と発音を向上させるためには、以下の手順が役立ちます。

まず、動画を数回視聴して全体の内容を把握します。主なトピックや著者の感情を理解しましょう。
次に、重要なフレーズや表現をメモします。例えば、「Goは簡単な言語です」といったフレーズを実際に声に出してみましょう。
聞き取った内容を繰り返し発音することで、発音の改善と流暢さを得ることを目指します。「shadowspeaks」を意識して声に出すのも効果的です。
聴き取れなかった部分があれば、再度その部分を集中して聞き取り、何度も繰り返します。これはIELTS スピーキング対策にも非常に有効です。
最後に、録音して自分の話し方をチェックし、改善点を見つけましょう。YouTubeで英語学習を行う際の重要なステップです。

これらの手順を実践することで、英語のスピーキング能力を高めることができるでしょう。

この動画の文法

話し手がよく使っている文型を、動画の実際の表現とともに紹介します。

文型	動画での表現
「used to」 used to + 動詞 — 今はもう違う過去の習慣や状態	used to be
現在完了形 have/has + 過去分詞 — 過去の出来事が今も関係している	It's been · have spent · have been
関係詞節 who / which + 節 — 人や物について情報を加える	time, which is · question, which was · foo, which means
受動態 be + 過去分詞 — 誰がするかより、何が起きるかに焦点を当てる	being ripped · could be hidden · was designed

シャドーイングとは？英語上達に効果的な理由

シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。

シャドーイングのやり方: ステップ別の完全ガイドを読む →

シャドーイング練習: Go’s Big Mistake - 動画で英語スピーキングを学ぶ

練習モードを選ぶ

アプリをダウンロード

同じチャンネル

It’s not just you

This is Crazy

He Realized his Mistake

People Are Mad They're Told to Learn

Maybe we were wrong

You won't fall behind

He’s always wrong

Github are you joking?

Casey Muratori Judges Our Digging Games | TheStandup

おすすめ動画

Fluent Forever

초면인데 왜 반말하세요?ㅋㅋ أشياء ما راح تفهمها إلا إذا تعلمت كوري 🇰🇷

So I tried Matt's skills...

We Let $200 GPT-Pro Think for 7 Days on Unsolved Math

I Was Going Somewhere With This

Podcast Chậm Rãi - Một cách học tiếng Anh mới cho các bạn đây | Tập 8

Why your best work happens when you stop taking it too seriously

Think Fast, Talk Smart: Communication Techniques

Once you see this, You’ll see Competitive Games Differently

Most devs don't understand what agents are

You're Not Behind: Become AI-Native (without the overwhelm)

文脈と背景

日常コミュニケーションのための5つのフレーズ

ステップバイステップシャドーイングガイド

この動画の文法

シャドーイングとは？英語上達に効果的な理由