Threads for p5v
-
Writing my book about Graphics Programming in Go
-
How did this article even make it in here? It’s mainly targeted at non-technical people, and in my opinion, leaves a bit to be desired. The problem with good blockchain applications is not that they don’t exist, but that idiots tried to sell us crap and succeeded. I still believe that blockchain s particularly interesting in cases where the individuals need to ensure that no single party can meddle with the individual transactions. I can’t think of a better example than voting, but somehow, no one tries to target that.
-
- all IO is done with byte arrays and sometimes it’s good to be able to access that directly
- abstractions are leaky
- the end.
This article is nearly devoid of any actual content.
-
It’s about “byte slices” (
[]byte), not “byte arrays” ([42]byte). But to be fair, the distinction doesn’t matter much for the gist of the post.-
Totally correct. I think, I even mention it somewhere in the post. The thing is, I wanted to make the post applicable to a broader audience coming to Go for the first time. Since a byte slice and a byte array are pretty much interchangeable concepts in this context, I decided to the stick to using byte array everywhere. It’s just what most programmers would know as a term.
-
-
-
I’ve recently switched my laptop from NixOS to Windows, and I use WSL for all my development needs. Some notes here.
WSL 2 is pretty seemless when it comes to Linuxy development on Windows, and with VSCode remote you can edit from a native Windows application, with all extensions and tools running inside WSL 2 (example).
I used to use macOS; but nowadays you can’t even get Nix installed easily on a Mac, so I’ve given up on the Apple ecosystem entirely (they do make great hardware though).
-
-
And with regards to development, Windows has been fairly clunky and annoying to work with
People keep saying it, but I’m almost certain it’s with the implied qualification for POSIXy development, and it’s quite obvious a non-Unix isn’t fun to develop in for things that expect nothing but Unix. But that doesn’t make Windows bad for development; I was my most productive using Visual Studio instead of fighting CMake and gdb.
-
-
-
-
why Windows over something more libre (Linux, BSD)?
As explained here, I use both and thereby get the best of both worlds - from a technology, application support and user experience points of view. Free Software is a great and all, but I’m personally not going to compromise on the aforementioned factors.
And with regards to development, Windows has been fairly clunky and annoying to work with (source: colleague uses Windows)—how has it faired for you?
With WSL 2 you essentially get a Linux development environment. I do everything in command line (neovim and tmux, for example), so it has not impacted my experience except in a couple of unimportant cases.
-
I’ve been using wsl lately and for me it’s that everything just looks and feels much better. I didn’t want to like it.
Before switching I had stopped using tiling window managers as an experiment and felt good about it, once I didn’t feel dependant on them, trying wsl wasn’t unreasonable.
-
You didn’t ask me so I hope you’ll forgive my answering your question anyway.
Mostly, I run Windows as well as Linux because as @srid says I feel like doing so enables me to get the best of both worlds, and additionally because I chose poorly when I bought this laptop and its compatibility with Linux is somewhat unstable at best (Laptops with the Nvidia Optimus chipset are notorious for this).
-
-
I can totally imagine the situation you’re in right now. As I pointed out on my blog, after a decade spent investing in the Apple ecosystem, I am at a crossroads. I love the Apple hardware, but am at odds with Apple becoming a gatekeeper of its macOS ecosystem. I have used Windows prior to 2010, and during its darkest days. A lot has happened since then, and I have to say, suddenly, thinking of using Windows for *nix development doesn’t sound outlandish at all.
-
-
-
Well written and nicely explained. Brought me back to my Uni days, when we had to implement boids and other simple state automata in C#.
-
I got close but failed the first time I tried to implement boids. It must have been soon after I started learning to code. I stretched myself because it looked super cool and I also liked that a version of it had been used in Half-Life.
-
I have recently laid out my intention to write an ebook about graphics programming in Go My humble start (It’s literally just a single draft page for now) aside, I would really like to have sections with practical examples. Yours fits perfectly. With your full permission (will be credited in the ebook’s references, of course), I’d like to republish or rephrase some of your code and explanations in it. How does that sound to you?
-
I’m currently in talks with a few publishers and have been advised to hold onto the exclusive rights to anything I would want to expand into a chapter of a book.
Your book sounds exciting – there’s always room for more content about graphics programming in Go! Do let me know if you need a technical reviewer.
-
-
-
-
I would love to get your honest opinion, on why this article gets massively downvoted, wherever I have posted it. Is it the clickbait title, the non-informative content, the affiliate link at the end? What is it that makes everyone avoid it like the plague?
-
I don’t think it’s a bad article, but I do think it’s off-topic here. Unlike HN Lobsters is much more focused on technical content. There’s https://barnacl.es/ for more business-y stuff like this, but it’s much less active.
-
-
-
-
I used to work with Jekyll, before I discovered Hugo a couple of years ago, and have never looked back. Honestly, the speed factor trumps everything else. Also, the fact that in typical Go fashion, it comes as a single binary that is ready to get executed as soon as you fetch it. I have had so many issues with Jekyll before, due to different Ruby versions, gems, etc. I do not want to even look back.
So, my blog uses Hugo as mentioned, together with a modified by me version of a popular theme: hello-friend-ng.
-
I think this is somewhat standard behavior. In other programming languages, the compiler, or latest, the runtime might try to prevent modifications to a looped-over collection. Go would allow that when using a pointer. Makes sense from a semantic point of view. Treat the ranged-over slice as immutable, unless you use a pointer to it.
-
It constantly lies about how complicated real-world systems are, and optimize for the 90% case,
Serious question, what’s wrong with optimizing for the 90% case?
ignoring correctness.
This is a bit of a weasel word. Does the author imply that in the remaining 10% of cases, Go is useless? (as in, the language cannot be used for these cases)
Or is it just that it’s slightly harder to work with?
-
They don’t mean the 90% use case, they mean the 90% execution case, and that Go omits a lot of features that enable the programmer to reason confidently about the correctness of their edge case handling. The rhetoric of simplicity around Go implies (disingenuously, IMO) that the language’s simplicity indicates a reduction of the total complexity involved in solving some problem, but more commonly it just shifts the complexity elsewhere, usually to a place (runtime behavior) where the complexity is harder to characterize and more dangerous to get wrong. I agree with the author that this is a remarkably poor tradeoff, and it’s definitely been my experience in writing Go daily for more than a year.
-
The rhetoric of simplicity around Go implies (disingenuously, IMO) that the language’s simplicity indicates a reduction of the total complexity involved in solving some problem
I’ve always thought that the type of simplicity they’re talking about isn’t about making complex problems simpler, but about getting the language out of the way when solving complex problems. You don’t have to reason about new constructs or different patterns when you’re solving a different problem. It’s also rather easy to read unfamiliar Go code because there aren’t very many ways to get clever.
That said I’m quite new to Go, and so far I’ve only used it for cloud-hosted server apps where my goals and use-cases align well with the Go developers’.
-
it just shifts the complexity elsewhere,
A really good point. That’s why I’ve been telling people to “panic without worry”. Not that I am against error checking. Where it makes sense, you should. It’s just the nature of the language that pushes you to find solutions to things like resilience at the infrastructure layer.
-
-
-
As someone who has spent enough time writing Go code to have a say on this, I really hoped to support this article. I agree with the general premise: Go is hiding a lot more complexity under the rug than what the alleged promise of simplicity made us believe in. Also, as a language that touts for being simple and consistent, there are various and sometimes, aggravating inconsistencies in how Go gets things done.
Yet, the article moves on to some very in-depth examples of how the language fails at solving some very specific technical tasks. And, it goes on explaining for nearly half an hour. IMHO, the author would have achieved a much larger effect, had he either shortened the explanations, or chosen different examples, with a much broader scope. Of those, there are plenty out there.
-
I slipped briefly into Major Grumpiness when I read that. It’s highly disingenuous.
Module support in the go command is now ready for production use.
So why has the entire Go programming community (outside Google, are they using this stuff yet or still on their internal build systems) spent the last year plus dealing with fallout from Go Modules, migrating over to it, deciding how to deal with other build systems, working around bugs, and more?
That’s not a sign that something was deployed as “not fit for production use yet”. Go 1.13 cut over to Go modules as on by default. Because it wasn’t yet fit for production use?
One small sentence inspiring such utter frustration.
-
-
I use it happily in my own projects, but had to report a few bugs in the proxy stuff. $employer hit major pains just before I arrived and had to use the env var to disable modules to be able to keep doing line-of-business work.
Citation: no. Just go look at everyone who was on
depjust before the vgo announcement; or the problems hit when people kept running into Go modules not updating to a “needless” new version which was a security fix, because unlike every other mainstream dependency management system an unpinned version didn’t get the latest stable release but the earliest release which met all constraints.-
The first part about bugs you found and reported, and $employer pains is very informative and valuable, thanks for sharing it.
As to the second part, it’s FUD I vehemently disagree with. First of all, please don’t claim “everyone” in your arguments and use “just this and that” rhetoric tricks. I mostly managed to avoid
depfor all its lifetime, and I actually expected problems with it from onset. One time I couldn’t avoid it, was when I tried usingdeponce to install some big package which used it. In that case I had abysmal experience with it: the project never managed to finish downloading, dying somewhere in the network of dependencies after several minutes. As to the community drama with switching fromdeptovgo, please don’t beat the dead horse; feathers were ruffled, lessons were (hopefully) learnt, it was basically a community mismanagement issue, not a technical one. As to “people running into Go modules not updating to new version”, again, citation needed. You can agree or disagree with this design choice (I personally do agree), but using it as argument for modules being “not fit for production use yet” is disingenuous.
-
-
I had a lot of pain with switching to Go modules with a pile of Kubernetes dependencies. Here’s someone else complaining about it.
-
-
-
- Even with a few warts, it was a massive improvement, and worth adopting.
- There wasn’t really very much in the way of fallout, mostly just a few third-party tools that needed to catch up, and one edge-case that was discovered in the module hasher. Nothing major in the design or in the implementation of modules in Go itself changed between 1.11 and 1.14; this is just sane release engineering. It’s working well, so now there’s a note that says “go ahead and use it, if you were waiting!”
-
Is gorename a third-party tool? This is an earnest question, I’m not sure if its inclusion in the tools repo means anything one way or the other. If it is a first-party tool, I think it’s pretty unacceptable that a feature released with “beta” status didn’t even have 100% support in the first-party tooling landscape for a good while, and if it isn’t, it was still quite frustrating to be dealing with a language ecosystem where the main language version has a 1 in the major version slot and a number higher than 10 in the minor version slot and having to choose between either having a basic automated refactoring feature or having a tolerable dependency management system.
-
-
are they using this stuff yet or still on their internal build systems
Google uses the internal version of Bazel (with a different way of using it than rules_go: no go_default_library, etc). It’s unlikely they will use modules for the main codebase…. ever (at least IMHO).
-
Anxiously trying to get my ebook Generative Art in Go finished before the February release. Wish me luck.
Good luck. Sounds really interesting so hopefully one extra pre-order helps with the motivation. Looking forward to reading it.
Many thanks! Appreciated 🙏🏼