16 ms·
Go makes it easier to write correct, clear and efficient code
- shusson 7y ago> Similarly, there is an error handling draft design than may replace the current bare-bones error handling. I actually really like the error handling in Go and think it makes it easer to write good code. At least for simple programs.
- founderling 7y agoI love programming languages. And I love to reason about them. When I see an article comparing languages, I'm all in. So I clicked on this one. Started skimming through it, looking for code. Found none. Came back here to share my disappointment. I'm always confused about articles that talk about code and have little code to show. Are there programmers who enjoy reading them? Or are these articles made for non-programmers? Another thing that always throws me off is fluff. The article starts with "Choosing a programming language isn’t easy.". What does this add to the article? It immediately makes me think the author stuffed this article for no reason. So I have to skim even faster to not being cheated of my time. Is there anybody out there who thinks having the article prefixed with "Choosing a programming language isn’t easy." makes it more valuable?
- csmnils 7y agoThere is little code in the main article, but there is a link to a detailed Java vs. Go code comparison: https://yourbasic.org/golang/go-vs-java/ https://yourbasic.org/golang/go-vs-java/
- wcdolphin 7y agoThat’s a bit of a straw man. 1. You are using go’s built in imaginary type, and writing one from scratch in Java. 2. That is no longer idiomatic Java. Use Autovalue and the comparison is a little more fair. The LOC and complexity still come out in go’s favor for this, no doubt. 3. Beating down on Java is fun, but with Kotlin interop and adoption rate, I think the comparison will become JVM vs X.
- tluyben2 7y agoHe even names examples he is comparing but the examples are not there; there are many links in there and I am not going to click them all... So why are those examples not there?
- bayesian_horse 7y agoProgrammers enjoy writing them and then have flamewars about the topic. But reading? probably not so much...
- rolleTx 7y agoBut it gives a lot of references to codes
- sacado2 7y agoThis article deals with "big picture" aspects, not specific syntactic details, so there is no reason for it to include code. Backward compatibility, compilation speed, circular dependencies, small vs big specs, etc. What code do you want to show about these aspects? > The article starts with "Choosing a programming language isn’t easy.". What does this add to the article? It's an introduction. It's a very common writing technique. You don't start with the core content of the article, you start with a paragraph or a sentence about why you wrote the article in the first place. You did the same with you "I love programming language" opening.
- founderling 7y agoBackward compatibility, compilation speed, circular dependencies, small vs big specs, etc. What code do you want to show about these aspects? Code that shows these aspects. What broke in Java because of language changes and why. How handling circular dependencies in one language makes code uglier then in the other. Examples of the specs. You did the same with you "I love programming language" opening. That I love programming languages and to reason about them is an information about myself that the reader does not know in advance. That choosing a programming language is not easy is public knowledge that the readers already know. At least if they are programmers. That is the point of my post. Asking who the target audience is. And how it is different from myself.
- setr 7y ago>That choosing a programming language is not easy is public knowledge that the readers already know. At least if they are programmers. Well that bit is certainly not true; passing by certain communities and you’ll be let known theres only one good answer: {lisp,c#,haskell,rust,js,c/++}
- chrismorgan 7y agoPlease do not use code formatting for quotations. Use the old de facto standard of a “> ” prefix.
- 7y ago
- vlthr 7y agoAren’t you being a bit uncharitable? - The article focuses on the properties of codebases, not individual code snippets. While it would be very valuable to do compare the properties of entire codebases, that is demanding on both the reader and the author. - Opening the article with a statement like “Choosing a programming language is never easy...” is an acknowledgement of the fact that he is not claiming Go is unequivocally the best in all scenarios. The author is signaling that he is a reasonable person, and while that may seem like fluff it is a necessary component of communicating with a wide audience.
- joppy 7y agoIf you think that somebody writing a 6-word sentence at the start of an article to set the tone is "cheating you of your time", perhaps stop reading random articles on the internet, and then also leaving comments about them.
- blablabla123 7y agoYeah but I think for non-trivial programs, say 10k+ lines of code, it's really difficult to show proper examples, not to speak of exhaustive coverage. Go in particular doesn't have many fancy language constructs and a lot of well written code in Go 1 might look a bit repetitive, especially the error handling. But once you wrote a larger program and followed best practices with error handling, you might be delighted how much more compact error messages are and still offer a lot of greppable things to debug after. Probably there are languages that have a really expressive syntax that solve problems also in a scalable manner. For instance Python with its list comprehension that are a real code and time saver for software that does a lot with lists. (No coincidence it's so popular with ML.)
- mratsim 7y agoIn ML you really want to use Numpy ndarrays, Pandas dataframes or Tensors. A list is much too slow because: - Not contiguous - No SIMD vectorization - No parallel processing Lists are mostly used for list of containers (for example storing the arrays inputs of a function)
- siscia 7y agoI do like go, but really this arguments start to be a little unprofessional if you ask me. All those arguments are fine and correct in small projects or libraries, there go is perfect. But they really don't hold on big project like docker or containerd. While it is clear what lines of code does, at a tactical level, it is extremely difficult to follow what happen in the big picture, the strategic level. Where the values comes from and where they go? When? How and why? Honestly I keep seeing this in all big go project, despite the lack of generics. Again if you need a small micorservice, use go! It is the best option right now. But I wouldn't bet any big codebase on it.
- kenhwang 7y agoI think complexity in software becomes difficult to grok as software gets bigger, and go does seem to go out of their way to code easier to understand at a hilariously micro scale at a huge cost at the macro level.
- sagichmal 7y agoAbsolutely the opposite. The ability to understand Go code seems roughly constant with regards to codebase size. On teams of enough engineers, especially as those engineers rotate in and out of maintenance roles, richer abstractions tend to obfuscate intent and hurt maintainability more than help it.
- stouset 7y agoI just don’t buy it. We already work at a layer dozens if not more abstractions away from what’s really happening underneath the surface. This is essentially an argument that every layer below is good and justified, but that any additional layer is just too much.
- PeterisP 7y agoFor complex, specialized systems what I'm often seeing is that essentially every decent large system gets split into a de-facto domain specific language (no matter if it's with language features or through some specialized libraries or webservices or whatever API) and the implementation of the business logic in that DSL. And, in general, the implementation of that DSL is something like ten times smaller than the amount of code using that DSL. The maintainability of the code is mostly determined not by how good the underlying language is but how good is that DSL. To take an example that's been widely discussed in HN, let's think about machine learning - the look, structure and maintainability of your code is highly influenced by the choice of your framework/"DSL" e.g. pytorch vs tensorflow1.x vs straight numpy vs Caffe will have major differences despite being in the "same language". And in that regard, the features of the core language matter only in regard of whether they facilitate making a good DSL. Of course, some languages fail because their choices result in the "core DSL" i.e. standard libraries that everybody uses being fragmented and confusing; Go has it quite good IMHO for the standard library; but for every specific domain it also matters if the DSL for that domain is good, whether it's an ORM layer or a OpenGL interface or a deep learning framework or an physics simulation library - whether the language abstractions mean that these DSL's (often being interfaces/wrappers to some third-party code written in another language) are going to be good and convenient, or whether the language structures limit the DSL so it becomes unwieldy to use.
- dvfjsdhgfv 7y agoThis is interesting: > The Python code snippet del a[i] deletes the element at index i from a list a. This code certainly is quite readable, but not so transparent: it’s easy to miss that the time complexity is O(n), where n is the number of elements in the list. Go doesn’t have a similar utility function. This is definitely less convenient, but also more transparent. Your code needs to explicitly state if it copies a section of the list. See 2 ways to delete an element from a slice[0] for a Go code example. But the examples given in [0] could also be implemented in Python as well with, I dare say, the same time complexity.
- akerro 7y agoAgree with the title, but I would like to add that learning Go (and Rust) made me look differently at many concepts in Java and made me better Java developer.
- ecmascript 7y agoNo matter how good Go is I would never use it just because it is from Google, a corporation I consider to be evil. Sure Oracle may not be the wonderchild, but at least they don't store everything they can about me without me having any say in the matter.
- chimen 7y agoDo you use React? MySql? VsCode? YouTube? Chrome? Not all departments have to share the same vision. Go is open source and its code up on a repository, open and visible.
- zelpo 7y agoIn other words, you cant escape the wrath of google, so what you should do is give up. It's like showing up at a Greenpeace march and pointing out to a protester they they are wearing shoes that were made in a facility that probably contributed to the destruction of the planet. Why bother protesting you imperfect hypocrite?
- Blackstone4 7y agoIf one wanted to hurt Google, stop using their products which generate revenue/profit i.e. Google Search, YouTube etc. For me Golang does not fall into this category.
- chimen 7y agoI'm not protesting anything. Sure I would like to use something else but I don't see any other search engine with better, more relevant results yet. Nor do I see a better video platform or a better webmail (I am being subjective here ofc). You can't tell people to give up good things just because [insert evil things here] and offer no better alternative. You can escape the wrath of google of course, there's always Bing, Duckgo and others; Python, Ruby, Elixir, PHP, Java; Proton, yahoo mail, Zoho; Vimeo, DailyMotion; Gmail, Search and Go (yes it's my fav language so far) runs or helps my business greatly and with a direct impact on my income so yes...I'll gladly share my fetishes with the big brother. I don;t want to but I have no better alternatives. Do you? I think your frustration comes from the fact that you want to avoid using their products but can't find better alternatives. Also, no need to call people names and...use your own username; don't go green in fear of internet points.
- i_phish_cats 7y agoI wrote a PDF parser in golang a few years ago and it was an extremely unpleasant experience. No polymorphism means I essentially have to cast everything to void* aka interface{}. Rewrote it in C (the rewrite was quite easy actually) which at least made the lib accessible to other languages.
- codr7 7y agoThere's plenty of polymorphism in Go, that's what interfaces are for. In C you would typically use a struct stuffed with function pointers, how is that an improvement? Its still a better C in many ways, strings and character sets is a big one.
- pishpash 7y agoIt's definitely a better C, but that's about it. Let's not kid ourselves. It's in many ways a language stuck in the past, for senile people, OCD's, or drones who are forbidden to produce non-uniformity and who want everything verbose and explicit.
- camdenlock 7y agoI kinda think /you/ are kidding yourself by making such wild assertions. I certainly do not agree with them, and I see no clear evidence to support them. There are different languages for different tasks. Tradeoffs abound. Pick the right tool, that’s all.
- codr7 7y agoLike C, you mean? How is it more verbose than C++, Java, Rust or Swift? You're not making much sense here, why do you feel so threatened?
- wtetzner 7y ago> How is it more verbose than C++, Java, Rust or Swift? All of these languages have generics.
- valw 7y agoAny comparison of languages in the form "language X is generally better than language Y" with no additional project context or problem domain is going to be an extremely naive one, to the point it's not relevant to anyone having to make pragmatic tech choices. This article is no exception. I'm not partial to Go, Java or Python, but I do wish this sort of article stopped making headlines, leaving room for finer analyses and experience reports. These are what we really need.
- bayesian_horse 7y agoMaybe it's because of the way my brain works, but I prefer clarity and brevity above almost everything else. That's why I like Python over Go, C# and others. Python lets me fit more functionality (expressed as code) in my working memory, and I have to ignore less line noise and boilerplate.
- erk__ 7y agoThe other side of the extreme is functional languages which have yet to have the big breakthrough in business.
- agumonkey 7y agoImmutability and recursion patterns do shrink the search space to a minuscule spot. It may fit ones brain. But some people have a state driven thinking process, which I despised for decades but recently got to understand. I see why people like to code in C-land. The issue is that, since it's not a straightjacket like ~pure FP, if you don't have a brain that sees state, state variable, lifetimes, etc etc, you're free to write piles of crap. Especially when young because you may believe that complex => more code, and complex is good. ps: note that I'm not criticizing FP or static/math oriented programming. I'm just trying to pu both sides into a shared perspective
- pishpash 7y agoThe real world has state. Mathematics don't. There are different domains in which different languages are most expressive.
- jcora 7y agoPure functional languages do have state. They don't have _implicit_ state. You can absolutely reason about state with mathematical abstractions, it's just not "free" and there's a learning/comfort curve.
- 7y ago
- KaiserPro 7y agoI think Go has many fun features. However, to argue that its easier to write "good" code, is hyperbole of the highest order. A programming language is a brush with which to paint your logic. If your picture is murky its because you, the programmer has made it murky. There are many tradeoffs with "good" code. Readability, speed, compactness, modularisation, use of libraries. As with any other practical subject, your skill comes from practice. Yes, new tools can make it _easier_ to be more efficient, or faster. They might even badger you into good habits. But They cannot make you "good". Its the expensive camera fallacy. Sure a Medium format SLR will take _spectacular_ pictures, but only if you use it properly. A good photographer will be able to take wonderful images using a camera phone from 2006.
- adrianN 7y agoSure, a great mechanic can use a hammer to drive a screw, but they usually choose more appropriate tools.
- KaiserPro 7y agoyeah, they'd use nails. Which underscores my point. When you are building a table in real life you make it all from one or two materials. You'd keep to one or two types of fasteners, because its simple quicker an easier. You don't change halfway through from turned oak to carbon fibre, "because its higher performance." unless you have a bloody good reason to change. Sure I've used screws as nails, it works pretty well, but we all know its a dirty hack.
- Rapzid 7y agoIt's worse to use nails as screws IMHO, but I digress.
- KaiserPro 7y agoTo underscore the point: The Python code snippet del a[i] deletes the element at index i from a list a. This code certainly is quite readable, but not so transparent: it’s easy to miss that the time complexity is O(n), where n is the number of elements in the list. Go doesn’t have a similar utility function. This is definitely less convenient, but also more transparent. Your code needs to explicitly state if it copies a section of the list. See 2 ways to delete an element from a slice for a Go code example. I think this assertion is wrong. del in python does exactly what it says it does. There are precisely three reasons to not use del: o Because you have written your program, got all the low hanging performance fruits, and now need to optimise how you delete from (large) lists, and dequeue doesn't work for you o you are arrogant and want to show everyone how clever you are because you understand how list operation are handled under the hood. So you have written your own. o a.remove()/a.pop() you think is more readable. It is far more important to be readable than to be fast in 90% of cases. If we all really cared about speed, then React/electron/et al would never be a thing.
- chvid 7y ago"Go makes it easier (than Java or Python) to write correct, clear and efficient code." I really appreciate taking a minimalist and opinionated approach to language design but all design choices done in Go comes at a cost and the above broad statement simply is not correct. And to me it just adds to the impression of the Go community of being on the immature and almost cultish side.
- pishpash 7y agoImmature or cultish might be too strong, but I will say it is very fitting for being a language associated with Google, which is also very opiniated and arrogant, but maybe 80% of the time right. It's that 20% of the time though that you hope for some humility and open-mindedness.
- sethammons 7y agoI did not use Java outside of school. I've rewritten and/or worked in rewritten codebase that started in async Python (Twisted) and async Perl (AnyEvent) and ended up in Go. I found the Perl much more approachable than the Python. However, Go allows my teams to actually know what is coming and going from a function, how code flows in the project, and makes concurrency easier to grok.
- jeswin 7y agoGo succeeded because it compiles to native code, has good performance and an efficient standard lib - but in spite of being a terrible programming language. There are a great many programmers who cared about producing great software rather dwell on the quality of PLs, and for these people Go hit a particular sweet spot. I have really tried to like Go, but the imperativeness is just something I struggled with. Even good Go code is littered with breaks, mid-function returns and imperative loops. For those who want cross-platform native code but find Rust too complicated, hopefully C# will fill the void once CoreRT ships.
- fxfan 7y agoWhen does CoreRT ship?
- navd 7y agoI hear this comment made often. For some people like me, Go is simple, and that makes it a great programming language. I definitely wouldn't call it terrible! Otherwise, a language is more than its feature set. A big part of what makes a language enjoyable is its culture as well. I think C# is a great language, but I prefer Go's culture much more.
- piano 7y ago> but I prefer Go's culture much more To me, Go culture is very arrogant, so much in fact that it almost reminds me of some Lispers of old. Unfortunately similar thing can be said about Rust. However, in Rust, most of the crap seems to be comming from zealous newcommers and a loud minority, while the leadership and people involved seem relatively humble (or at least not too arrogant). In Go, OTOH, the arrogance seems to be stemming all the way from the top, judging from some talks & blogs by Pike, Cheney et al. Pike in particular seems to me to be a very arrogant, unpleasant person. I respect him very much as an engineer, but I will never like the way he speaks, promotes Go and spreads FUD about other languages.
- pjmlp 7y agoMono is already a solution, no need to wait for CoreRT. Java has AOT compilers available since around 2000, just not for free. And there are plenty of other languages with AOT compilers to native code.
- hamilyon2 7y agoWell, arguments in favor of go are made up. For instance, you have to add literally one line of code to terminate Java application at the end of main function. Why would such a minute feature of language make Java programs harder to reason about? Why would anyone even present this argument as a serious one?
- JanSt 7y agoYes, Java does have its weaknesses. It's an old language and people were still figuring out a lot of the stuff. But the ecosystem is huge and if you know the quirks, it's still a heck of a productive language. > Java inner classes suddenly appeared in 1997; it took more than a year to update the specification, and it became almost twice as big as a result. That’s a high price to pay for a non-essential feature. I can't talk about the doubling of the specification but you can learn everything you need to about inner classes on 5 pages or so. It's over 20 years old now. > generic arrays aren’t supported So you can't use something with arrays that go doesn't even support ;-) > type wildcards with upper and lower bounds are quite complicated. Well, it's two words (extends and super) and some syntax. How could it be much easier? > Enum [...] It’s certainly nice to have, but offers little that couldn’t be done with ordinary classes Yes, and generics offer little that couldn't be done by implementing specialised classes. Enums are there to help you. You see an enum? You know what happens, you know what it offers, you know it's not a "normal" class but is there for a special reason. Yes, Java does have its inconsistencies. Why is String Immutable when in a OO-language the opposite would be taken for granted? Why can't you use int as a datatype for an ArrayList but Integer? What's up with Stack and Deque and Vector? You have to know Java to work with it effectively. We are professionals after all. It can be expected that we know the language. Java gets the job done. That's not to say that Go couldn't get ahead of Java and may be the better language (especially in the future). But the ecosystem is far from it for now and Go has to prove it won't suffer from the same problems Java is now.
- isacikgoz 7y agoDespite all critic comments here, I think the article is great because it clearly identifies what is minimalism in Go and how it is easy to learn and use compared to Java or Python. Still, there could be code snippets or more details on context but these are huge subjects and even if he tried it would be a hard read.
- cal97g 7y agoGolang is literally dogshit.
- VBprogrammer 7y agoI don't like downvoting people but in this case your comment adds literally nothing to the conversation. While I can wholeheartedly agree that golang has features, and in some cases absence of features, which make it less than ideal for some things. However, writing off a whole language, created by people who are no doubt smarter than you, is pretty silly.
- icebraining 7y agoDon't feed the trolls.
- lifeisstillgood 7y agoIs it just me - but writing correct and clear code depends less on the language and more on the problem being solved and the domain - and ones understanding of both. Someone with a detailed grasp of both can write clear code in C, Haskell, Python even BASIC If you don't grasp either and have no time to be allowed to do it, no language will save you.
- throwawayjava 7y ago> If you don't grasp either and have no time to be allowed to do it, no language will save you. That is certainly true. But the language can have a big impact on the difficulty of getting the implementation correct.
- mattnewport 7y agoGiven a certain level of understanding of the problem, certain languages can make it easier to write clear and correct code. For example, code that does physics or 3D graphics calculations is clearer in a language that can represent matrices and vectors as types providing the expected operations (e.g. C++ over C) and if the code involves physical quantities it can be easier to enforce correctness in a language that supports units in the type system.
- _n_b_ 7y agoAgree. This is one of the reasons that Fortran remains popular for scientific computing: * dead-simple array/vector operations (http://www.mathcs.emory.edu/~cheung/Courses/561/Syllabus/6-Fortran/array.html http://www.mathcs.emory.edu/~cheung/Courses/561/Syllabus/6-F...) * many useful built-ins (e.g., DOT_PRODUCT, MAXVAL/MAXLOC, MATMUL, TRANSPOSE) * standard math libraries (e.g., LAPACK) with lots of very fast functions for linear algebra
- jcora 7y agoThis. I hate this relativism about the merits of languages. There's an entire field of study dedicated to that and just because you can write a web app in all your languages of choice doesn't actually invalidate the vast conceptual differences that exist and have real effects on how you program
- amelius 7y agoHow well would a library like NumPy work in Go, given that much of its ease of use comes from operator overloading?
- jcadam 7y agoNo language supports the commoditization of programming talent quite like Go. Java gave it a good shot, but Go is much closer to "perfection" in this regard. Using Go feels like mindless clerical work. My industry (defense and govt contracting) is still big into Java, but we traditionally run at least 10 years behind the state of the art. At some point (maybe in another 10 years) I expect to see the cube farms full of Java code monkeys replaced by cube farms full of Golang code monkeys. Big body shops (which is what the majority of my industry is) love mediocrity and overstaffed programs. By that time the cool kids will have moved on to something else. Maybe they'll rediscover OOP or some such.
- raducu 7y agoI fail to see what's wrong with the commoditization of programming -- I assume you think there's something wrong because you use the term "code monkey". Is there some language that's used by cool programmers that allows them to write complex code(equivalent of millions of lines of code written by "code monkeys" -- or 10 lines of code written by the gods) ? Is there a conspiracy against said language that these god programmers write that prevents it from taking over the world (besides the "code monkeys" not being able to learn it? Because in my experience once you get to decently complex projects, the (modern)language doesn't really matter that much. My intuition is the above is applicable even for small projects, and that beyond hand picked examples, the programming language doesn't really matter as long as you're comparing apples to apples -- that is some business functionality, the choice is based just on the ecosystem.
- CoolGuySteve 7y agoYeah but you won't like the answer. It's C.
- sosodev 7y agoWriting your web services in C sounds like a great idea.
- 7y ago
- gerbilly 7y agoUgh, go is fine but is seems like a regressive design with guardrails all over the place to prevent programmers from hurting themselves. I use it, but feel its design insults my intelligence.
- oromier 7y agoSO is Ruby, and who uses Ruby still ? I love ruby I would like to work with Ruby 100% of the time but yeah... too many downsides.
- deckarep 7y agoAfter being fully invested in Go for close to 6 years and working at primarily Go based shops...I want to disagree with this headline. Folks new and old to Go still write data-race riddled code unless they put in the extreme mental effort and care into avoiding data-races. Also, if they write good unit tests that help them spin through the code they can often double-down on ensuring their code is correct by using the race-detector. Even if you do all of this...sorry but there’s no guarantees. In my opinion this is why we are seeing languages like Rust invest heavily in something like the borrow checker...to prove at compile time when you have racy code. If Go had a compile time ability to do this it would be really amazing. Yes, this all my experience and opinion.
- acuozzo 7y ago> to prove at compile time when you have racy code Check out Pony.
- AnimalMuppet 7y agoI can't tell. Is that just a pun, or does Pony actually help with this?
- deckarep 7y agoIt’s not a joke see Pony’s front-page. I’ve also heard that other languages are considering moving to this provable compile time model such as Swift. I’d be happy to offload such mental hoops to the compiler.
- oconnor663 7y ago> Go is strongly and statically typed with no implicit conversions This is one glaring exception: Concretely typed objects can be silently converted to interface objects. In particular, a `*MyErrorStruct` can be silently converted to an `error`. The giant footgun associated with this conversion is that because the resulting interface object "remembers" its concrete type, it won't compare equal to `nil`, even if the original value was in fact `nil`. This is a pretty big exception, which I've seen cause bugs in production. It's common to have one function that returns a concrete type wrapped by another function that returns an interface. That means the silent type conversion is happening in the `return` statement, which is extremely easy to overlook. (Or which can be introduced after the fact by changing the signature of either function.)