331–340 of 396 posts
Earlier quoted context omitted.
> Unified codestyle The moment I got my first compile error due to an unused variable and an unused import, made me realize Go is not a serious programming language.
The moment you see that you had misspelled a variable name by a single character when the compiler warned you about an unused variable, you'll realize Go is a serious programming language.
Earlier quoted context omitted.
Well written list of what made Go better language during last years. I'd add iterators, the recent big thing from Russ.
Iterators and generics go against the original goals of Go - simplicity and productivity. They complicated Go language specification too much without giving back significant benefits. Iterators and generics also encourage writing unnecessarily complicated code, which makes Go less pleasant to work with. I tried explaining this at https://itnext.io/go-evolves-in-the-wrong-direction-7dfda8a1...
Generics also allow to write some data structures that would be useful e.g. to speed up AST parsing: writing a custom allocator that would allocate a large chunk of structs of a certain type previously required to copy this code for each type of AST node, which is a nightmare.
Earlier quoted context omitted.
What are some things that make it well managed?
The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion up…
Could you provide some examples of this? From knowledge of the pipeline operator proposal[0], moving fast and breaking things isn't always a priority.
It goes without saying that Babel is an external collection of modules that don't fall under the TC39 umbrella, so they're able to iterate at a much greater cadence than the official specification (and you obviously need to explicitly opt-into using it.)
[0]: https://github.com/tc39/proposal-pipeline-operator/commit/da... (first commit; Nov 9, 2015, which is 8 years, 8 months, 24 days ago)
Earlier quoted context omitted.
This is the first time I'm noticing that rsc would be an initialism for the blog.
Me too!
While you're still reading these, I want to say that while I've never ended up using Go for any shipping projects, I've been a fan since day 1. And it hasn't been lost on me that in the languages and ecosystems I do use in my professional life, good decisions from Go have propagated through the software world.
One thing that really sticks in my brain is gofmt; it makes it clear that there's still relatively low-hanging fruit where you can make a really good decision that spreads to the rest of the world on merits alone. It's an inspiration.
> I don’t believe that the “BDFL” (benevolent dictator for life) model is healthy for a person or a project It's interesting that the best projects have BDFLs, and that the best BDFLs are skeptical of their own power.
I've noticed: competent people who aren't interested in leadership tend to make the best leaders. As compared to people who want to be leaders, for the sake of being known as a 'leader', but have neither the competency nor accountability to be leaders.
The best leaders are interested in being leaders for the betterment of their team/community, not for the clout. But people who are pushed to be leaders without being interested in that, they tend to suck and make life miserable for everyone else. Leadership is a skill, if you treat it differently, you will suck at it.
Earlier quoted context omitted.
In part of the comment yes, kind of, but the comment begins by saying "Iterators definitely have one of the strangest syntaxes I've seen". As there is no syntax specific to iterators in Go, I find this a bit hard to understand.
Well, yes, that's the thing: you don't get any special syntax for generators (like "yield" keyword), which makes them look quite weird compared to other languages that have native support for them. You need to have very clunky and verbose syntax (at least I view it as such) which consists of having to define an extra nested closure and use a function pointer that was passed to you. Having a new keyword would allow fo…
The benefit of Go’s generator implementation is a huge simplificación of the language semantics compared to other approaches. The generator function has no special semantics at all, and when used with ‘range’, all that occurs is a very simple conversion to an explicit loop repeatedly calling the function. Other popular approaches require either special runtime support for coroutines of some form, or a much more elaborate translation step within the compiler.
Earlier quoted context omitted.
The reluctancy to introduce new syntax too quickly (looking at you, TC39 and Babel) makes go an almost maintenance free language. If you learned idiomatic go, you can maintain and patch other libraries in the ecosystem very quickly. Unified codestyle, unified paradigms, unified toolchain. It's a language with harsh opinions on everything. If you manage to get over your own opinions, you'll realize that any opinion up…
"That's why go's toolchain isn't as messed up as npm, yarn, grunt, ..." And let's be honest, Rust toolchain is pretty messed up too. Want to cross-compile with go? Set the GOOS variable and you are done. On Rust you need to curl-sh rustup, switch to nightly, add new targets, add target to your cargo and cross fingers it works this week.
> On Rust you need to curl-sh rustup
Yes, but you do that once per computer, probably when you installed the compiler
> switch to nightly,
No
> add new targets,
Fair. But this is also one-time setup.
>add target to your cargo
Not sure what you're talking about here tbh
> and cross fingers it works this week.
Don't use the nightly compiler and you're good
Earlier quoted context omitted.
> It's impossible to write complex and performant programs without pointers. Well, I'd rather not copy around a multi-hundred-megabyte (or gigabyte) 3D object around to be able to poke its parts at will. I'll also rather not copy its parts millions of times a second. While not having pointers doesn't make impossible, it makes writing certain kinds of problems hard and cumbersome. Even programming languages which do n…
Well, looks like the GP missed a very common false fact: The operations written in a program must literally represent the operations the computer will execute. This one stops being true on high-level languages at the level of x86 assembly.
"Assembly is not a low level language" is my favorite take, and with microcode and all the magic inside the CPU, it becomes higher level at every iteration.
Earlier quoted context omitted.
A goal of Go was to put working on complex distributed systems within the reach of the junior people Google had access to in the quantity they were hiring. To whit, the kind of people who would have been able to work on a big Python system with 3 months ramp up or on a big C++ system with a year of ramp up. It is pretty clear that with respect to that goal, Go is a success. It has attracted Python programmers who nee…
> "Introducing a junior person to a large Rust system would still take a year, because it is so much more difficult than Go." A recent study done at Google disagrees with this assessment. ""it takes about the same sized team about the same time to build it, so that's no loss of productivity" , said Google's Director of Engineering Lars Bergstrom about porting Go to Rust in the talk https://youtu.be/6mZRWFQRvmw?t=2701…
"When we have rewritten from Go into Rust, we found that it takes the same size of team and same time to build it."
Important part here being: rewrite. I would expect a rewrite to take less time, not the same time, than writing from scratch. Yet a Rust rewrite took as long as Go from-scratch project.
So to me, this implies the opposite, that Rust takes longer to write.
Earlier quoted context omitted.
This! In Go, a feature needs to have an extremely good reason to be added, and even then it's only added with care and caution. In other languages, pointless features are added because maintainers are afraid, or not empowered to say... "yeah, we get it, but no, we will not add cruft to the language because you can't write your own 2 line function to achieve the same, no matter how hard you dunk on us on Twitter, it's…
> pointless features are added because maintainers are afraid I wouldn't have described language designers' feelings that way, but you're absolutely right. For example, witness the recent features added to Python with little more justification than "other languages have it". It's pure FOMO - fear of missing out.