Live data from Hacker News

Python Is Easy. Go Is Simple. Simple != Easy

preslav.me

301–310 of 313 posts

Re: Python Is Easy. Go Is Simple. Simple != Easy

#301
post #273

Earlier quoted context omitted.

One day is not enough to even get a superficial understanding of any language. People tend to always exaggerate how little time it takes to learn a language to a meaningful degree. Sure, the first day I tried Go I was able to accomplish something useful, but it took me a few months to develop a basic understanding of how you use Go in an idiomatic manner. I'd say it took at least a couple of years before I could say…

I disagree; you can learn 90% of Go in an afternoon. However, you also do have a point; the power of Go is not apparent in an afternoon, but in longer term and larger projects spanning years or decades, and hundreds or thousands of developers. It was made by and for Google to solve Google's problems, which include millions of LOC written and read by thousands of engineers over the span of decades. So while at first y…

> I disagree; you can learn 90% of Go in an afternoon.

Learning a language only starts with knowing the formal spec. Then you have to learn how to express yourself efficiently and in mechanical sympathy with the language. That takes time. Worse yet, a significant portion of developers can't do it without a lot of help.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#302
post #37

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…

I used Go for many years. My issue is that it's _almost_ a great language, but in its current version it's just a collection of foot guns that makes it difficult to get shit done. Go doesn't have some of the most library functions, so large codebases shared between teams end up with a dozen different implementations of functions like "minimum" or "filter". Good luck debugging a bug in one of the implementations. The…

> There's no way to ask for a not-null pointer at the type level, so you have to check for nullity everywhere and good luck debugging those runtime panics.

You can write a simple Option type yourself using generics [1]. It's not strictly idiomatic and you do have to remember to use it, but it works well.

[1]: (my post) https://news.ycombinator.com/item?id=38331565

Re: Python Is Easy. Go Is Simple. Simple != Easy

#303

The sad thing is that many people make language decisions on the beginner topics like syntax , literals, hello world or trivial samples. Sure a 20 line python app will be 40 lines in Golang, but that doesn’t mean 10k lines of python are 20k lines in golang. And there are way more serious considerations than LOC. Golang concurrency is amazing. You can reproduce an entire multi-core application stack with concurrent IO…

My experience translating a codebase from Python to Golang (chat application), is that 20k of Python really does translate to around 40k of Golang to get the same functionality. And it’s not just due to language but also expressiveness of the library ecosystem.

I very much doubt that.

"The man barrier to translation was that, while at 14KLOC of Python reposurgeon was not especially large, the code is very dense. It’s a DSL that’s a structure editor for attributed DAGs — algorithmically complex, bristling with graph theory, FSMs, parsing, tricky data structures, two robot harnesses driving other tools, and three different operator-composition algebras. It became 21KLOC of Go." [1]

[1]: https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...

Re: Python Is Easy. Go Is Simple. Simple != Easy

#304
post #271

Earlier quoted context omitted.

Language design is always easier in retrospect. It is harder than it looks, and often harder than the people designing a language realize before it is too late. I think it was a good choice to take smaller steps and try to not be too ambitious too soon. Sure, Go isn't the most sexy language from an academic point of view, but it has a certain conservative and pragmatic approach that does work. It does generally resul…

> Go is an engineering language - not an academic exercise. Great summary. I personally think Scala is the antithesis to Go, it being an academic exercise - with complexity and tooling to boot. re: Java generics, I've got this comment from 2015 bookmarked, it's a great explainer about the decision process behind adding generics to Go and the problem(s) with Java's implementation: https://news.ycombinator.com/item?id=…

Thanks for posting that link. It lead to a lot of interesting background material! I think this quote in particular resonates:

  > those ideas simply haven’t had time to pass through the filter of 
  > practical experience

Re: Python Is Easy. Go Is Simple. Simple != Easy

#305
post #197

Earlier quoted context omitted.

I could address each of these "issues" but I'd rather focus on the following: > The language itself is extremely poor > I think this is not something most Python users are aware of These two statements are contradictory. If it was indeed so "poor", people would notice :) If they instead increasingly adopt it (out of appreciation, not because they are lobbied into doing it) it becomes really difficult to logically dem…

> These two statements are contradictory. If it was indeed so "poor", people would notice :) Would they? The history of programming is full of great ideas that took a very long time to reach mainstream adoption. We also did some things that in hindsight were bad ideas, but for a time were very popular. This is because the programming language "market" is not rational. It moves at the speed of education, not the speed…

I don't claim that Python is the perfect language and it will never be replaced, in popularity, by something that is better.

What I'm saying is that considering Python a bad language, just because there are some languages that improve on some of its shortcomings, is just wrong.

As of today, Python is the most popular, hence (as a corollary) the best choice for most people. One day that might change, sure. These aren't mutually exclusive.

I don't agree with the claim about the market not being "rational". Someone who adopts Python even when given requirements that are clearly beyond the language's capabilities isn't going to last long in such market (and neither will their choices).

On the other hand there are plenty of people (myself included) who prefer using Python whenever possible, even though they have been "educated" in the use of other languages (I'd say I'm fairly comfortable with Typescript or even C building non trivial systems). I guess I'm not innovative enough :)

Re: Python Is Easy. Go Is Simple. Simple != Easy

#306
post #304

Earlier quoted context omitted.

> Go is an engineering language - not an academic exercise. Great summary. I personally think Scala is the antithesis to Go, it being an academic exercise - with complexity and tooling to boot. re: Java generics, I've got this comment from 2015 bookmarked, it's a great explainer about the decision process behind adding generics to Go and the problem(s) with Java's implementation: https://news.ycombinator.com/item?id=…

Thanks for posting that link. It lead to a lot of interesting background material! I think this quote in particular resonates: > those ideas simply haven’t had time to pass through the filter of > practical experience

I remain somewhat unconvinced on that front. There were good implementations from outside the functional programming sphere (which seems to be what people from the Go space tend to mean when they say "academic") already existing at the time. I think the real problem is that the most well-known examples, C++ STL and Java 5 generics, were trying to stick generics into an existing language with a "some things are objects and some things are not objects" type system. My take on the story there is that generics called attention to some deep deficiencies in that kind of type system, and people responded by shooting the messenger.

Languages like C# (which I've used extensively) and Eiffel (haven't used in anger), on the other hand, have a consistent type system, and didn't seem to have the same problems with generics that Java and C++ did. Or for a non-object-oriented model that has some other features that might be attractive to Go, such as not allowing implicit specialization, there's Ada.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#307

Earlier quoted context omitted.

To be fair, most million plus LOC projects match “misfortune” and “nightmare”.

Go is verbose, a million plus LOC doesn't go as far as it would otherwise.

I don't know, my experience with mega SLOC projects were Java, so verbosity was also a thing.

Go's verbosity is usually found in multiples (if err), not in long forms (int[] arrayOfIntegersWithValuesOneToFive = new ArrayFactory().createArrayWithSize(5).populateWithValues(1, 2, 3, 4, 5); ).

Re: Python Is Easy. Go Is Simple. Simple != Easy

#308
post #32

Earlier quoted context omitted.

The way I describe it is that Golang is optimized for reading, other languages are often optimized for writing. If you have to deal with someone else’s codebase, then Golang is a godsend. I also like that you pointed out that every Golang codebase looks the same. I think part of that is that Golang’s formatter can’t be customized. I pushed for that to happen in Rust but lost the battle.

I read a lot of code. Reading Go is painful because I have to parse whatever open-coded version of standard algorithms or error handling the developer chose to use that day.

I used to read code for a living (security consultant) and I'll ask you this question: you're being thrown in a codebase and you need to understand it in a week, what code do you wish the codebase to be. I'll give you the answer: it's going to be the language you work in, and then Golang if it's not the language you work in.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#309
post #54
post #32

Earlier quoted context omitted.

The way I describe it is that Golang is optimized for reading, other languages are often optimized for writing. If you have to deal with someone else’s codebase, then Golang is a godsend. I also like that you pointed out that every Golang codebase looks the same. I think part of that is that Golang’s formatter can’t be customized. I pushed for that to happen in Rust but lost the battle.

I've actually found Golang codebases to be the hardest to read, mostly due to the non-locality of effects from channels. It's just to easy to read a line of code and not know where to move next.

I would argue that code with channels are hard to read in any languages, not just Golang.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#310

Earlier quoted context omitted.

Exactly. Code is read WAY more often than it's written. Go is verbose, that's true. And if the speed of writing code is the biggest hurdle in your productivity you're either a true 100x coder savant or deluded. Go is boring, boring is good when you need shit to work every time. And especially when you can't pick the top1% geniuses to work on it and might need to bring some rando up to speed to the project AND languag…

Go is verbose. That slows me down when I’m _reading_ code. Especially when it means the chunk of code I’m reading doesn’t fit on my screen.

Java is verbose, C++ is verbose, Golang is not. Golang actually cared about verbosity. For example, uppercase letter means that your function is exposed, no keyword!
Post reply on HN