81–90 of 297 posts
Most of the items explained are non-issues and part of why Golang is how it is today. Lets hope we can keep the language as-is and don't go back to old decisions and remove features like Scala have been doing the last years...
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…
Except that clearly history showed that it wasn't enough, and we ended up with about 50 millions (and counting) different meaning for "static" for instance. I like C but its simplicity is almost by accident more than by design. It's pretty far from "perfect" in my book.
There are so many weird features about the language that can bite you ass for no good reason. Why don't switch() break by default since it's what you want it to do the overwhelming majority of time (answer: if you generate the corresponding assembly jump table by hand "fall through" is the easiest and simplest case, so they probably kept it that way).
Why do we have this weird incestuous relationship between pointers and arrays? It might seem elegant at first (an array is a pointer to the first element or something like that) but actually it breaks down all over the place and can create some nasty unexpected behavior.
Why do we need both . and -> ? The compiler is always able to know which one makes sense from the type of the variable anyway.
String handling is a nightmare due to the choice of using NUL-terminated strings and string.h being so barebones that you could reimplement most of it under an hour.
Some of the operator precedences make little sense.
Writing hygienic macros is an art more than a science which usually requires compiler extensions for anything non-trivial (lest you end up with a macro that evaluates its parameters more than once).
Aliasing was very poorly handled in earlier standards and they attempted to correct that in more modern revisions while still striving to let old code build correctly and run fast. So you have some weird rules like "char can alias with everything" for instance. Good luck explaining why that makes sense to a newbie without going through 30+ years of history.
The comma operator.
Undefined function parameter evaluation order.
I suspect that with modern PL theory concepts you could make a language roughly the size of C with much better ergonomics. I'm also sure that nobody would use it.
Earlier quoted context omitted.
If you're just writing a REST API, I wonder, why did you choose Go for this instead of Java or Python?
I also prefer writing REST APIs in Go. - Compared to Java: Ecosystem is way over-engineered. You might get along just fine without writing a bunch of boilerplate and factories and XML configs, but sooner or later you're probably going to pull in some dependency that does and have to deal with a bunch of clunky APIs and other annoyances. - Python: Possibly the only language that's even worse at dependency management t…
> == vs ===
Just never use ==, and you're done. This is pretty much a defacto standard. It essentially has no legitimate usecase that couldn't be expressed more explicitly with at most 1 extra line, and should just be ignored.
> undefined vs null
I've only very occasionally run into this being an issue. Standard seems to be using the falsey nature of both undefined and null to check for them, !x rather than x === null for example, so that it doesn't really come up much in practice, but anyway...
> TypeScript may solve some of these issues
Yes, it solves both the above :-)
> Dislike dealing with promises / callbacks
Firstly callbacks are hardly seen anywhere any more. And if they are, certainly no more than one level deep, and that's even assuming you don't just promisify the callback function anyway, which is trivial to do.
For Promises - async/await makes dealing with them syntactically much nicer in node. It's pretty much just like synchronous code to read, and in behaviour.
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 ANSI style function declaration was maybe the only innovation that came after that that significantly improved the language. "const" as well (back ported from C++ ?). And being able to declare variables anywhere (instead of just at the beginning of a block)
I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I perso…
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 me seemed like C was such a tight, perfect little design. Only thirty keywords, and simple consistent semantics. Except that clearly history showed that it wasn't enough, and we ended up with about 50 millions (and counting) different meaning for "static" for instance. I like C but its simplicity is almost by accident more than by design. It's pretty far from "perfect" in my book. There are so many weird features…
If this is true, then that makes perfect sense. C was attempting to look after its target market: assembly programmers.
Earlier quoted context omitted.
Same here. K&R C is probably still my favorite programming book. I will admit that most of the examples I had to stop and think about, they all seemed 'cleverly' written. But in each case, it gave me pause, and taught me a new, often simpler way.
The 'K' in K&R actually wrote a book on Go, "The Go Programming Language". I haven't used it personally but it has good reviews, so it might be a good resource for people who are curious about Go and know they like that writing style.
The actual problems like versioning, error handling and generics (may be) are being worked on.
I have seen many new learners find it hard to learn what packages mean, and how about teaching them private, public, static, ...
Earlier quoted context omitted.
I can comment on this on my own: 1. Java - did not want to adopt the entire ecosystem. This is very much wanted a banana and got the whole jungle with a gorilla type of story. 2. Python - dynamic. Don't want that. Go's minimal typing is perfect. It's easy to deploy (binaries). It's fast. It can scale well. It's opinionated (love this). Python and Java both encourage and allow developers to flex creative solutions tha…
You can write small Java services. You really don't need Spring or anything. You should try it some time.
most of these seems reasonable, but they are not big enough for me to actively dislike the language. The capitalisation is maybe the most annoying for me, I think it was designed with an IDE in mind (which would be able to automatic update all references), but I still find it a flawed design to have to touch potentially a lot of files, many places to change something from private to not private. The problem with err…
If you don't have an IDE, you can start by making all functions and methods private. When you know you need it public, wrap the private function with the public one:
func myF(ana int) { /*do something */ }
func MyF(ana int) { myF(ana) }
func myG(a int) { myG2(a, 7) }
func myG2(a, b int) { /*do something*/ }