211–220 of 297 posts
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…
Earlier quoted context omitted.
I liked a similar aspect of Ruby: attributes and 0-args methods had the same syntax, so you could easily refactor a static field into a method that returns a dynamically calculated value. Overall I don't like that feature, but that was a very handy aspect of it.
Ruby actually went one step beyond: there are no attributes. `attr_reader` just generates a 0-arg method, while `attr_writer` just generates a 1 argument `name=` method.
Funnily enough, Self opted for the opposite tack of not having private data fields (although it does have readonly and read/write slots), but you can trivially swap "data" slots and "method" slots: http://handbook.selflanguage.org/2017.1/langref.html#constru...
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 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…
I work on Golang stuff at work where we made the switch after the troubles associated with refactoring Python. Recently though, I 'typed' a personal project of mine that was fairly large, and it's become a pleasure to work on.
IDE integrations of mypy warn you as soon as type errors occur. The fact that the type annotations are first-class features of the language and not embedded in comments also makes it great. The compromise of type-safety at the boundaries where you interface with 3rd party APIs that don't provide type annotations (the major ones do) does not get in the way too often contrary to what I expected.
mypy makes Python a pleasure to work with again.
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think t…
I think the worst part of that decision is I've never seen a bug arise from unused imports and variables (even in languages with ubiquitous importing side-effects like Python, imports and import ordering can cause issues but usually you need the import anyway, you can't just nuke it).
Meanwhile variable shadowing / overwriting or unused return values which do cause issues are perfectly fine by the compiler.
Earlier quoted context omitted.
After a long stint in enterprise Java land, Go was a really big adjustment. Mostly about letting go of unnecessary complexity. I didn't realize how much I didn't miss that complexity until I recently went back into Java. If you learn the golang way of doing things, the issues this guy mentions really are not something you run into.
One of the commenters on lobste.rs called boilerplate-heavy Go written by programmers coming from Java "Gova". From a lot of what I've seen, that is a useful description.
If you come to Java with a blank slate, and try using it with simplicity in mind. There's not much wrong with it. But once people add design patterns, layers of layers, reflection, annotations. Etc. You get a monster. And somehow, the enterprise world seems to always create those.
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…
> Why do we need both . and -> ? The compiler is always able to know which one makes sense from the type of the variable anyway.
You're contradicting yourself in a way.
Maybe K & R thought: "Why can't arrays decay to pointers? The compiler is always able to know which one makes sense from context anyway."
I agree with the your opinion about arrays/pointers, but disagree about ./->. A programmer reading the code might confuse a pointer for a non-pointer if you conflate . and ->
Unrelated thoughts: > Structs do not explicitly declare which interfaces they implement. This is done implicitly by matching the method signatures. This design makes a fundamental error: It assumes that if two methods have the same signature, then they have the same contract. Isn't this just duck typing? Don't other languages renowned for their type systems do this? > There’s no ternary (?:) operator. Every C-like la…
> Isn't this just duck typing? Don't other languages renowned for their type systems do this? It's "structural subtyping", which is the type-safe equivalent of duck typing. It's a feature that allows implementations to exist without needing to know exactly every interface they implement. TFA's concern is purely theoretical. > That's horrifying. append() doesn't operate on arrays, it operates on slices. Arrays are fix…
Vectors are standard data structures.
Append possibly mutating in place and possibly return a new vector instead, not so much.
That's exactly what Go does.
Not to mention the ability to share a backing array between two "vectors" and to append to both. That's a Go innovation right there.
insert rant about how you need generics for functional programming here
You’re not forced to use the "imperative verbosity" in the article. The following is shorter and more idiomatic. serializeType := model.SerializeNonArchivedOnly if showArchived { serializeType = model.SerializeAll }
How is this not imperative verbosity? Not to mention you are mutating an already assigned variable. You run in to problems when you want to know the type of serializeType and you look at the first assignment but don't see that there is a second one.
Go is statically typed, so the type of serializeType doesn't change, only the value.