I generally use aliases over scripts, but one advantage of scripts is that they work “anywhere” in the command string, e.g. watch my-alias won’t work, whereas watch my-script does.
I don’t really care because in zsh you can use the -g flag in your alias to make it “global” (as another commenter mentioned), but i don’t know if this functionality is available in all shells.
This is an incredibly strange article. It has a few technical inaccuracies (Box IS a Sized type, the size of a pointer to an object doesn’t depend on the size of the object itself), but more fundamentally, it doesn’t actually answer the question it poses in the title.
For example, it complains that fat pointers are bad because they’re not supported by FFI. Nobody* writing a business app is going to care about FFI.
The rest of the article is full of “standard” complaints about Rust that I think have been fairly widely debunked, or just represent a not-well-informed view of things (e.g., the borrow checker is too hard, async sucks, etc) but even if true none of these criticisms are specific to business apps, it’s just a critique of the language itself.
I also just had to laugh at this bit:
While languages such as Go enable you to write pretty much entire HTTP service from standard lib alone, this bazaar-style package management comes with the burden: whenever you need to solve any mundane problem, you land in a space where everything has at least 7 different crates available, but half of them are actually a toy projects and most of them were not maintained for the last 5 years. And don’t get me started about audits to check if one of 600 dependencies of your hello world app won’t be used for supply chain attacks.
Yes, dependency management is a concern, but comparing to Go which famously refuses to implement basic features in the language, and then expects you to import xXx69roflcopterxXx’s github repo which is widely accepted as the best library in the ecosystem is a bit hilarious to me.
Yes, yes, I’m sure that somebody somewhere has tried to write a business app with FFI included, but it’s certainly not the norm.
Yes, dependency management is a concern, but comparing to Go which famously refuses to implement basic features in the language, and then expects you to import xXx69roflcopterxXx’s github repo which is widely accepted as the best library in the ecosystem is a bit hilarious to me.
Rust is the exact same, it just hides the GitHub repo names better. The Cargo package json would in Go be spelled "github.com/maciejhirsz/json-rust".
Well, not the exact same, because if you also decide to write your own json package for Rust you can’t register it in crates.io due to its no-namespaces naming policy. Go doesn’t restrict how many packages are allowed to match the pattern "github.com/*/json".
I think the idea is that there will be fewer glitches, since the very short time period will force automation (and you’ll learn very quickly if your automation breaks). If a site lasts more than a week, then, it’s likely to last indefinitely.
I did this for a short period of time. And then I set up automation but at some point something changed that broke my automation but it was only one every 90 days so it took me more than a year to actually sit down and fix it properly.
I have been semi seriously using jj for a couple months (i tried it earlier last year and bounced off pretty hard, so this is my second attempt). I think where I’ve come to with it is that I like it in theory a lot, and the git integration is basically required if I’m collaborating with anybody else, but in practice I find it very difficult to use and often have to drop back into git in order to get something done.
I also recognize that it’s still an early project and I haven’t had as much time to put into learning it as would be ideal, so this shouldn’t be read as a critique of the project in any way. I really hope it continues to grow and gain popularity!
not knowing how to do something in jj and not being able to (or not having the time to) figure out from the docs - I forget the exact exact details but there was some change I made recently where I couldn’t get jj to do what I wanted so I ended up just recloning the repo in a separate directory and making the change with git
i only have jj installed and set up in a handful of repos so I’m constantly context switching which repo I’m in and how to make it work.
The second problem is hypothetically solvable by just switching everywhere but the fact that I don’t understand it and have run into situations like (1) make me nervous.
Edit: Oh actually I remember now–somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
If you’re willing to use discord, the discord is very friendly to questions, even beginner ones.
The docs do need work. It’ll get there.
somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
Almost a decade ago I wrote vdirsyncer which basically does two-way sync of calendars from arbitrary sources (including gcal) in a generic way. It’s getting ported to rust now.
Oh neat! Yours looks significantly more advanced than mine… I think it doesn’t work for my use case, though, since one of my calendars is Proton Calendar, which doesn’t (afaict) expose any sort of CalDAV interface.
In the most charitable interpretation, it’s only a restatement of something from the article:
Elsewhere Pike talks about the thousands of engineers he was targeting, in his usual modest, subtle way:
The key point here is our programmers are Googlers, they’re not researchers. They’re not capable of understanding a brilliant language.
So you could even argue that “Go being great if you’re an amateur with no taste” was an explicit design goal, and perhaps we should ask Rob Pike to be better.
Ah, the good “everyone who disagrees is dumb and uncivilized” argument.
As we all know that Pike, Thompson, Griesemer, Cox, et al have no idea of what they’re doing.[/irony]
It’s fine to disagree on things, have different opinions and criticism. Heck, that’s how people decide what language they wanna use. But the reason there are more than a hand full of languages with different designs is probably not that everyone else is dumber than you.
And should “amateur” in fact not be meant as an insult, then the argument essentially becomes “to use zig you have to be smart, and not make mistakes” which judging by your other comments regarding doesn’t seem to your opinion either.
Trying to give you the benefit of the doubt here, since other than me personally not liking certain design choices I think Zig seems like a great project overall.
Ah, the good “everyone who disagrees is dumb and uncivilized” argument.
Go was explicitly designed for fresh university graduates at google, thus, amateurs. And as Pike himself says, quoted in the linked article, for people with no taste (“They’re not capable of understanding a brilliant language”). Andrew’s assessment is completely fair.
That Pike quote has been used as a stick to beat him with since 2012. I have a note about it.
It’s from a talk, so likely extemporised.
Here’s the full quote:
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.
I think it’s pejorative to state that recent CS graduates who have started working at Google before 2012 “have no taste”. No experience at writing production software at scale, sure. But software development is so much more than language.
I haven’t watched the talk, so I don’t know if the term “brilliant language” is used semi-ironically. Neither C, Java, nor COBOL for that matter are considered “brilliant”, but they have been used to write a lot of software. There’s a law of large numbers in play when it comes to writing software at scale which means that you neccesarily have to cater to the lowest common denominator of developers, which even at Google at its prime was probably lower than the average commenter here ;)
I am fully in agreement that Golang was probably a great fit for Google, and maybe still is. Its popularity outside Google is probably due to good marketing, “if we copy Google we too will succeed”, and a genuine demand for a “C-like with garbage collection and concurrency”.
For outside Google use, that last part “C-like with garbage collection” is I suggest a big part of its appeal. If one is already aware of how to write reasonable C, it is a useful mechanism to have, and less risky for small to medium sized companies than depending upon D.
If one has folks who are familiar with C, and have a problem to tackle which does not not require manual memory management, nor the tricky performance things C is often used for, then it seems an obvious option. Without dragging in a lot of the pitfalls of C++, or complexities of other languages. I’ve occasionally proposed it in such cases.
I have actually chosen to use Go for one project, specifically because of its good CSP support, as the problem domain lend itself to such a design approach. However one had to be aware to avoid certain risks: lack of immutable pointers for sends over channels, ensuring one nil’ed a pointer after sending (moving ownership), being wary of sending structs containing slices, avoiding accidental mutable captures in spawning goroutines from interior functions, etc.
Despite that it was still the easiest approach to sharing work on said program with others not familiar with the CSP approach. In many ways one can view Go as the Alef with a GC which Pike wanted Winterbottom to make, for CSP tasks it reasonably serves in that role. However it would (IMHO) be better if it had a few more of the issues I mention above addressed; that’ll have to wait for some future language.
As to general concurrency, I’ve seen a lot of Go written in a threads + mutex protecting structs style which one often sees in C and C++, so I suspect most people are not taking the effort to analyse in the CSP style, or more likely are simply unaware of it.
My point is that constantly quoting a 12 year old remark as an anti-golang trope is lazy and borderline intellectually dishonest.
I think Rob Pike knows more about Google’s workforce than most of his detractors do - and that hiring a bright young person directly from university does not give you a seasoned software developer. I also believe that an appreciation for “brilliant languages” in relation to software development is something that is developed over time, at which time the person hired by Google is probably doing something more valuable to the company bottom line than writing code.
I don’t think it’s intellectually dishonest to bring up a rude and dismissive quote from one of the designers of golang stating that golang is a dumbed-down language because its target userbase is too stupid to understand a better language.
I disagree. Disliking a language because it has multiple technical issues, like others have pointed out in this thread and others, is defensible. Disliking it because its creator said something inappropriate is not.
Even the most generous reading I can muster for Pike’s infamous remarks is something like “we want new graduates with limited breadth and depth of experience to be able to make productive contributions without having to learn a lot of new stuff.” I think the criticism of Go that is pegged to Pike’s remarks is not dislike because of what he said, it’s that its deficiencies exist in part because of the design goals these remarks lay bare. The remarks provide evidence that Go’s design was targeted at novices (“amateurs with no taste”, if you like) from whom economic productivity is expected immediately, rather than professionals with an unbounded capacity for learning and independent interest in doing excellent work.
Maybe. I still think a bunch of nerds got really angry at Pike because they didn’t get jobs at Google back in the day despite being fluent in Haskell, and they will never forget nor forgive.
I have another reason to think Pike’s quote is unattractive: it’s devious rhetoric.
He indirectly acknowledges that Go lacks a bunch of good features, fair enough. But then he insinuates that that is because those features are hard to understand (require devs “capable of understanding a brilliant language”). That is wrong on the facts, at least in the case of sum types. It is also rude: he uses the word “brilliant” as a synonym for ‘hard to understand’. That is a ‘back-handed compliment’, which is another word for ‘insult’ in the brilliant English language ;-) .
As for its relevance to Go: sure, the quote is not enough to condemn Go. But it suggests the big mistake (nil) that Go’s designers did, in fact, go on to make. Which is why there is so much cause to quote it.
The context here is about how Go was designed. A quote from the creator of the language about how it was designed at a time when it was designed seems like the most appropriate thing possible to bring up.
I agree with your second paragraph, but I see no relation to the first one. The language was designed in a certain way for certain reasons. If that was yesterday or 12 years ago does not really matter when looking at the lifecycle of the typical programming language.
Even within Google, Java is significantly bigger/more used than Go, and frankly, I don’t see much difference in their design goals. I would even say that Java is a better “Go” than Go itself - it has better concurrency primitives, now has virtual threads, very simple language with utmost care for backwards compatibility. And it is already over its growing pains (which one would think go could have easily avoided by learning from these..) - it is expressive, but not in the “redefine true to false” kind of dangerous way, has good enough generics, etc.
Also, all that development into Java’s GCs can really turn the tables in a naive performance comparison - sure, value types can make the life of the Go GC easier, but depending on workload it may not be enough to offset something like the beast G1GC is - especially in server environments where RAM is plentiful (and often have to be plentiful).
Hmm, that’s odd. Your note almost literally quotes [a Hacker News comment]((https://news.ycombinator.com/item?id=18564643), right down to the truncated link text ending in ...; but the second link was introduced with the crucial words “And there are other hints on”, and those are missing.
Go was explicitly designed for fresh university graduates at google
What does “explicitly designed” mean in this context? This feels a lot like saying Python has explicitly designed as a teaching language and C explicitly for Unix, etc.
Also I’d argue that Go - despite Google - is a lot more in the tradition of Limbo, Alef and Newsqueak.
Google plus university students sounds a lot more than Python and Java, languages already used a lot by Google.
Anyways, let’s stick to the criticism. Let’s take Limbo. Limbo is rather close to Go. Just quite a bit more niche for many reasons. However to the best of my knowledge it wasn’t “explicitly designed for fresh university graduates”, certainly not at Google which didn’t exist at the time.
Is that also a language for amateurs with no taste?
I mostly ask, because the specific context “people working at Google” under which it was created seems to be overly present in the argument, yet we talk about it largely as people who didn’t work at Google. Also Go is largely used by amateurs (compared to Python, JavaScript, etc.) seems at least debatable.
And to be clear: I hate the fact that Google seemingly at some point decided to exert a lot more control. Honestly, I even dislike the fact that Go was created at Google. The main reason I got interested in the language originally was that I tend to like software designed by the Plan 9 crowd. The fact that it was less niche - and that’s Google’s “fault” - as well as promised stability in a time where programming languages seem to largely designed like fashion, where one just adds what’s currently on-vogue piling up “old ways of doing things” until enough cruft is accumulated for everyone to leave the sinking ship of “sounds good on paper” ideas and code bases where you can tell when they were written depending on which feature was new and hip at the time. See Java’s OO features, JavaScript’s million ways to write simple loops. Pike’s talks on how Go is essentially finished, with only generics remaining[1] and focus shifting to libraries, compiler, GC, etc. seemingly confirmed that. Then Pike got quiet and Google replaced the Go website with a heavily Google branded one.
So in that sense I get where things come from. However, if you look at Go it’s also a clear next step from previous languages in the spirit of Alef, Newsqueak and Limbo. Channels exist in all of them and might be the thing that was copied the most. So that “awful, buggy concurrency primitive” has a history going back to the 80s and Go is currently the reason it’s been copied so much into other languages.
fresh university graduates at google, thus, amateurs
Why not say that then?
Wikipedia on amateur:
An amateur is generally considered a person who pursues an avocation independent from their source of income. Amateurs and their pursuits are also described as popular, informal, self-taught, user-generated, DIY, and hobbyist.
Someone who formally studied something for three years seems like a stretch. But even then, that disregards the reality of Go usage completely.
Andrew’s assessment is completely fair.
I don’t see how “having no taste” is “a fair assessment”.
go is great if you are an amateur with no taste, like 99% of google employees.
Neither says “Go was designed for” nor “fresh university graduates”. And google employees in this sentence sounds more like an example of people who are amateurs with no taste. But even if not, I don’t see how this can be interpreted in a nice/factual without losing any meaning. Let’s say Go was designed for Google employees. How is that different from Python being designed for teaching and other such things, and what does it say about the language? Is that a criticism? Why would one not want an easy to understand language?
If it’s just about it being technically correct (which seems like a stretch as described above) then what’s the thing the sentence wants to convey? In the context I’d expect it to be a criticism.
[1] look it up, their website mentioned they’d add them from pre 1.0 days and that statement only was changed after they added them. Just to counter the wrong trope of “they finally convinced them”.
As we all know that Pike, Thompson, Griesemer, Cox, et al have no idea of what they’re doing.
I feel like this is sort-of correct. They are all quite competent, but I don’t think any of them have good ideas when it comes to language design. On the other hand I don’t think I say that I agree with Andrew on language design, since I find Zig a bit Goish. There’s a lot of skill behind it and its ideas are being executed well, I just think the ideas come together into something that I feel isn’t particularly good. Obviously quite a few people like Zig and are creating great stuff with it, but the same is true of Go.
As someone who is fairly content with go (mostly due to disillusionment with everything, certainly including go), and who hasn’t used zig, can you explain to me what you don’t like about zig and how it all comes together?
Depends on your definition of “discipline” in a language. Go loses points for: nil pointers, slice/map/channel footguns, no enums/sum types. It gains points for some type safety, memory safety, first-class testing and benchmarking tooling.
I’m not familiar with Erlang but no data races is a clear advantage over Go’s approach to concurrency. Rust is probably the most disciplined language for my own definition of disciplined (too disciplined for some domains like game dev).
Go should only receive partial credit for memory safety. Most sources of memory unsafety are not present in Go, but since data races can result in memory unsafety in Go, it cannot be said to be a memory safe language. There are two approaches to fixing this: the Java way, which is to make it so that data races can’t result in memory unsafety, and the Rust way, which is to make it so that data races can’t happen.
It seems a fair tradeoff, given it often compiling to smaller and more efficient binaries than C itself.
On the other hand, Go not being memory safe with its choice of tradeoffs (middle of the pack performance with the productivity of a GC) is a very sad fact of life. (It can Segfault on race conditions, while similar languages, like java, might corrupt a given object, but that will still be well-defined java code and the runtime can just chug along).
Surely segfaulting, crashing the process, and restarting it is preferable to continuing with some internal object in an invalid/corrupt/wrong state? Not that Go is guaranteed to crash for a data race updating a map.
The former fixes the problem, the latter allows it to continue to propagate.
Segfaulting is the happy case, but it’s up to the OS to detect, not Go (more or less).
What’s much more likely is that it silently corrupts either the user’s application state, or even worse, the runtime’s state, which can yield a completely unexpected error down the line which will be impossible to debug.
But that also seems to be the implication of the java case where you wrote ‘might corrupt a given object’. So the program can still suffer knock on errors of an essentially non-deterministic nature. Just because the runtime is still valid, does not imply that the overall program is.
In Java the object you racily accessed might get into a bad state you didn’t want to get it into, but in Go, you might write into some random other object that had nothing to do with what you were accessing. It’s plain old UB that can result in pretty much anything you can think of.
The scope to which such an error can propagate is way different.
If I open a new thread and create a list with a few objects, they will 100% work in Java’s case. You can’t say the same for Go, as a hidden corruption of the runtime can rear its ugly head anywhere.
Preach. What reinforces this is the awful discourse around software dev.
Advocates for $CURRENT_TECH take most of the oxygen in the room, so toxic positivity is taken to be normative. Software design is often denigrated in favor of duct-taping more libraries together, as people love to advertise that they worship at the altar of Business Value exclusively. Most any design/testing philosophy is usually seen as “too hard,” despite bug counts being where they are. Devs regard make-work like keeping up with tiny, breaking package updates as equivalent to actually delivering value.
It’s like it’s a big social game where the objective is pretend to care less about craft and instead signal properly that you are in the group of software developers.
I feel like we live in a tech dystopia and I’m mad about it.
As I watch the city burn around me, it’s hard not to feel that way too.
Arguably it’s mainly societal pressures that create this incentive structure, however, the widespread use of a programming language as undisciplined as Go certainly factors into it.
I think it’s societal pressures that cause the incentive structure. However, I do think that there is an insidious path dependence that cements a worse is better attitude: you start with buggy software, you try to make something more better, people take a chance, it fails, and people assume that nothing better can happen so they don’t invest in better software. Progress is slow and requires risk.
At the end of the day, you are trying to make something better and more aligned with your values. I hope you succeed. I would just caution against calling tens of thousands of people amateurs. No need to paint with so broad a brush.
NB: I don’t like Go and I don’t work for Google. (Just to preempt allegations. :] )
Arguably it’s mainly societal pressures that create this incentive structure, however, the widespread use of a programming language as undisciplined as Go certainly factors into it.
See it as a stepping stone. I started as a PHP developer and then moved to Go. Rust or Zig will be my next language. If Go would replace inefficient and messy languages like PHP, Python and Ruby, that would be a win, I think. The good thing about Go is that it is simple enough to appeal to that immense group of amateur developers without taste.
Go will never replace PHP, python or Ruby because they don’t occupy the same niche to begin with.
Also, it’s rich calling these “messy and inefficient” (besides the usual caveat that language implementations are that can be slow), especially with reference to Go which is at most in the middle on a theoretical “close to bare metal” scale (the default go compiler does very little optimizations, that’s how it can output binaries fast, plus the runtime has a fairly simple GC which is no performance champion), and I think it itself is a fairly good contender on the messiness scale, given its weak type system and two million dollars mistakes instead of only one!
At least Ruby and Python give you a fast and dynamic environment for explorative programming and scripting with the capability of using very productive libraries due to the expressiveness of these languages, something in which Go is quite lacking (and that can be a fair tradeoff, mind you. But so is not taking this tradeoff).
Anyways, this can get subjective pretty quickly, resulting in language flame wars.
Fair enough. But I do think the niches of all of those languages have a large overlap. I group them all in the category: We want to run something on a server, and we don’t want it to be difficult.
‘Messiness’ is just a negative word for ‘dynamic environment.’ Both can be applicable, sometimes even at the same time. But if we are talking about the first quote, about the proliferation of bugs, then the negative interpretation feels like it has more weight. For me at least.
Arguably it’s mainly societal pressures that create this incentive structure, however, the widespread use of a programming language as undisciplined as Go certainly factors into it.
Thank you for linking to your talk, I really enjoyed it.
You didn’t even mention my least favorite “feature” of Go: panic and recover. Totally not throw/catch!
I say this as someone who has been writing Go for years. I love Go for problems I just want done ASAP but I don’t want to totally screw it up, and I love Zig for problems whose solutions I want to be as good as it possibly can be
I’ll try to remember to write some up. Working on high-performance embedded hardware has been a lot of fun but also has had a lot of deep debug sessions.
Edit: as an example, we used Ghidra to disassemble a vendor-provided closed source library, found a function that we suspected was missing a lock, and then used https://frida.re/ to dynamically fix their code to prove definitively that the missing lock was the problem. We had been getting occasional deadlocks and had used GDB to get a rough idea of what was happening but the vendor refused to believe the issue was on their end.
Very good argument, but also a possible cause of all this negativity. See, programming languages are a communication medium with a high switching cost (learning, legacy code…), which naturally gives them extremely strong network effects. People can sense, as a language rises at the top of their niche, that they will be forced to use it. Like, literally being threatened with losing their job and worse if they don’t switch.
No wonder some Linux kernel maintainers are feeling threatened.
Do people actually really get threatened with losing their job over this? I mean, if you get hired at a company and their codebase is in Ruby, and you’re like “I don’t write Ruby code” then yeah OK maybe. But, like, nobody is “forcing” anybody to do anything. Also, who really cares? I’ll write in whatever language you want if you’re gonna pay me for it.
and worse
This feels like hyperbole. Companies aren’t going to hire a hitman to take you out if you refuse to write in whatever programming language their product is in.
I meant what I said literally. In our economy/political system, when a position is no longer available, you either do something else, or you eventually run out of money. This hits harder in the US than in most Western countries. Now just imagine the Linux kernel stops doing C (it won’t any time soon, just imagine): well, at that point paid kernel devs have a choice to make:
Switch away from C, to whatever language the kernel uses.
Work on something other than the kernel.
Stop being paid.
As @david_chisnall points out, it’s more of an ecosystem problem than a company one. No individual or company is forcing anyone away from the language they’re used to, it’s the entire ecosystem that gradually stops paying those who don’t switch. In that, they are forced to switch, some of them under penalty of homelessness.
Is that such a bad thing? I’m not sure to be honest. But those are the facts as I understand them.
It’s probably less a company problem than an ecosystem one. Programming languages tend to find niches where they dominate. Web development used to mean writing CGI scripts in Perl. If you knew Perl, there were loads of jobs available writing CGI. Then PHP came along and grew as the web ecosystem grew. The number of Perl jobs may not have gone down, but it wasn’t increasing and the number of web developers was increasing hugely. Five years later, it was easy to find a job doing web development in PHP, much harder in Perl.
Imagine if Google decides that all of their future Linux contributions will be Rust, not C. If you have spent 20 years establishing yourself as a Linux kernel programmer then you are almost certainly a C expert. Now, the codebase that you work on and are an expert in shifts to being increasingly Rust focused. The abstractions that you build in C and the ones you’d want in Rust are different and so there’s a lot of friction for you to move. You effectively have to unlearn a load of the things that previously made you an expert. This makes it harder to compete with new developers who grew up with Rust and internalised the kind of design patterns that Rust uses.
The question of “is language A better than language B” is almost always “it depends”. I certainly have languages I prefer to use (I like Rust, I don’t love Go) but I will write a program in whatever language and whatever tools are best suited to the task. If it’s a pre-existing project, the answer is “whatever people are already using”; if it’s a new project, the answer is often “meh, just pick something, everything has tradeoffs”.
On whether HTML and CSS are real programming languages, I don’t think it’s gatekeeping to say that to be technically accurate they are markup languages which is a different thing than a programming language, but no less difficult to use effectively.
One thing I have often seen come up in the discussion of “what is a real programming language” are visual programming languages. I’d tell anyone that thinks they’re not that they’re laboring under the misapprehension that typing is “the hard part” of programming
Are you telling a computer what to do?
Yes -> You're programing
No -> You might still be programming
From this lens, HTML/CSS is still “programming” – you are instructing a computer how to display a thing. Whether you’re using a “real” programming language doesn’t seem all that important to me at that point. There is certainly value in developing a taxonomy of programming languages, but a) those taxonomies are blurry and nebulous (what’s the difference between an interpreted and a compiled language?), and b) they’re generally most useful for people studying programming, not people trying to do programming.
I don’t think it’s gatekeeping to say that to be technically accurate they are markup languages which is a different thing than a programming language, but no less difficult to use effectively.
Is this really true? Outside of very precise mathematical definitions (which generally aren’t relevant to these sorts of discussions), I’m not sure there’s a clear definition of a “programming language” that can be clearly distinguished from a “markup language”. You have languages like Typst or LaTeX that are very powerful programming languages in their own right, but are clearly designed to be used for marking up documents. You have configuration languages like YAML that, if interpreted correctly, can be Turing-complete, as well as other languages like Jsonnet that are Turing-complete in their default form.
Like, there’s still clearly a difference between HTML and, say, Javascript, but I think the categories we use are often very fuzzy. Like you say, visual programming clearly is a form of issuing commands to computers, even if the form of those commands is very different. Spreadsheets are another great example — you can’t necessarily issue arbitrary HTTP requests using just Excel’s cell syntax, but you are essentially doing reactive programming.
I find whenever I start putting things into categories (e.g. “programming language” vs “markup language”), it’s important to remember why I’m making those categories. It’s like asking whether a tomato is a fruit — you can’t get a sensible answer until you clarify whether you’re interested in plant biology or cooking. In that sense that the article is talking about, JS, HTML, and CSS are all necessary components in web development, and separating one of them out as the “real programming language” part of that isn’t really useful.
You have languages like Typst or LaTeX that are very powerful programming languages in their own right, but are clearly designed to be used for marking up documents. You have configuration languages like YAML that, if interpreted correctly, can be Turing-complete, as well as other languages like Jsonnet that are Turing-complete in their default form.
I think it’s more productive to focus on how fit for purpose a language is. Yes, CSS+HTML is turing-complete (I think it requires a minimum of user interaction, like wiggling the mouse around). Does that mean it’s a good idea to write a complex program in it? No, because it wasn’t designed to be used that way. Compare to something like Brainfuck, which was explicitly designed to be hard to use, or something like Excel which was designed to be easy to use for mathematical formulae with a pinch of automation. Some people build amazing works in Excel. But they are usually not maintainable or even understandable for anyone else.
The reason so many people dunk on PHP for example is not that it isn’t a programming language. Obviously it is. It’s actually extremely “fit for purpose” if you use it in the originally intended way as a simple templating language. However, it has many problems which by now we all know about which arguably make it unfit for the purpose of writing robust and secure code suitable for building a large business upon.
It’s great if someone wants to program the computer to do something they would like it to do can do so using an easy to learn/low barrier of entry language or tool. However, such tools inevitably are limited and have their problems. And it’s fine to discover those on your own, and move on to better tools. It gets more dicey when people learn such tools and then stick with them, regardless. That’s how you end up with insecure/unmaintable/messy systems, and people who have felt the pain of having to deal with them is probably how you end up with all the negativity (that, and a big dose of ego in some cases).
Anyway, sorry for the brain dump. I’m feeling a bit scatterbrained today.
Yeah, I think focusing on the purpose/fit of the language is the key. That said, I do think it’s worth second guessing our definitions of what tasks a language is suitable for. Often our impressions of other languages and tools come from hearsay and a lack of personal experience.
For example, like you said, it’s common to dunk on PHP, but as I understand it, modern PHP is a pretty powerful language, that behaves a lot more consistently than it used to and is a lot more secure than it used to be. But the hearsay sticks, and now everyone knows that PHP is a Bad Language.
That doesn’t mean we can’t have preferences — everything I’ve seen of modern PHP makes it seem like it’s Java OO taken to its logical conclusion, and that’s not a style of programming that I particularly enjoy. But I think it’s always important to understand where our preferences and gut reactions are coming from, what’s informing them, and what biases might be affecting us.
Yeah, on the one hand I would like to see the “not a real language” thing dissected with a little more scrutiny; like are you saying it’s not turing-complete? or do you mean it’s low-quality? or that people doing it are doing menial work? (with the implication that menial work and the people who do it are inferior)
But on the other hand, I think part of the point of the article was that it always means the last one, even if people claim it’s something else, and that last one sucks!
I’m reminded of many people’s attitudes towards signed languages (before I have given them a very quick lecture on what language is); as if vocalisations are the tricky part of communicating.
I avoid calling HTML and CSS programming languages[^1] only because in many ways, they’re more difficult to use effectively.
@drmorr’s sibling comment described them as “instructing a computer how to display a thing”, but that’s not really true, is it? HTML isn’t instructions for displaying a thing, it is the thing that is displayed. The instructions are inside the browser, and a lot of developer[^2][^3] frustration comes from not acknowledging that, or trying to work around that. No matter how much we yap about “semantic HTML” and “CSS is only a suggestion” and “don’t try to control the screen reader”, the programmer brain wants to tell the computer what to do, and push to production when it does it (on my machine). The MBA brain seems aligned with the programmer brain in this case, which is sad for the web designer brain.
[^1]: personally. I don’t go around telling people they’re wrong for doing that (they’re not).
[^2]: particularly the seasoned programmer who’s had to become a web developer on short notice (a common scenario in the htmx community) (this has to be linked the devaluation of web design/development skills described in the OP, right?)
I don’t think this is a great take. Privilege escalations don’t matter* for individuals. Getting root on a box that belongs to a business, on the other hand, is another matter entirely. And let’s not even talk about cloud providers.
I’ve been thinking a lot about version numbers recently, I released version 1 of a project I’m working on a few months ago and then just released version 2 last week. I don’t have a ton of users yet and it was a breaking change, so i wanted to get over the v2 hype hump before people could freak out about it. Going from 1->2 somehow “feels” like a bigger deal than going from 7->8, for example.
The counter example is the gcloud CLI which is currently on version 501.0.0………..
The slide deck is super impressive. In some ways, this feels a lot like the Choreographic Programming work being investigated by Dr. Lindsay Kuper and others. In other respects, it reminds me of the now-defunct Metaparticle project, only nicer.
This isn’t directly related to the post but the over the top language in the title and throughout caused me to bounce off pretty hard. “terrifying”? “carnage”? Really?
My general takeaway from this article is that most of the problems they bring up are because they’re trying to build devpods for EVERYBODY, and this need to think very carefully about all their isolation boundaries. It would be very bad if developer from company X could access the devpod of somebody from company Y (and slightly less bad, but still bad, if they could DoS company Y by starving them of all the node resources).
If you were trying to build an internal devpods solution for a single end user base, I think many (but not all) of the problems they bring up go away, or at least become less severe.
I think you’re right. As a moderate k8s hater, even I read these requirements and think, “Well, you’re kind of signing up for trouble”.
The promise of Kubernetes is that the platform abstractions it provides are good enough to write your own implementations that satisfy your platform’s requirements with plugins.
Even considering state management by itself. You want to avoid moving gigabytes of source/logs/whatever between machines. You want to leave the state where it is and route your client’s network connection to the state, and instatiate your execution environment “on top” of that state. In other words you have to care about where that state lives, which is a little bit against the philosophy of “you don’t care where anything lives” philosophy of k8s.
That said, Kubernetes has hooks and interfaces for every layer of this problem. You can write a scheduler for compute, you can write storage implementations, you can change the container runtime with VMs, LXC, whatever. You can mount host volumes and do seccomp profiles.
So they could have effectively written most of a k8s distribution. But is the abstraction good enough for their use case? And if not their use case, who’s use case? I think the jury’s still out.
For my own use cases, the only good experiences I’ve had as a developer have been working inside fully-managed distros with sophisticated UIs: GCP and/or OpenShift after 4.x. As an infra person, I’ve never had a good time :)
Yeah, k8s multitenancy is not really designed for this “cardinality” it’s really meant for multiple tenants within a company for example, not letting all your customers run on it.
I recently switched from pandas to duckdb, mainly because I couldn’t fit all the data I had in memory at once and duckdb is good at managing memory. I wasn’t expecting the performance most that came along with the switch, duckdb is SIGNIFICANTLY faster than pandas.
I am ambivalent about SQL versus something more python-esque… I tried to use the python native bindings but I found they got in the easy mood than they helped so I just went back to writing raw SQL queries.
I generally use aliases over scripts, but one advantage of scripts is that they work “anywhere” in the command string, e.g.
watch my-aliaswon’t work, whereaswatch my-scriptdoes.I don’t really care because in zsh you can use the
-gflag in your alias to make it “global” (as another commenter mentioned), but i don’t know if this functionality is available in all shells.This is an incredibly strange article. It has a few technical inaccuracies (Box IS a Sized type, the size of a pointer to an object doesn’t depend on the size of the object itself), but more fundamentally, it doesn’t actually answer the question it poses in the title.
For example, it complains that fat pointers are bad because they’re not supported by FFI. Nobody* writing a business app is going to care about FFI.
The rest of the article is full of “standard” complaints about Rust that I think have been fairly widely debunked, or just represent a not-well-informed view of things (e.g., the borrow checker is too hard, async sucks, etc) but even if true none of these criticisms are specific to business apps, it’s just a critique of the language itself.
I also just had to laugh at this bit:
Yes, dependency management is a concern, but comparing to Go which famously refuses to implement basic features in the language, and then expects you to import xXx69roflcopterxXx’s github repo which is widely accepted as the best library in the ecosystem is a bit hilarious to me.
Rust is the exact same, it just hides the GitHub repo names better. The Cargo package
jsonwould in Go be spelled"github.com/maciejhirsz/json-rust".Well, not the exact same, because if you also decide to write your own
jsonpackage for Rust you can’t register it in crates.io due to its no-namespaces naming policy. Go doesn’t restrict how many packages are allowed to match the pattern"github.com/*/json".I’m not sure what you call a business app. All the ones I know always have some dll-based runtime plugin / extension mechanism.
When I read that LE was going to six-day certs, my first thought was that sites would go back to http:// .
(you can argue that they shouldn’t, I’m predicting that at the first or second glitch they will)
I think the idea is that there will be fewer glitches, since the very short time period will force automation (and you’ll learn very quickly if your automation breaks). If a site lasts more than a week, then, it’s likely to last indefinitely.
You mean there are people who are updating manually every 90 days?
I did this for a short period of time. And then I set up automation but at some point something changed that broke my automation but it was only one every 90 days so it took me more than a year to actually sit down and fix it properly.
Yes
I have been semi seriously using jj for a couple months (i tried it earlier last year and bounced off pretty hard, so this is my second attempt). I think where I’ve come to with it is that I like it in theory a lot, and the git integration is basically required if I’m collaborating with anybody else, but in practice I find it very difficult to use and often have to drop back into git in order to get something done.
I also recognize that it’s still an early project and I haven’t had as much time to put into learning it as would be ideal, so this shouldn’t be read as a critique of the project in any way. I really hope it continues to grow and gain popularity!
What are the things that you’re dropping into git for, out of interest?
Two things:
not knowing how to do something in jj and not being able to (or not having the time to) figure out from the docs - I forget the exact exact details but there was some change I made recently where I couldn’t get jj to do what I wanted so I ended up just recloning the repo in a separate directory and making the change with git
i only have jj installed and set up in a handful of repos so I’m constantly context switching which repo I’m in and how to make it work.
The second problem is hypothetically solvable by just switching everywhere but the fact that I don’t understand it and have run into situations like (1) make me nervous.
Edit: Oh actually I remember now–somehow i’d gotten jj into a state where it assigned the same stable id to two different commits and it was very unhappy about that, and I couldn’t figure out how to fix it
If you’re willing to use discord, the discord is very friendly to questions, even beginner ones.
The docs do need work. It’ll get there.
This is called a “divergent change” https://jj-vcs.github.io/jj/latest/FAQ/#how-do-i-deal-with-divergent-changes-after-the-change-id and as the FAQ says, if you only want one of them, abandon the other, and if you want both, duplicate one so it gets a new change id, and then abandon the one with the duplicate change id. Hopefully that can help you for next time!
A proper debugger for rust. I am so tired of firing up rust-gdb and discovering (once again) that it doesn’t understand traits.
I’m so confused. Why wouldn’t you just use a password safe?
Almost a decade ago I wrote vdirsyncer which basically does two-way sync of calendars from arbitrary sources (including gcal) in a generic way. It’s getting ported to rust now.
Oh neat! Yours looks significantly more advanced than mine… I think it doesn’t work for my use case, though, since one of my calendars is Proton Calendar, which doesn’t (afaict) expose any sort of CalDAV interface.
that was just 30 seconds off the top of my head.
go is great if you are an amateur with no taste, like 99% of google employees.
Gotta say, it’s a bad look to just throw out insults like “go is great if you are an amateur”. Clearly many non-amateurs use it effectively.
I think you can be better.
In the most charitable interpretation, it’s only a restatement of something from the article:
So you could even argue that “Go being great if you’re an amateur with no taste” was an explicit design goal, and perhaps we should ask Rob Pike to be better.
Ah, the good “everyone who disagrees is dumb and uncivilized” argument.
As we all know that Pike, Thompson, Griesemer, Cox, et al have no idea of what they’re doing.[/irony]
It’s fine to disagree on things, have different opinions and criticism. Heck, that’s how people decide what language they wanna use. But the reason there are more than a hand full of languages with different designs is probably not that everyone else is dumber than you.
And should “amateur” in fact not be meant as an insult, then the argument essentially becomes “to use zig you have to be smart, and not make mistakes” which judging by your other comments regarding doesn’t seem to your opinion either.
Trying to give you the benefit of the doubt here, since other than me personally not liking certain design choices I think Zig seems like a great project overall.
Go was explicitly designed for fresh university graduates at google, thus, amateurs. And as Pike himself says, quoted in the linked article, for people with no taste (“They’re not capable of understanding a brilliant language”). Andrew’s assessment is completely fair.
That Pike quote has been used as a stick to beat him with since 2012. I have a note about it.
It’s from a talk, so likely extemporised.
Here’s the full quote:
Source:
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro…
https://talks.golang.org/2012/splash.article
While it’s nice to see the full quote, it doesn’t invalidate what I said, nor do I feel the sentiment is all too different in it’s full context.
I think it’s pejorative to state that recent CS graduates who have started working at Google before 2012 “have no taste”. No experience at writing production software at scale, sure. But software development is so much more than language.
I haven’t watched the talk, so I don’t know if the term “brilliant language” is used semi-ironically. Neither C, Java, nor COBOL for that matter are considered “brilliant”, but they have been used to write a lot of software. There’s a law of large numbers in play when it comes to writing software at scale which means that you neccesarily have to cater to the lowest common denominator of developers, which even at Google at its prime was probably lower than the average commenter here ;)
I am fully in agreement that Golang was probably a great fit for Google, and maybe still is. Its popularity outside Google is probably due to good marketing, “if we copy Google we too will succeed”, and a genuine demand for a “C-like with garbage collection and concurrency”.
For outside Google use, that last part “C-like with garbage collection” is I suggest a big part of its appeal. If one is already aware of how to write reasonable C, it is a useful mechanism to have, and less risky for small to medium sized companies than depending upon D.
If one has folks who are familiar with C, and have a problem to tackle which does not not require manual memory management, nor the tricky performance things C is often used for, then it seems an obvious option. Without dragging in a lot of the pitfalls of C++, or complexities of other languages. I’ve occasionally proposed it in such cases.
I have actually chosen to use Go for one project, specifically because of its good CSP support, as the problem domain lend itself to such a design approach. However one had to be aware to avoid certain risks: lack of immutable pointers for sends over channels, ensuring one nil’ed a pointer after sending (moving ownership), being wary of sending structs containing slices, avoiding accidental mutable captures in spawning goroutines from interior functions, etc.
Despite that it was still the easiest approach to sharing work on said program with others not familiar with the CSP approach. In many ways one can view Go as the Alef with a GC which Pike wanted Winterbottom to make, for CSP tasks it reasonably serves in that role. However it would (IMHO) be better if it had a few more of the issues I mention above addressed; that’ll have to wait for some future language.
As to general concurrency, I’ve seen a lot of Go written in a threads + mutex protecting structs style which one often sees in C and C++, so I suspect most people are not taking the effort to analyse in the CSP style, or more likely are simply unaware of it.
You are saying a lot of things, but what’s your point? Nothing of that invalidates the original statement.
My point is that constantly quoting a 12 year old remark as an anti-golang trope is lazy and borderline intellectually dishonest.
I think Rob Pike knows more about Google’s workforce than most of his detractors do - and that hiring a bright young person directly from university does not give you a seasoned software developer. I also believe that an appreciation for “brilliant languages” in relation to software development is something that is developed over time, at which time the person hired by Google is probably doing something more valuable to the company bottom line than writing code.
I don’t think it’s intellectually dishonest to bring up a rude and dismissive quote from one of the designers of golang stating that golang is a dumbed-down language because its target userbase is too stupid to understand a better language.
I disagree. Disliking a language because it has multiple technical issues, like others have pointed out in this thread and others, is defensible. Disliking it because its creator said something inappropriate is not.
Even the most generous reading I can muster for Pike’s infamous remarks is something like “we want new graduates with limited breadth and depth of experience to be able to make productive contributions without having to learn a lot of new stuff.” I think the criticism of Go that is pegged to Pike’s remarks is not dislike because of what he said, it’s that its deficiencies exist in part because of the design goals these remarks lay bare. The remarks provide evidence that Go’s design was targeted at novices (“amateurs with no taste”, if you like) from whom economic productivity is expected immediately, rather than professionals with an unbounded capacity for learning and independent interest in doing excellent work.
Maybe. I still think a bunch of nerds got really angry at Pike because they didn’t get jobs at Google back in the day despite being fluent in Haskell, and they will never forget nor forgive.
I have another reason to think Pike’s quote is unattractive: it’s devious rhetoric.
He indirectly acknowledges that Go lacks a bunch of good features, fair enough. But then he insinuates that that is because those features are hard to understand (require devs “capable of understanding a brilliant language”). That is wrong on the facts, at least in the case of sum types. It is also rude: he uses the word “brilliant” as a synonym for ‘hard to understand’. That is a ‘back-handed compliment’, which is another word for ‘insult’ in the brilliant English language ;-) .
As for its relevance to Go: sure, the quote is not enough to condemn Go. But it suggests the big mistake (nil) that Go’s designers did, in fact, go on to make. Which is why there is so much cause to quote it.
The context here is about how Go was designed. A quote from the creator of the language about how it was designed at a time when it was designed seems like the most appropriate thing possible to bring up.
I agree with your second paragraph, but I see no relation to the first one. The language was designed in a certain way for certain reasons. If that was yesterday or 12 years ago does not really matter when looking at the lifecycle of the typical programming language.
Even within Google, Java is significantly bigger/more used than Go, and frankly, I don’t see much difference in their design goals. I would even say that Java is a better “Go” than Go itself - it has better concurrency primitives, now has virtual threads, very simple language with utmost care for backwards compatibility. And it is already over its growing pains (which one would think go could have easily avoided by learning from these..) - it is expressive, but not in the “redefine true to false” kind of dangerous way, has good enough generics, etc.
Also, all that development into Java’s GCs can really turn the tables in a naive performance comparison - sure, value types can make the life of the Go GC easier, but depending on workload it may not be enough to offset something like the beast G1GC is - especially in server environments where RAM is plentiful (and often have to be plentiful).
Hmm, that’s odd. Your note almost literally quotes [a Hacker News comment]((https://news.ycombinator.com/item?id=18564643), right down to the truncated link text ending in
...; but the second link was introduced with the crucial words “And there are other hints on”, and those are missing.Anyway,
You’re correct, this is from the HN comment thread, which seems to be ground zero for the quote.
Thanks for clearing up the links, and thanks for the Youtube link with timestamp.
https://lobste.rs/s/tlmvrr/i_m_programmer_i_m_stupid#c_itjpt0 I noticed the same thing.
Great comment, I’ll add it to my notes about the quote.
What does “explicitly designed” mean in this context? This feels a lot like saying Python has explicitly designed as a teaching language and C explicitly for Unix, etc.
Also I’d argue that Go - despite Google - is a lot more in the tradition of Limbo, Alef and Newsqueak.
Google plus university students sounds a lot more than Python and Java, languages already used a lot by Google.
Anyways, let’s stick to the criticism. Let’s take Limbo. Limbo is rather close to Go. Just quite a bit more niche for many reasons. However to the best of my knowledge it wasn’t “explicitly designed for fresh university graduates”, certainly not at Google which didn’t exist at the time.
Is that also a language for amateurs with no taste?
I mostly ask, because the specific context “people working at Google” under which it was created seems to be overly present in the argument, yet we talk about it largely as people who didn’t work at Google. Also Go is largely used by amateurs (compared to Python, JavaScript, etc.) seems at least debatable.
And to be clear: I hate the fact that Google seemingly at some point decided to exert a lot more control. Honestly, I even dislike the fact that Go was created at Google. The main reason I got interested in the language originally was that I tend to like software designed by the Plan 9 crowd. The fact that it was less niche - and that’s Google’s “fault” - as well as promised stability in a time where programming languages seem to largely designed like fashion, where one just adds what’s currently on-vogue piling up “old ways of doing things” until enough cruft is accumulated for everyone to leave the sinking ship of “sounds good on paper” ideas and code bases where you can tell when they were written depending on which feature was new and hip at the time. See Java’s OO features, JavaScript’s million ways to write simple loops. Pike’s talks on how Go is essentially finished, with only generics remaining[1] and focus shifting to libraries, compiler, GC, etc. seemingly confirmed that. Then Pike got quiet and Google replaced the Go website with a heavily Google branded one.
So in that sense I get where things come from. However, if you look at Go it’s also a clear next step from previous languages in the spirit of Alef, Newsqueak and Limbo. Channels exist in all of them and might be the thing that was copied the most. So that “awful, buggy concurrency primitive” has a history going back to the 80s and Go is currently the reason it’s been copied so much into other languages.
Why not say that then?
Wikipedia on amateur:
Someone who formally studied something for three years seems like a stretch. But even then, that disregards the reality of Go usage completely.
I don’t see how “having no taste” is “a fair assessment”.
Neither says “Go was designed for” nor “fresh university graduates”. And google employees in this sentence sounds more like an example of people who are amateurs with no taste. But even if not, I don’t see how this can be interpreted in a nice/factual without losing any meaning. Let’s say Go was designed for Google employees. How is that different from Python being designed for teaching and other such things, and what does it say about the language? Is that a criticism? Why would one not want an easy to understand language?
If it’s just about it being technically correct (which seems like a stretch as described above) then what’s the thing the sentence wants to convey? In the context I’d expect it to be a criticism.
[1] look it up, their website mentioned they’d add them from pre 1.0 days and that statement only was changed after they added them. Just to counter the wrong trope of “they finally convinced them”.
I feel like this is sort-of correct. They are all quite competent, but I don’t think any of them have good ideas when it comes to language design. On the other hand I don’t think I say that I agree with Andrew on language design, since I find Zig a bit Goish. There’s a lot of skill behind it and its ideas are being executed well, I just think the ideas come together into something that I feel isn’t particularly good. Obviously quite a few people like Zig and are creating great stuff with it, but the same is true of Go.
As someone who is fairly content with go (mostly due to disillusionment with everything, certainly including go), and who hasn’t used zig, can you explain to me what you don’t like about zig and how it all comes together?
Come on, Andrew! No need to beat around the bush. Tell us how you really feel!
I feel like we live in a tech dystopia and I’m mad about it.
Borrowing Dan Luu’s words:
“People basically just accept that software has a ton of bugs and that it’s normal to run into hundreds or thousands of software bugs in any given week”
“widely used software is frequently 100000x slower than it could be if it were highly optimized”
Arguably it’s mainly societal pressures that create this incentive structure, however, the widespread use of a programming language as undisciplined as Go certainly factors into it.
And I’m happy to send a stray shot at Google any time for all the evil & advertisements they inflict on us.
Your language is less memory safe than Go.
What does that have to do with discipline? Erlang doesn’t have data races. Is Erlang now better than Go? (I mean, yes, but not the point.)
Depends on your definition of “discipline” in a language. Go loses points for: nil pointers, slice/map/channel footguns, no enums/sum types. It gains points for some type safety, memory safety, first-class testing and benchmarking tooling.
I’m not familiar with Erlang but no data races is a clear advantage over Go’s approach to concurrency. Rust is probably the most disciplined language for my own definition of disciplined (too disciplined for some domains like game dev).
Go should only receive partial credit for memory safety. Most sources of memory unsafety are not present in Go, but since data races can result in memory unsafety in Go, it cannot be said to be a memory safe language. There are two approaches to fixing this: the Java way, which is to make it so that data races can’t result in memory unsafety, and the Rust way, which is to make it so that data races can’t happen.
Or the Erlang way: data can only be copied, not shared.
It seems a fair tradeoff, given it often compiling to smaller and more efficient binaries than C itself.
On the other hand, Go not being memory safe with its choice of tradeoffs (middle of the pack performance with the productivity of a GC) is a very sad fact of life. (It can Segfault on race conditions, while similar languages, like java, might corrupt a given object, but that will still be well-defined java code and the runtime can just chug along).
Surely segfaulting, crashing the process, and restarting it is preferable to continuing with some internal object in an invalid/corrupt/wrong state? Not that Go is guaranteed to crash for a data race updating a map.
The former fixes the problem, the latter allows it to continue to propagate.
Segfaulting is the happy case, but it’s up to the OS to detect, not Go (more or less).
What’s much more likely is that it silently corrupts either the user’s application state, or even worse, the runtime’s state, which can yield a completely unexpected error down the line which will be impossible to debug.
Quite.
But that also seems to be the implication of the java case where you wrote ‘might corrupt a given object’. So the program can still suffer knock on errors of an essentially non-deterministic nature. Just because the runtime is still valid, does not imply that the overall program is.
So how is that any different?
In Java the object you racily accessed might get into a bad state you didn’t want to get it into, but in Go, you might write into some random other object that had nothing to do with what you were accessing. It’s plain old UB that can result in pretty much anything you can think of.
The scope to which such an error can propagate is way different.
If I open a new thread and create a list with a few objects, they will 100% work in Java’s case. You can’t say the same for Go, as a hidden corruption of the runtime can rear its ugly head anywhere.
Preach. What reinforces this is the awful discourse around software dev.
Advocates for $CURRENT_TECH take most of the oxygen in the room, so toxic positivity is taken to be normative. Software design is often denigrated in favor of duct-taping more libraries together, as people love to advertise that they worship at the altar of Business Value exclusively. Most any design/testing philosophy is usually seen as “too hard,” despite bug counts being where they are. Devs regard make-work like keeping up with tiny, breaking package updates as equivalent to actually delivering value.
It’s like it’s a big social game where the objective is pretend to care less about craft and instead signal properly that you are in the group of software developers.
As I watch the city burn around me, it’s hard not to feel that way too.
I think it’s societal pressures that cause the incentive structure. However, I do think that there is an insidious path dependence that cements a worse is better attitude: you start with buggy software, you try to make something more better, people take a chance, it fails, and people assume that nothing better can happen so they don’t invest in better software. Progress is slow and requires risk.
At the end of the day, you are trying to make something better and more aligned with your values. I hope you succeed. I would just caution against calling tens of thousands of people amateurs. No need to paint with so broad a brush.
NB: I don’t like Go and I don’t work for Google. (Just to preempt allegations. :] )
See it as a stepping stone. I started as a PHP developer and then moved to Go. Rust or Zig will be my next language. If Go would replace inefficient and messy languages like PHP, Python and Ruby, that would be a win, I think. The good thing about Go is that it is simple enough to appeal to that immense group of amateur developers without taste.
Go will never replace PHP, python or Ruby because they don’t occupy the same niche to begin with.
Also, it’s rich calling these “messy and inefficient” (besides the usual caveat that language implementations are that can be slow), especially with reference to Go which is at most in the middle on a theoretical “close to bare metal” scale (the default go compiler does very little optimizations, that’s how it can output binaries fast, plus the runtime has a fairly simple GC which is no performance champion), and I think it itself is a fairly good contender on the messiness scale, given its weak type system and two million dollars mistakes instead of only one!
At least Ruby and Python give you a fast and dynamic environment for explorative programming and scripting with the capability of using very productive libraries due to the expressiveness of these languages, something in which Go is quite lacking (and that can be a fair tradeoff, mind you. But so is not taking this tradeoff).
Anyways, this can get subjective pretty quickly, resulting in language flame wars.
Fair enough. But I do think the niches of all of those languages have a large overlap. I group them all in the category: We want to run something on a server, and we don’t want it to be difficult.
‘Messiness’ is just a negative word for ‘dynamic environment.’ Both can be applicable, sometimes even at the same time. But if we are talking about the first quote, about the proliferation of bugs, then the negative interpretation feels like it has more weight. For me at least.
Thank you for linking to your talk, I really enjoyed it.
Lol great negative PR for zig
There are two kinds of languages. Those that are tasteful and those that are actually used. 🤷♂️
List of commercial companies and non-profit organizations using Zig in production. Some serious software (Bun, TigerBeetle, Tuple) in there, even if the lists aren’t long yet.
I had a better opinion of Zig creator before. Well-well-well.
You didn’t even mention my least favorite “feature” of Go: panic and recover. Totally not throw/catch!
I say this as someone who has been writing Go for years. I love Go for problems I just want done ASAP but I don’t want to totally screw it up, and I love Zig for problems whose solutions I want to be as good as it possibly can be
I love reading debugging stories like this, I wish more people would post them
I’ll try to remember to write some up. Working on high-performance embedded hardware has been a lot of fun but also has had a lot of deep debug sessions.
Edit: as an example, we used Ghidra to disassemble a vendor-provided closed source library, found a function that we suspected was missing a lock, and then used https://frida.re/ to dynamically fix their code to prove definitively that the missing lock was the problem. We had been getting occasional deadlocks and had used GDB to get a rough idea of what was happening but the vendor refused to believe the issue was on their end.
I’m going to start interpreting all versions that I see as if ther were pride-versioned.
There’s sure a lot of rust libraries whose maintainers are deeply ashamed of their work!
/s
I was going to say. Aren’t most Rust projects pride versioned?
Very good argument, but also a possible cause of all this negativity. See, programming languages are a communication medium with a high switching cost (learning, legacy code…), which naturally gives them extremely strong network effects. People can sense, as a language rises at the top of their niche, that they will be forced to use it. Like, literally being threatened with losing their job and worse if they don’t switch.
No wonder some Linux kernel maintainers are feeling threatened.
Do people actually really get threatened with losing their job over this? I mean, if you get hired at a company and their codebase is in Ruby, and you’re like “I don’t write Ruby code” then yeah OK maybe. But, like, nobody is “forcing” anybody to do anything. Also, who really cares? I’ll write in whatever language you want if you’re gonna pay me for it.
This feels like hyperbole. Companies aren’t going to hire a hitman to take you out if you refuse to write in whatever programming language their product is in.
I meant what I said literally. In our economy/political system, when a position is no longer available, you either do something else, or you eventually run out of money. This hits harder in the US than in most Western countries. Now just imagine the Linux kernel stops doing C (it won’t any time soon, just imagine): well, at that point paid kernel devs have a choice to make:
As @david_chisnall points out, it’s more of an ecosystem problem than a company one. No individual or company is forcing anyone away from the language they’re used to, it’s the entire ecosystem that gradually stops paying those who don’t switch. In that, they are forced to switch, some of them under penalty of homelessness.
Is that such a bad thing? I’m not sure to be honest. But those are the facts as I understand them.
It’s probably less a company problem than an ecosystem one. Programming languages tend to find niches where they dominate. Web development used to mean writing CGI scripts in Perl. If you knew Perl, there were loads of jobs available writing CGI. Then PHP came along and grew as the web ecosystem grew. The number of Perl jobs may not have gone down, but it wasn’t increasing and the number of web developers was increasing hugely. Five years later, it was easy to find a job doing web development in PHP, much harder in Perl.
Imagine if Google decides that all of their future Linux contributions will be Rust, not C. If you have spent 20 years establishing yourself as a Linux kernel programmer then you are almost certainly a C expert. Now, the codebase that you work on and are an expert in shifts to being increasingly Rust focused. The abstractions that you build in C and the ones you’d want in Rust are different and so there’s a lot of friction for you to move. You effectively have to unlearn a load of the things that previously made you an expert. This makes it harder to compete with new developers who grew up with Rust and internalised the kind of design patterns that Rust uses.
The question of “is language A better than language B” is almost always “it depends”. I certainly have languages I prefer to use (I like Rust, I don’t love Go) but I will write a program in whatever language and whatever tools are best suited to the task. If it’s a pre-existing project, the answer is “whatever people are already using”; if it’s a new project, the answer is often “meh, just pick something, everything has tradeoffs”.
A few thoughts on this:
On whether HTML and CSS are real programming languages, I don’t think it’s gatekeeping to say that to be technically accurate they are markup languages which is a different thing than a programming language, but no less difficult to use effectively.
One thing I have often seen come up in the discussion of “what is a real programming language” are visual programming languages. I’d tell anyone that thinks they’re not that they’re laboring under the misapprehension that typing is “the hard part” of programming
I have very much fallen into the camp of
From this lens, HTML/CSS is still “programming” – you are instructing a computer how to display a thing. Whether you’re using a “real” programming language doesn’t seem all that important to me at that point. There is certainly value in developing a taxonomy of programming languages, but a) those taxonomies are blurry and nebulous (what’s the difference between an interpreted and a compiled language?), and b) they’re generally most useful for people studying programming, not people trying to do programming.
And according to my dad back in the day setting the clock on the VCR was “programming it” :)
more commonly, people referred to setting the recording schedule on a VCR as “programming”
Is this really true? Outside of very precise mathematical definitions (which generally aren’t relevant to these sorts of discussions), I’m not sure there’s a clear definition of a “programming language” that can be clearly distinguished from a “markup language”. You have languages like Typst or LaTeX that are very powerful programming languages in their own right, but are clearly designed to be used for marking up documents. You have configuration languages like YAML that, if interpreted correctly, can be Turing-complete, as well as other languages like Jsonnet that are Turing-complete in their default form.
Like, there’s still clearly a difference between HTML and, say, Javascript, but I think the categories we use are often very fuzzy. Like you say, visual programming clearly is a form of issuing commands to computers, even if the form of those commands is very different. Spreadsheets are another great example — you can’t necessarily issue arbitrary HTTP requests using just Excel’s cell syntax, but you are essentially doing reactive programming.
I find whenever I start putting things into categories (e.g. “programming language” vs “markup language”), it’s important to remember why I’m making those categories. It’s like asking whether a tomato is a fruit — you can’t get a sensible answer until you clarify whether you’re interested in plant biology or cooking. In that sense that the article is talking about, JS, HTML, and CSS are all necessary components in web development, and separating one of them out as the “real programming language” part of that isn’t really useful.
I think it’s more productive to focus on how fit for purpose a language is. Yes, CSS+HTML is turing-complete (I think it requires a minimum of user interaction, like wiggling the mouse around). Does that mean it’s a good idea to write a complex program in it? No, because it wasn’t designed to be used that way. Compare to something like Brainfuck, which was explicitly designed to be hard to use, or something like Excel which was designed to be easy to use for mathematical formulae with a pinch of automation. Some people build amazing works in Excel. But they are usually not maintainable or even understandable for anyone else.
The reason so many people dunk on PHP for example is not that it isn’t a programming language. Obviously it is. It’s actually extremely “fit for purpose” if you use it in the originally intended way as a simple templating language. However, it has many problems which by now we all know about which arguably make it unfit for the purpose of writing robust and secure code suitable for building a large business upon.
It’s great if someone wants to program the computer to do something they would like it to do can do so using an easy to learn/low barrier of entry language or tool. However, such tools inevitably are limited and have their problems. And it’s fine to discover those on your own, and move on to better tools. It gets more dicey when people learn such tools and then stick with them, regardless. That’s how you end up with insecure/unmaintable/messy systems, and people who have felt the pain of having to deal with them is probably how you end up with all the negativity (that, and a big dose of ego in some cases).
Anyway, sorry for the brain dump. I’m feeling a bit scatterbrained today.
Yeah, I think focusing on the purpose/fit of the language is the key. That said, I do think it’s worth second guessing our definitions of what tasks a language is suitable for. Often our impressions of other languages and tools come from hearsay and a lack of personal experience.
For example, like you said, it’s common to dunk on PHP, but as I understand it, modern PHP is a pretty powerful language, that behaves a lot more consistently than it used to and is a lot more secure than it used to be. But the hearsay sticks, and now everyone knows that PHP is a Bad Language.
That doesn’t mean we can’t have preferences — everything I’ve seen of modern PHP makes it seem like it’s Java OO taken to its logical conclusion, and that’s not a style of programming that I particularly enjoy. But I think it’s always important to understand where our preferences and gut reactions are coming from, what’s informing them, and what biases might be affecting us.
Yeah, on the one hand I would like to see the “not a real language” thing dissected with a little more scrutiny; like are you saying it’s not turing-complete? or do you mean it’s low-quality? or that people doing it are doing menial work? (with the implication that menial work and the people who do it are inferior)
But on the other hand, I think part of the point of the article was that it always means the last one, even if people claim it’s something else, and that last one sucks!
I’m reminded of many people’s attitudes towards signed languages (before I have given them a very quick lecture on what language is); as if vocalisations are the tricky part of communicating.
I avoid calling HTML and CSS programming languages[^1] only because in many ways, they’re more difficult to use effectively.
@drmorr’s sibling comment described them as “instructing a computer how to display a thing”, but that’s not really true, is it? HTML isn’t instructions for displaying a thing, it is the thing that is displayed. The instructions are inside the browser, and a lot of developer[^2][^3] frustration comes from not acknowledging that, or trying to work around that. No matter how much we yap about “semantic HTML” and “CSS is only a suggestion” and “don’t try to control the screen reader”, the programmer brain wants to tell the computer what to do, and push to production when it does it (on my machine). The MBA brain seems aligned with the programmer brain in this case, which is sad for the web designer brain.
[^1]: personally. I don’t go around telling people they’re wrong for doing that (they’re not).
[^2]: particularly the seasoned programmer who’s had to become a web developer on short notice (a common scenario in the htmx community) (this has to be linked the devaluation of web design/development skills described in the OP, right?)
[^3]: and user frustration.
I don’t think this is a great take. Privilege escalations don’t matter* for individuals. Getting root on a box that belongs to a business, on the other hand, is another matter entirely. And let’s not even talk about cloud providers.
*don’t matter as much
I’ve been thinking a lot about version numbers recently, I released version 1 of a project I’m working on a few months ago and then just released version 2 last week. I don’t have a ton of users yet and it was a breaking change, so i wanted to get over the v2 hype hump before people could freak out about it. Going from 1->2 somehow “feels” like a bigger deal than going from 7->8, for example.
The counter example is the gcloud CLI which is currently on version 501.0.0………..
Source code is available for the demo: https://github.com/acrlabs/kompile
Slides are available here: https://static.sched.com/hosted_files/kccncna2024/1b/What%20if%20Kubernetes%20was%20a%20compiler%20target_.pdf
The slide deck is super impressive. In some ways, this feels a lot like the Choreographic Programming work being investigated by Dr. Lindsay Kuper and others. In other respects, it reminds me of the now-defunct Metaparticle project, only nicer.
Tim is actually one of Dr. Kuper’s students!
I did not realize that, how absolutely wonderful!
I’m at kubecon this week! Are there any other lobsters folk attending? Would be fun to do a lobsters meetup or something if there’s enough of us.
This isn’t directly related to the post but the over the top language in the title and throughout caused me to bounce off pretty hard. “terrifying”? “carnage”? Really?
My general takeaway from this article is that most of the problems they bring up are because they’re trying to build devpods for EVERYBODY, and this need to think very carefully about all their isolation boundaries. It would be very bad if developer from company X could access the devpod of somebody from company Y (and slightly less bad, but still bad, if they could DoS company Y by starving them of all the node resources).
If you were trying to build an internal devpods solution for a single end user base, I think many (but not all) of the problems they bring up go away, or at least become less severe.
I think you’re right. As a moderate k8s hater, even I read these requirements and think, “Well, you’re kind of signing up for trouble”.
The promise of Kubernetes is that the platform abstractions it provides are good enough to write your own implementations that satisfy your platform’s requirements with plugins.
Even considering state management by itself. You want to avoid moving gigabytes of source/logs/whatever between machines. You want to leave the state where it is and route your client’s network connection to the state, and instatiate your execution environment “on top” of that state. In other words you have to care about where that state lives, which is a little bit against the philosophy of “you don’t care where anything lives” philosophy of k8s.
That said, Kubernetes has hooks and interfaces for every layer of this problem. You can write a scheduler for compute, you can write storage implementations, you can change the container runtime with VMs, LXC, whatever. You can mount host volumes and do seccomp profiles.
So they could have effectively written most of a k8s distribution. But is the abstraction good enough for their use case? And if not their use case, who’s use case? I think the jury’s still out.
For my own use cases, the only good experiences I’ve had as a developer have been working inside fully-managed distros with sophisticated UIs: GCP and/or OpenShift after 4.x. As an infra person, I’ve never had a good time :)
Yeah, k8s multitenancy is not really designed for this “cardinality” it’s really meant for multiple tenants within a company for example, not letting all your customers run on it.
I recently switched from pandas to duckdb, mainly because I couldn’t fit all the data I had in memory at once and duckdb is good at managing memory. I wasn’t expecting the performance most that came along with the switch, duckdb is SIGNIFICANTLY faster than pandas.
I am ambivalent about SQL versus something more python-esque… I tried to use the python native bindings but I found they got in the easy mood than they helped so I just went back to writing raw SQL queries.
FTFY
Sigh. Stupid phone. Thanks