Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twelve Years of Go

go.dev

Post reply on HN
Print view View original

51–60 of 244 posts

Re: Twelve Years of Go

#51

Post by morelisp »

mseepgood wrote: post #38
AtNightWeCode wrote: post #26

Earlier quoted context omitted.

What you learn at school when it comes to programming is to avoid if-statements for control flow. It is error prone. If-statements are mainly used for various types of guards.

'if' is the epitome of control flow (next to looping). It's fundamental to computer programming. It's honest. Don't be ashamed of control flow, don't hide your control flow as if it didn't exist.

> It's fundamental to computer programming.

I'm weakly pro-if, but no, it's not. We went a lot of years without it, and some rending and gnashing accompanied its introduction.

Re: Twelve Years of Go

#52

Post by Thaxll »

AtNightWeCode wrote: post #37
nineplay wrote: post #25

Earlier quoted context omitted.

Error handling is easily one of my favorite things about Go. No 'oops I forgot to put in a try/catch and now my code died with no explanation'. No 'I forgot a finally ( or didn't realize I needed one ) and now I'm leaking resources'. No 'should I return Null or false or an error code?'. No '20 log messages for the same error because every function is reporting it'. The Go model - Return err, always as the last parame…

1. You have something that catches and logs all uncaught exceptions. 2. Defer is nice. As easy to forget as using in C#. 3. Always null/nil. Uncle Bob is plain wrong here. 4. Stack trace. But you should keep things wide and shallow. No matter what technology you use. In Go it is about as easy to swallow errors as with try-catch. But my post was more about how all the if-statements generates more unnecessary if-statem…

1. In most web server you have a panic middleware that does exactly that.

By default in Go uncaught panic go to stdout.

Re: Twelve Years of Go

#53

Post by JimiofEden »

0x008 wrote: post #39
jstx1 wrote: post #9

I’ve only picked up Go recently and I must say that the beginner experience is superb. Way easier to get started, learn new concepts and put them in use compared to some other languages.

can you recommend any video lectures?

So it's not a video lecture on Go specifically, but I first started learning itbecause I saw how it looked and how fast it ran while watching a Dynamic Programming series that happened to use Go for its implementations.

https://www.youtube.com/watch?v=jTjRGe0wRvI&list=PLVrpF4r7WI...

From there, I started reading about it more seriously here: https://golangbot.com/learn-golang-series/

And I've been using it and loving it ever since. There are one or two things that trip me up (slice manipulation can sometimes get me if I'm not paying close attention to my capacity and just pointing around, rather than copying) But for the most part, it's a fairly elegant language, and amazingly fast! For me, it's also been incredibly intuitive start working on asynchronous features.

The new inclusion of Generics is just icing on the cake.

Re: Twelve Years of Go

#54

Post by caente »

jrockway wrote: post #29

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading i…

> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible (...) they should be impressed by what the program does for them, not what language features you used to implement it.

Interestingly, what made me go through similar evolution was the very language in which I was trying to do all those things, namely Scala. After a few years of trying to be "smart", I realized that the problem was usually bigger than the language.

So perhaps, it wasn't Go, nor Scala, who helped us in our realization, but life and experience?

Re: Twelve Years of Go

#55

Post by ohCh6zos »

handrous wrote: post #30
ohCh6zos wrote: post #19

Earlier quoted context omitted.

Programming is always going to be complicated as long as the domain is complex. Go as is has traded having no learning curve for having nothing to offer.

What it offers is that code you didn't write is significantly easier to read & understand than in most languages.

This hasn't been my experience. Go is incredibly difficult to read because all Go code looks the so similar, lacking intentionality or style, and it's so verbose that it takes a very long time to grasp what any given thing does in totality.

Re: Twelve Years of Go

#56

Post by quadcore »

jrockway wrote: post #24
quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

If you want to write unmaintainable code in Go, it's already very easy; just use interfaces incorrectly. Go lets bad programmers write bad programs. If you have a solution to that problem, your programming language will be the one that kills all current programming languages. Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let goo…

Everything you say compfort me in the fact this is going to be bad. Everything I read in the article about generics compfort me in the fact this is going to be bad.

Example: first you agree with me "its already easy to write bad code", well you agree then its gonna be easier. Your example about io.Copy. Yeah bingo, absolutely io is the exception, the only case I know in 25 years of programming that is made tasteful with generics. Actually its the only case I know in 25 years of programming where a diamond-like multi inheritance structure is okay. IoBase, IoBaseRead:ioBase, IoBaseWrite:ioBase, Io:ioBaseRead, ioBaseWrite. You get the idea.

Do you realise the language grammar is modified? They are modifying Go's grammar. Man, they gotta have some balls to make virtually a new language after 12 years of success.

Im open. I am. But the idea is bad on paper, now the signs are too.

Re: Twelve Years of Go

#57

Post by dhagz »

princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

I only use Go for two things: CLIs and web services. There are a lot of frameworks out there to help you develop web services in Go, but what really impresses me is that you don't really need them - you can get surprisingly far just using the standard library.

Re: Twelve Years of Go

#58

Post by kryptonomist »

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters.

Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you deal with complicated OS level calls, memory and library deployment issues (problems fixed by Go). Yes, a few benchmarks show C#/Java almost as fast, but at the price of a highly optimized syntax not seen in any average programmer. An average guy get superb performance with Go without complications from day 1.

And absent object oriented features are quickly forgotten.

Re: Twelve Years of Go

#59

Post by machiaweliczny »

jrockway wrote: post #24
quadcore wrote: post #12

I cant believe they are moving forward with "generics". Programmers on average already tend to make things more complicated than they should be. Now every single module in the ecosystem is gonna use more abstractions, generics to fit their social environment. Its well known that abstractions are the devil. How many modules are gonna use generics when they should not? Most? Programmers are bad at programming and they…

If you want to write unmaintainable code in Go, it's already very easy; just use interfaces incorrectly. Go lets bad programmers write bad programs. If you have a solution to that problem, your programming language will be the one that kills all current programming languages. Generics will be similar; people will misuse them, and you'll curse their names when you have to dive in and debug it. But it will also let goo…

Elm kinda had such guardrails but they are hindrance, so it's all about balance (or letting them off purposely - which makes lang implementation hard as you need to compile half-broken programs). That's why I think interpreted code will win due to productivity gain or we get something that compiles even faster than Go or real hot-reload.

Re: Twelve Years of Go

#60

Post by princevegeta89 »

pphysch wrote: post #33
princevegeta89 wrote: post #27

Would you say Go is suitable for web services and apps? I was trying to compare it with a rapid development framework like Rails but felt Go Web Frameworks aren't as mature and ready like Rails. Any insight would be appreciated, thanks!

Definitely suitable. Depends if you want to work within a framework or not. If you want a framework, use Rails/Django/Node as they are very mature. Huge plugin ecosystems, great for prototyping non-trivial features like authn, because a plugin certainly exists for it. If you want more control (fewer dependencies), roll everything yourself with Go. The built-in libraries are fantastic, you can spin up a CRUD app witho…

Thanks. How about a framework which has all these things stitched together already? For example, a good templating engine and an ORM that supports DB migrations out of the box? Do we have one for Go?
Post reply on HN