Go really does do well in the zero-to-hero case, that’s for certain. Unfortunately it doesn’t fare nearly as well in terms of ease when it comes to continued development.
Go has a heavy focus on simplicity and ease-of-use by hiding away complexity through abstractions, something that makes it an excellent language for getting to the minimum-viable-product point. Which I definitely applaud it for, it can be a true joy to code an initial implementation in it.
The issue with hiding complexity like such is when you reach the limit of the provided abstractions, something that will inevitably happen when your project reaches a certain size. For many languages (like C/C++, Ruby, Python, etc) there’s an option to - at that point - skip the abstractions and instead code directly against the underlying layers, but Go doesn’t actually have that option.
One result of this is that many enterprise-sized Go projects have had to - in pure desperation - hire the people who designed Go in the first place, just to get the necessary expertice to be able to continue development.
Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.
I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.
*I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.
Another reason is kind of a general thing with programming language design: Go, like Java or C, has relatively few concepts in the language and stdlib. This means you’re relatively quick to have seen all of them.
But this also means that for various tasks, these concepts that were left out, would have been the right tool. For example, Go doesn’t have enums.
Generally, it’s still possible to create all possible programs, because of turing-completeness, but it will be more cumbersome and more boilerplate-heavy.
So, as a rule of thumb, the more concepts are provided by the language and stdlib, the more you have to learn upfront, but the less pain you have long-term.
Is there a language that anyone would say really does fare well for continued development or is it just that few people enjoy maintaining code? I’ve maintained some pretty old Go programs I wrote and didn’t mind it at all. I’ve inherited some brand new ones and wanted to rage quit immediately. I’ve also hated my own code too, so it’s not just whether or not I wrote it.
I have found maintainability is vastly more about the abstractions and architecture (modules and cohesive design etc) chosen than it is about the language.
Rust is extremely geared toward maintainability at the cost of other values such as learnability and iteration speed. Whether it’s successful is of course somewhat a matter of opinion (at least until we figure out how to do good quantitative studies on software maintainability), and it is of course possible to write brittle Rust code. But it does make a lot of common errors (including ones Go facilitates) hard or impossible to replicate.
It also strongly pushes toward specific types of abstractions and architectural decisions, which is pretty unique among mainstream languages, and is of course a large part of what critics dislike about it (since that’s extremely limiting compared to the freedom most languages give you). But the ability for the compiler to influence the high-level design and code organization is a large part of what makes Rust uniquely maintainability-focused, at least in theory.
If I’m going to inherit a large code base to maintain, I’d like Java, C# the most, Python, the least. Go isnt too bad IMO. I’ve not worked with enough Rust code to really judge it. BTW I like Python but lack of types makes refactoring and discoverability harder
I used to joke with my niece that my programming job was just me staring at screens and meetings all day. She didn’t believe me until she got to shadow me one day and got super bored.
Not op but guessing she had an idea from media like TV shows and movies that make technical jobs seem much more exciting for entertainment over realism. Crises are usually more Jerry accidentally deleted a directory and we need to recover some files and establish safe guard procedures to prevent it from happening again or this thing broke that nobody even knew existed so we gotta figure it out and less type fast enough to save the mainframe from l33t hackers.
Ninjas, super-heroes, black-belt and terms like that are known gender-excluders. I’ve been through a couple of adjustment sessions for company standard job descriptions and it’s unreal how you can change the applicant mix by wording.
Ah yes, I’ve spent decades cringing when I meet a self-proclaimed or even peer-proclaimed “rockstar”, “ninja”, “guru”, “jedi”, or probably a half dozen other “cool” designations for a tech worker.
With all the recent hype around AI, I feel that a lot of people don’t understand how it works and how it is useful. AI is useful at solving certain types of problems that are really difficult using traditional programming, like finding patterns that aren’t obvious to us.
For example, object recognition is about finding patterns in images. Our brains are great at this, but writing a computer program capable of taking pixels and figuring out if the pattern is there is very hard.
Even if AI is sometimes going to misclassify objects, it can still be useful. For example, in a factory you can use AI to find defects in the production line. Even if you don’t get it perfect, going from 100 defects per 1M products to 10 per million is a huge difference and saves the factory a lot of money.
Agree, but the joke to me is business folks thinking AI is a miracle and they can just shove it everywhere to print money. Where us devs know what you mean, and would like to add it in where it makes sense. Business thinks it’s ready to replace us.
The key to "AI" is having a human there to take algorithms and apply them to the right problems.
This is what most people don't understand because many of the demos are quite impressive and narrowly tailored to prevent the fact from being obvious unless you know what you're looking for.
Most useful application so far seems to have been to predict protein folding. Have to check up on that, it should allow to cure all sorts of bad things.
It’s even worse then: that means it’s probably a race condition and do you really want to run the risk of having it randomly fail in Production or during an important presentation? Also race conditions generally are way harder to figure out and fix that the more “reliable” kind of bug.
Legit happens without a race condition if you’ve improperly linked libraries that need to be built in a specific order. I’ve seen more than one solution that needed to be run multiple times, or built project by project, in order to work.
Isn’t that the definition of a race condition, though? In this case, the builds are racing and your success is tied to the builds happening to happen at the right times.
Or do you mean “builds 1 and 2 kick off at the same time, but build 1 fails unless build 2 is done. If you run it twice, build 2 does “no change” and you’re fine”?
XML has a bad rap because people went a bit (ok a lot) overboard with it in the early years, pretty much like what happens with a lot of other technologies, but as far as structured and human-readable data formats with good schema and tooling support go, it’s pretty much unbeatable. Now that JSON is the New Good Tech and XML is the Old Bad Tech, too many developers use JSON where XML would absolutely make more sense, and then we end up with unholy abominations like Portable Text, which is JSON pretending to be XML, and is so incredibly verbose and monumentally stupid that it feels like some sort of joke esolang data format rather than something being used in a production system. But no, here we are, god is dead and JSON is XML.
XML is terrific for building eg. structured markup languages with more complex markup than what something like Markdown can provide, and have the resulting files be comparatively readable, at least in comparison to the JSON-based alternatives – compare HTML to Portable Text, for example. XML has such a bad reputation – partially deservedly – that people just automatically assume it’s not a valid tool for anything modern, even when the modern “NoSQL”, “structured and typed data is for nerds, suck it” JSON solution is a giant pile of shit compared to the XML alternative
Growing up with C made me assume semicolons and braces were needed to avoid subtle bugs, but experience with more recent languages showed me that it’s possible to reliably parse the same semantic cues that humans use: indentation, parentheses, and other such context. (Perhaps this was less viable when C was invented, due to more constrained hardware.)
I was skeptical at first, but in practice, I have never encountered a bug caused by this approach in Python, Nim, or any other language implementing it consistently, over the course of a decade or two using them. Meanwhile, I have seen more than a few bugs caused by brace and semicolon mistakes.
So nowadays (outside of niche & domain-specific languages) I see braces and semicolons as little more than annoying noise and fuel for religious arguments.
Well, Python kind of does the reverse of a semicolon: If you want to continue a statement over multiple lines, then you have to \
escape it.
Python also then tries to avoid multi-line statements for that reason, but yeah, in most other languages this would be equally as annoying as semicolons are.
There are some languages which use neither, for example Scala, but I can at least say that while I consider the people behind Scala and Rust equally competent and the languages more or less equally modern, Rust just completely blew it out of the water in terms of error messages despite being much younger. (Not because Scala is bad, Rust is just incredibly good there.)
And yeah, I’m suspecting that Rust using semicolons makes the difference there.
While Scala will pretty much have to guess where a statement with compile error ends, Rust just knows it ends at most at the next semicolon.
I will also say my experience is opposite of yours. I have managed multiple times to try to access a variable in Python, which wasn’t in scope anymore, because the indentation wasn’t enough of a visual cue to me.
And in any modern language, missing/missplaced semicolons or braces are a compile error, with clear error message where it’s missing. I genuinely don’t even know how you’d get a bug out of that.
Well, Python kind of does the reverse of a semicolon: If you want to continue a statement over multiple lines, then you have to \ escape it.
That’s not true. Being within parentheses, brackets, quotes, etc. is enough for the parser to know you’re continuing. In practice, I find that context is already present in most cases.
For the other cases, occasionally surrounding an expression in parentheses is easy enough. Long conditionals probably deserve parentheses anyway, for clarity.
Well, it mostly being already correct is what I meant with Python avoiding multi-line statements.
In JVM languages, Rust etc., it’s for example popular to use Fluent Interfaces. These also reduce visual clutter and the number of variables in scope (and/or the need for mutability).
I did not know about enclosing them with parenthesis, but apparently that works, too, as this library shows: pypi.org/project/fluentpy/
I am a Scala and Rust fan. I can corroborate what you said
The part about no semicolons/curly braces I like in Scala is that I can write a function and it’ll look virtually indistinguishable from a regular ol variable. Functions become much less of a ritual and integrate more nicely with the rest of the code. Other than that though, Rust definitely wins out because of the curly braces & semicolons. I use curly braces in most situations in Scala where I’d normally use them in Rust, and I would use semicolons everywhere in Scala if it weren’t considered unidiomatic. Whitespace-significant syntax is just really annoying to deal with. Using Python or even maybe F# makes me want to die because I keep accidentally missing an indent somewhere or indenting too much somewhere else or using the wrong kind of whitespace and the entire program implodes. At least Scala and Kotlin keep it sane
Also it’s just way harder to visually organize in whitespace based languages. You basically have to do a bunch of magic tricks to make the code look slightly different in a specific scenario than what the language wants you to. Rust allows you to actually visually organize your code easily while also having a strong style rules which you shouldn’t stray too far from (or else the compiler will yell at you).
In Java it’s quite difficult to forget semicolon and still have a syntactically correct program.
I think braces are incredibly important. With Python it can be confusing which indentation is correct when copying code between files. Different indentations can easily be still syntactically correct, but the outcome is vastly different. It’s often I have to double and triple check to verify I copied the code with correct indentation.
It’s often I have to double and triple check to verify I copied the code with correct indentation.
I vaguely remember facing that issue once or twice in the past, but certainly not often. It was because the pasted code was too long for its starting point to be easily found in my editor, even if I scrolled up a bit.
If this happens to you often, I wonder: perhaps the code you maintain should be broken into smaller functions?
If I was in that situation again, I think I would simply place a bookmark before pasting and then jump back to the bookmark to indent/dedent the pasted block appropriately.
Edit: Come to think of it, I would have to check and correct it regardless of the language and braces, since confusingly indented code is unwelcome in my commits.
As someone used to working in c# (and before that Java, C++, Visual Basic, and Pascal) I haven’t seen any brace or semicolon related errors since the days of Borland IDEs (any remotely self respecting IDE will highlight them and refuse to compile, these days), but working with Kotlin has shown me that I, at least, read code with semicolons slightly faster than code without.
There’s a reason we use punctuation when writing, and the same applies to code.
Ugh, you just gave me Turbo Basic flashbacks. My favorite thing was that variable names could be as long as you liked and mixed case, but the compiler only used the first two letters and case insensitive at that. So “BatShitCrazy” and “BALLPARKESTIMATE” actually referenced the same variable.
I constantly call out juniors who do things like ignore warnings, completely unaware that the warning is going to cause serious tech debt in a few months.
But Ive also unfortunately shrugged after seeing hundreds of warnings because to update this requires me to go through 3 layers of departments and we’re still waiting on these six other blockers.
Yeah I’m one of the “I only want to write this fucker once so I will make it as solid as I can” types… and my manager/team-lead/principal dev (all the same person - that’s a whole other story) is the “yolo send it” type.
We do not get on well. I’m probably going to switch teams or jobs soon.
Virtualization was supposed to reduce the overhead, not create entire DevOps departments.
Years of containerization yet no real use over make clean; make build
Wanted to deploy your app in the “cloud” anyways for a laugh? We had a tool for it, it’s called rsync
Let’s run a virtual container in –privileged mode, so we can manage system resources from it – Statements dreamt up by utterly Deranged
Look at what tech interviews have been demanding your Respect for all these years. (These are real documentation examples for how a simple virtualization supposedly works)
Dear sweet christ, I’ve been the manager of a medium sized non profits databases (everything other than finance because they’re special, as in using an overpriced wacky proprietary tool because they are used to it, oh and probably commiting fraud) and, as the author references, I have actually had one of the members of the board get a bunch of other people with 0 technical competence to try to get me to ‘implement blockchain technology’ on postgres.
Non of those fucking morons could ever provide an actual project outline. None of these fucking morons even knew their own teams processes, and they would all change depending on team member asked and date.
Not relevant to this story, but basically I am now disabled and living off of SSDI after being assaulted and seriously injured.
I am 99% sure, after years of working with completely technically incompetent managers, I am never going to work in tech again.
I would literally rather be poor, do uber eats delivery when I feel like it, and slowly build a video game, by myself, not even to make money, just to give my tech brain something to sate it.
I am too autistic to be able to handle the constant stream of bullshit and social manipulation/pressure from everywhere I have ever worked.
Problem is the morons from other industries have all decided that working in tech is now cool and le future, so they get hired at tech companies and bring all their stupid non-merit-based shenanigans with them. Good tech people don’t want to become bullshitters, so they avoid management positions, and therefore get these idiots as their bosses. The solution is to only work at small companies with flat hierarchy.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.