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

Why I Don't Like Golang (2016)

teamten.com

Post reply on HN
Print view View original

191–200 of 297 posts

Re: Why I Don't Like Golang (2016)

#191

Post by saagarjha »

earenndil wrote: post #144
jolmg wrote: post #120

Earlier quoted context omitted.

By the fact that lmm said "You can pass functions", they probably meant "function pointers", since that's the only way you can pass in something that could be referred to as a function in C. EDIT: At least last I heard. The example I gave is C89, and I know C99 and some GNU extensions. I don't know if a new standard introduced something else that could be referred to as a function that can be passed in but not return…

GNU c can have lambda expressions[1]. And clang does even have closures[2]. 1: http://walfield.org/blog/2010/08/25/lambdas-in-c.html 2: https://en.wikipedia.org/wiki/Blocks_(C_language_extension)

Note that the first example relies on multiple GCC-only features, one of which is the atrocity that is nested functions, and even then technically invokes undefined behavior.

Re: Why I Don't Like Golang (2016)

#192

Post by [deleted] »

jayd16 wrote: post #65
sdegutis wrote: post #56

Earlier quoted context omitted.

The "Capitalization feature" is actually objectively worse because of the reason OP mentioned, of having to rename all semi-local usages when visibility changes. But good IDEs can help mitigate the difficulty of this. But even more significant is that the Go authors cannot seem to grasp the importance of pre-existing conventions. Almost every language I've used in the past decade allows and encourages the variable, C…

WRT renaming, I find that refactoring code is often such an oversight from language designers. I consider C# to be an elegant language in this way. Public fields and properties look the same in C# so you can effortlessly refactor between them, for example. I wish more languages thought about this stuff.

[deleted]

Re: Why I Don't Like Golang (2016)

#193

Post by 50 »

gerbilly wrote: post #31

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

To piggyback this comment, does anyone know of any co's building something interesting mainly w/ the C programming language (and maybe even w/ Rust)? Also, that are usually open to interns/entry level programmers?

Re: Why I Don't Like Golang (2016)

#194

Post by saagarjha »

kazinator wrote: post #172
tx-0 wrote: post #106

Earlier quoted context omitted.

but you can't pass functions in C, you can only pass pointers-to-functions... and you can return them too. the piles of stuff that C contains are the stuff of 20th century von Neumann architectures, the stuff that defines the undefined behaviors, and that's what has made C indispensible. I'm not saying C's perfect, but you can't swap it out without replacing what it did and does.

That's the same with languages that have first class functions. The code part is still passed by reference, not by copying around the machine code.

Of course, almost every high-level language that compiles to native code ends up doing something that looks like sugared C for many of their features.

Re: Why I Don't Like Golang (2016)

#195

Post by kazinator »

saagarjha wrote: post #194
kazinator wrote: post #172

Earlier quoted context omitted.

That's the same with languages that have first class functions. The code part is still passed by reference, not by copying around the machine code.

Of course, almost every high-level language that compiles to native code ends up doing something that looks like sugared C for many of their features.

That first class functions are passed by reference can be verified at the high level; e.g. with the eq function in Common Lisp.

Re: Why I Don't Like Golang (2016)

#196

Post by borgel »

50 wrote: post #193
gerbilly wrote: post #31

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

To piggyback this comment, does anyone know of any co's building something interesting mainly w/ the C programming language (and maybe even w/ Rust)? Also, that are usually open to interns/entry level programmers?

It's fairly common for folks doing embedded work. What are you interested in?

Re: Why I Don't Like Golang (2016)

#197

Post by 886 »

lllr_finger wrote: post #53
886 wrote: post #28

Earlier quoted context omitted.

you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?

I'd propose Rust - it's also a static, stack-favoring, non-class-based language with OO features that compiles down to native binaries. Where it differs is a wonderful type system and top tier package management. If you can work through lifetimes and the borrow checker, you might enjoy it.

Yes, that's true. Rust is good alternative to Go, and probably the closet to Go in terms of feature parity. Definitely worth checking out.

Re: Why I Don't Like Golang (2016)

#198

Post by stevekemp »

maxxxxx wrote: post #125
gerbilly wrote: post #31

Does anyone remember reading K&R for the first time? To me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics.¹ When I first learned it, it was still pre ANSI, and you declared a function like this int f(a) char *a { } The ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. I remember in…

"The K&R book is worth a read if anyone missed it. It's beautifully written." Agreed. I read the whole thing in a weekend and had a pretty good idea about pointers and stuff afterwards. I feel a lot of people have trouble with pointers didn't read it.

My programming journey went roughly:

* ZX Spectrum BASIC

* Assembly language (Z80)

* FORTH

* C

* ..

Learning C when I already knew assembly language made it obvious what pointers were. I suspect a programmer these days might start with javascript then jump to C and be a little mystified.

Re: Why I Don't Like Golang (2016)

#199

Post by 886 »

bluquark wrote: post #40
886 wrote: post #28

Earlier quoted context omitted.

you make it sound like Go is not top tier in the 2019's programming landscape and there is a good alternative. Can you elaborate?

Kotlin and Swift are both currently encroaching on Go's server-side use cases. For example, Go's star feature, goroutines, has recently been cloned by Kotlin. They are at least as equally pleasant to program in, and they're hitched to major client platforms which means they improve faster and will definitely have a pool of trained developers in the long term.

Points taken. I am full time on Go since few years ago and before that I was 100% Java. Haven't really kept myself up-to-date with the Java land.

But from my experience with Java, Go, and Python, I find Go a very versatile programming language. Being able to compile binaries means it's great for infrastructure deployments and CLI tools. Goroutines, concurrency, and etc make it a great choice for server/micro service use cases as well. Some can say that not having a JVM is a plus as well.

However, developers do have to be disciplined with error handling and dependency management. But one can argue that this is the case for software development in general.

Re: Why I Don't Like Golang (2016)

#200

Post by saagarjha »

lacker wrote: post #189
DaveInTucson wrote: post #123

I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.

If you work for a while at a larger company that enforces a style guide, it starts to make total sense. If your company's style guide already insists that identifiers should be named with some convention that matches their visibility, then by making that part of the language, you are simplifying the system. I would not be surprised if specifically the Google C++ style guide influenced this decision.

Yes, but this forgets the fact that companies have different style guides.
Post reply on HN