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

Go is not an easy language (2021)

arp242.net

Post reply on HN
Print view View original

21–30 of 37 posts

Re: Go is not an easy language (2021)

#21

Post by kevincox »

HenriTEL wrote: post #20

pop() would have been a much better example, as ruby providing delete_at is a mistake IMO, since it runs in O(n), chances are that you're using the wrong data structure. Go providing append but not pop is inexplicable

There are many, many situations where delete_at is a completely reasonable operation. It may be O(n) but it is a blazing fast O(n) as it is just a memmove. For example if you are writing a TODO app and you want to delete a task it is likely a very acceptable solution. You would need millions of tasks before you couldn't remove it withing a few milliseconds. Most other solutions even though they have better time complexity would be slower in practice. (But benchmarks would be needed to verify this).

I would say that the biggest concern with delete_at is if you are using it inside another O(n) loop, then it becomes O(n^2) which does scale up fast enough to become a performance issue.

Re: Go is not an easy language (2021)

#22

Post by myaccountonhn »

dtdynasty wrote: post #3

I was writing a more involved change in golang for the first time and was surprised to find golang didn't support higher order functions like map and filter. It's not a big deal to have to implement them in a custom for loop but for a language that sells on simplicity, I was surprised to find these missing. I guess I have a different idea of simple than the golang team.

I can appreciate Go's design philosophy of simplicity and emphasizing fast tooling + one way to do things.

But as someone who has done a ton of functional programming, to me it is just too conservative of a language. There actually has been progress in the PL space the past 50 years, and I personally prefer a language that includes them.

I think OCaml strikes a better balance between power and simplicity, it is probably the closest to Go in the functional programming space (and is also a systems language). It has a blazingly fast compiler, it's easy to understand how it executes things, compiles down to a single binary, the tooling is good. Very similar advantages to Go.

Re: Go is not an easy language (2021)

#23

Post by remus »

diarrhea wrote: post #13
bborud wrote: post #11

People tend to underestimate how much effort it takes to a) learn how to be a good programmer, and b) learn a given programming language. Sometimes they confuse the two.

Yeah. Tons of people claim to be able to pick up languages within a week, or a month. I’m convinced it takes at least a year to get out of beginner status, even for simple languages. I’m including things like knowing the ecosystem and popular libraries (http server and clients, ORMs, testing frameworks, …) in that.

Yeah, I often wonder what threshold people use when they say they picked up a language in x hours/days/weeks. I guess it's largely a matter of opinion, but like you I consider a working understanding of the standard library, popular packages in the ecosystem etc. to be beginner level stuff, and for me it takes at least a few months to start getting a grasp on these things (especially in something like go which has a pretty big standard library).

Re: Go is not an easy language (2021)

#24

Post by pjmlp »

graemep wrote: post #12
The_Colonel wrote: post #9

Earlier quoted context omitted.

Higher order functions are not easy to grasp for beginners, but once you do, they simplify reasoning about the code a lot. Go is targeted at system programming, which is a domain in which you need pretty advanced developers. But the language feature seems to favor use by absolute programming beginners. It's a trade-off which seems somehow inverted.

Go was designed to be easy to learn for inexperienced developers. Is it actually intended for systems programming? Its main (and intended) use seems to be a faster and better at concurrency and parallelism alternative to Python, Ruby etc.

Rob Pike was after C++ programmers initially, turns out that naturally the language isn't appealing to that community.

> Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Re: Go is not an easy language (2021)

#25

Post by arp242 »

HenriTEL wrote: post #20

pop() would have been a much better example, as ruby providing delete_at is a mistake IMO, since it runs in O(n), chances are that you're using the wrong data structure. Go providing append but not pop is inexplicable

There is nothing wrong with O(n). It can be faster than O(1) depending on the size of n and what you're doing (small arrays are usually faster than hashmaps for example).

Big-O just tells you how something scales. It doesn't really tell you how fast something is.

Re: Go is not an easy language (2021)

#26

Post by cryptos »

Go is so minimalistic that it forces developers to reinvent the same things again and again. Just think about how common certain collection operations are and how easy they are in some languages (e.g. Java, Kotlin, C#, Rust), but in Go you'd write list and for loops like in the last century. This wastes developer time, makes the code harder to understand and adds chances for bugs.

So, this cite applies to Go: “Everything should be made as simple as possible, but no simpler.”

Re: Go is not an easy language (2021)

#27

Post by kramerger »

dtdynasty wrote: post #3

I was writing a more involved change in golang for the first time and was surprised to find golang didn't support higher order functions like map and filter. It's not a big deal to have to implement them in a custom for loop but for a language that sells on simplicity, I was surprised to find these missing. I guess I have a different idea of simple than the golang team.

Go is not a functional language.

The most common complaint against Go seems to be "My favourite programming language has X, why doesn't Go has X??"

There are things I would like to see in Go (e.g. real enums and the ? operator for error handling), but I DONT WANT Go to become a copy of C# or Haskell...

Re: Go is not an easy language (2021)

#28

Post by nickd2001 »

cryptos wrote: post #26

Go is so minimalistic that it forces developers to reinvent the same things again and again. Just think about how common certain collection operations are and how easy they are in some languages (e.g. Java, Kotlin, C#, Rust), but in Go you'd write list and for loops like in the last century. This wastes developer time, makes the code harder to understand and adds chances for bugs. So, this cite applies to Go: “Everyt…

As someone dabbling in Go, still a n00b really, but experienced in many other languages, I find this too, why's there stuff that's just standard in e:g Python, yet missing in Go? Apparently a thought-out, deliberate decision by the language designers. But then, since many people feel this way about Go, I'm mystified that 3rd-party libraries haven't evolved to cover "missing features" of Go. One would think, someone will scratch an itch, release it, then everyone uses that. Seems to have happened in other languages. Weirdly, there are indeed 3rd-party libs for Go that do more sophisticated things, web frameworks etc. Its almost as though 3rd-party devs don't dare touch the lower level stuff cos that's "against the spirit" of Go, but do make reusable libs for higher level things. Well, this comment may reflect my naiveté / ignorance of the language. Maybe someone else will clarify this? ;)

Re: Go is not an easy language (2021)

#29

Post by bborud »

remus wrote: post #23
diarrhea wrote: post #13

Earlier quoted context omitted.

Yeah. Tons of people claim to be able to pick up languages within a week, or a month. I’m convinced it takes at least a year to get out of beginner status, even for simple languages. I’m including things like knowing the ecosystem and popular libraries (http server and clients, ORMs, testing frameworks, …) in that.

Yeah, I often wonder what threshold people use when they say they picked up a language in x hours/days/weeks. I guess it's largely a matter of opinion, but like you I consider a working understanding of the standard library, popular packages in the ecosystem etc. to be beginner level stuff, and for me it takes at least a few months to start getting a grasp on these things (especially in something like go which has a…

As you point out there's a lot to cover. There's the language, the libraries, and the tooling. Then there's learning how different people use the language. The stylistic elements, how to play to the strengths of the language, how to deal with the shortcomings etc. All that takes time because you have to gain some experience with all of this. Even the things you figure out aren't very good.

The reason it took me a long time to learn Java is because when I started learning Java there was a certain way to architect Java systems. And to be frank, the way Java was done in the 90s was horrible. Lots of complex boilerplate, lots of structure and none of it seemed to pay off. And on top of that, most people still didn't understand OO all that well so you'd get layer violations and strong coupling all over the place. Making code really hard to maintain. (I used to ask people to read the first part of the GOF book, and forget about the rest of the book. Because at that point, the introduction contained the best explanation of OO we had found. It is probably still worth reading. Though the rest of the book led to a lot of silly dogmatism where some people suddenly behaved as if the patterns were the only allowable design strategies)

Then came the 00s with people adopting huge frameworks that in themselves took a lot of time to learn and, again, didn't produce the results we wanted. Worse yet, applications became hostages to these frameworks. Ever been faced with a few hundred thousand lines of code trapped inside a Spring-dictated architecture. That's really, really expensive to do something about.

It took a really long time to figure out a good way to do software in Java. It also took a very long time to re-train Java developers whenever we got a new hire. To teach them anything from "microdesign" (how you express things in Java) to how you design, plan and architect stuff without ending up with a lot of

Post reply on HN