Also, OCaml had trouble with multithreading for quite some time, which was a limiting factor for many applications.
Facebook made a large effort to thrust OCaml into the limelight, and even wrote a nice alternative frontend (Reason). Sadly, it did not stick.
Old but funny comparison: http://adam.chlipala.net/mlcomp/
> 1/100th the momentum and community and resources of Go or Rust
I think even 1/100 would be pretty generous.
If you look at it from that perspective, then Rust is the hobby language.
How different?
Rust has functional programming features and no garbage collection, because the borrow checker can tell when a closure will outlive the references in its captured environment. We used to think that would not be feasible other than perhaps in very special cases - hence the need for GC to keep that environment around - but Rust proved that wrong quite convincingly.
It's not about not having a C-like syntax (huge mainstream points lost), good momentum, and not having the early marketing clout that came from Rust being Mozilla's "hot new language".
* Rust has a C++-flavored syntax, but OCaml has a relatively alien ML-flavored syntax.
* Rust has the backing of Mozilla, but I don't think OCaml had comparable industry backing. (Jane Street, maybe?)
I do not at all agree with this. Rust is by far the most complex language in terms of syntax that has ever become popular enough to compare it to anything.
But you use it more and see actionscript types of function notation, funtional language semantics where you just "return" whatever was the last expression in a statement, how structs have no bodies (and classes aren't a thing) and instead everything is implemented externally, and it starts to really become its own beast.
> Rust's syntax is similar to that of C and C++,[43][44] although many of its features were influenced by functional programming languages such as OCaml.[45] Hoare has described Rust as targeted at frustrated C++ developers...[15]
I'm not sure what "actionscript types of function notation" means, but Rust's closures syntax (|x| ...) was probably inspired by Ruby and/or Smalltalk. Anyway, sure, the expression-orientedness, implicit return, etc., are very un-C++-like, but I do think the syntax was explicitly designed to be approachable to C++ developers.
[0]: https://en.wikipedia.org/w/index.php?title=Rust_(programming...
Can you show example of "written by random cat" code you often see?
The difference between academia languages such as ocaml or haskell and industry languages such as Java or C# is hundreds of millions of dollar in advertising. It's not limited to the academy: plenty of languages from other horizons failed, that weren't backed by companies with a vested interest in you using their language.
You should probably not infer too much from a language's success or failure.
Yes.
> in advertising
No, in hiring 500 compiler and tool developers, developing and supporting libraries, optimizing it for niche use cases.
[1]: https://www.theregister.com/2003/06/09/sun_preps_500m_java_b...
No, I'm not talking about financial backing in general, I'm talking specifically about advertising the language.
There's no doubt that a big ecosystem helps a lot, Python is a good proof of that ; but this is not what i was talking about.
Java and C# are the only one's that fit this. Go and Rust had some publicity from being associated with Google and Mozilla, but they both caught on without "millions of dollars in advertising" too. Endorsement by big companies like MS came much later for Rust, and Google only started devoting some PR to Go after several years of it already catching momentum.
No amount of advertising is going to propel Haskell to a mainstream language. If it wants to succeed (and let's be honest, it probably doesn't), it's going to need an investment of millions of developer-hours in libraries and tooling. No matter how pretty and elegant the language may be, if you have to reinvent the wheel every time you go beyond "hello world" you're going to think twice before considering it for production code.
Rust is a significant counterexample
Hell, the early versions of the Rust compiler were written in OCaml...
Also I would argue the rust compiler started as a hobby project
A version of React was built to run in ReasonML, which is a flavor of Ocaml for the web, but Reason didn't even exist before React was fairly well established.
Hell, Facebook's own XHP's interface (plus PHP/Hack's execution model) is more conceptually relatable to React, and its initial development predates Jordan's time at Facebook. It wasn't JavaScript, but at the very least it defined rails for writing applications that used the DOM.
> Yes, the first prototype of React was written in SML; we then moved onto OCaml.
> Jordan transcribed the prototype into JS for adoption; the SML version of React, however great it might be, would have died in obscurity. The Reason project's biggest goal is to show that OCaml is actually a viable, incremental and familiar-looking choice. We've been promoting this a lot but I guess one blog post and testimonial helps way more.
I kind of like that Ruby is still focusing on single developer/small team productivity.
Your list is at least missing PHP, Typescript, Swift, Go, Lua, Ruby and Rust though.
But Ocaml really doesn't belong anywhere close to this list.
OCaml runs software that billions use, is used by financial and defense firms, plus Facebook.
But Lua? By that metric I'm throwing in every language I've ever seen a job for...
R, Haskell, Odin, Lisp, etc...
Edit - this site is basically a meme at this point. Roblox is industrial strength but Facebook, Dassault and trading firms are "hobby". Lol.
Also, I'm not dissing Lua, there's just irony in calling Lua industrial but not OCaml...
Do realize that luajit for years was bankrolled by corporations.
Lua, Bash ... these are birds of a feather. They are the glue holding things together all over the place. No one thinks about them but if they disappeared over night a LOT of stuff would fall apart.
The most famous example being World of Warcraft, but it's far from the only one. If you play, or have played, games, you almost certainly have run software built with Lua without realizing it.
It's not because a language isn't relevant in your personal coding niche that it's not industrially relevant.
OCaml's use is comparatively very, very narrow.
And, in case you are wondering, I have absolutely nothing again OCaml. In fact, my first ever programming language was, as a significant fraction of French engineer from my generation, the “Lite” dialect of Caml. And I suspect that its OCaml heritage is a significant fraction of the reason why I love Rust.
But being used by exactly one FANG company, a single finance one and allegedly a defense company (aren't you confusing Dassault System with Dassault Aviation ?) isn't enough to change its status, especially when it's not the dominant language in two of those (AFAIK Jane Street really is the only one where OCaml has such a central place).
Dassault Aviation makes the planes themselves. All Dassault companies are under one umbrella anyway.
The OCaml website lists a bunch of other users.
In my opinion, none of that really matters, any single one of those uses proves it's utility... Facebook Messenger alone is probably used by more people than every piece of Lua software ever made though.
First, Dassault Systèmes doesn't fall "under one umbrella" with Dassault aviation, it is an independent public company (with the Dassault group having minority shares in the company). And just because a software company has defense related products doesn't make it a “defense company”, nobody would ever call either IBM or Microsoft “Defense Companies”.
Then Facebook doesn't seem to be using Ocaml in Facebook Messenger, and instead uses its standard tech stack for that (the Hack PHP derivative).
The fact that Facebook has a developer-facing team building internal development tools with OCaml doesn't suffice to change the status of a language: since there are barely any Ocaml developers at Facebook, an Ocaml enthusiast would have to be very, very lucky to land an Ocaml job there…
And that's the whole point of the “hobby language” status: can you land a job using it or not, and Ocaml simply isn't that kind of language. And again, France has been teaching Ocaml to at least a hundred thousands of students over the years.
Most of my smaller projects don't benefit so much from the statically proven compile time guarantees that e.g. Rust with it's borrow checker provide. They're simple enough to more-or-less exhaustively test. They also tend to have simple enough data models and/or lax enough latency requirements that garbage collectors aren't a drawback. C#? Kotlin? Java? Javascript? ??? Doesn't matter. I'm writing them in Rust now, and I'm comfortable enough with the borrow checker that I don't feel it slows me down, but I wouldn't have learned Rust in the first place without a borrow checker to draw me in, and I respect when people choose to pass on the whole circus for similar projects.
The larger projects... for me they tend to be C++, and haven't been rewritten in Rust, so I'm tormented with a stream of bugs, a large portion of which would've been prevented - or at least made shallow - by Rust's borrow checker. Every single one of them taunts me with how theoretically preventable they are.
Borrow checker is my friend, it helps me write better code, but it doesn't stops me when I don't care about code quality and just want a task to be done.
Except both of these things are that way for a reason.
The author talks about the pain of having other refactor because of the borrow checker. Every one laments having to deal with errors in go. These are features, not bugs. They are forcing functions to get you to behave like an adult when you write code.
Dealing with error conditions at "google scale" means you need every one to be a good citizen to keep signal to noise down. GO solves a very google problem: don't let JR dev's leave trash on at the campsite, force them to be good boy scouts. It is Conways law in action (and it is a good thing).
Rust's forced refactors make it hard to leave things dangling. It makes it hard to have weak design. If you have something "stable", from a product, design and functionality standpoint then Rust is amazing. This is sort of antithetical to "go fast and break things" (use typescript, or python if you need this). It's antithetical to written in the stand up requirements, that change week to week where your artifacts are pantomime and post it notes.
Could the borrow checker be better, sure, and so could errors in go. But most people would still find them a reason to complain even after their improvement. The features are a product of design goals.
Also, in my experience, the Rust maintainers generally err on the side of pragmatism rather than opinionatedness; language design decisions generally aren't driven by considerations like "this will force junior developers to adhere to the right discipline". Rust tries to be flexible, because people's requirements are flexible, especially in the domain of low-level programming. In general, they try to err on the side of letting you write your code however you want, subject to the constraints of the language's two overriding design goals (memory safety and precise programmer control over runtime behavior). The resulting language is in many ways less flexible than some more opinionated languages, but that's because meeting those design goals is inherently hard and forces compromises elsewhere (and because the language has limited development resources and a large-but-finite complexity budget), not because anyone views this as a positive in and of itself.
(The one arguable exception to this that I can think of is the lack of syntactic sugar for features like reference counting and fallible operations that are syntactically invisible in some other languages. That said, this is not just because some people are ideologically against them; they've been seriously considered and haven't been rejected outright, it's just that a new feature requires consensus in favor and dedicated resources to make it happen. "You can do the thing but it requires syntactic salt" is the default in Rust, because of its design, and in these cases the default has prevailed for now.)
I don't think this is a bad thing but it's a funny consequence that to become mainstream you have to (1) announce a cool new feature that isn't in other languages (2) eventually accept the feature is actually pretty niche and your average developer won't get it (3) sand off the weird features to make another "C but slightly better/different"
Personally I just far prefer to work in a GCed langauge. Much simpler mental model.
That's the requirement for 100% if professional software development.
"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."
And interpreting the quote charitably I'm going to have to agree with it - I don't think many of my coworkers care enough to get to the point where they'd appreciate everything something like Haskell can do for them.
Most programmers are "lousy programmers" because most of the are not researchers and have no interest in theory.
I can write in Go or Rust (or anything else given some time) but I won't ever use Rust to write any kind of business logic for my company - and this is what I do most of the time I actually write code.
Why? Because Rust is terrible for the job (at least if we are talking about real life scenario where the job should be done in hours and not weeks)
but this would be a problem almost anywhere, no?
This has nothing to do with Rust vs Go vs Ruby or something else. Rust makes this even bigger problem, ok, but I don't think we should call people not using Rust (c\c++ etc) "lousy".
PS: tbh this kind of statements usually (from my experience) come from people who mainly write system level software or work with hardware directly.
That is exactly how it was sold.
A safe C, or a nicer simpler Java.
Nobody cared about Erlang back then and nobody does today.
I write Erlang for a living.
It's never been "safe C" because it's garbage collected. Java is truly the comp because it's a great Grug language.
I also wrote some Erlang in the past, I really enjoy it and I was sad that Go didn't borrow more.
Nobody may have known they cared about Erlang, but those features sure made people pay attention.
I think this is incredibly correct and obviously personally true for you but I'd like to add one more thing from the peanut gallery.
No one really needs Erlang either. Turns out most problems are just fine not being modeled in the way that Erlang wants to model problems.
Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.
Yeah it was a bit vague -- I should have said something more like "not many developers/teams/companies need telecom level uptime and resilience enforced at the single system level". In reality, most groups have solved this by redundancy and building multiple systems/distributing them. You could argue it's the wrong solution, but it's been good enough for so many people that... it's probably fine.
Ironically, Java was sold as a "nicer simpler C++".
Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained executable.
I would say that Go is mostly a better Modula-2 (with bits of Oberon); it's only better from the language standpoint because now it has type parameters, but GC definitely helps make writing it simpler.
A lot of very smart stuff is written in Go by programmers who just want the language to get the hell out of their way. Go is some ways very good at that. Rough though if you want your programming language to model your problem domain or your algorithmic approach! TANSTAAFL.
Having used go in anger I don’t necessarily agree with this, could you point out an example. Maybe I just accepted it and work around it without paying much attention.
If you are referring to interface types being able to be null, well they are allocated on the heap and have dynamic dispatch, this isn’t particularly a surprise if you have worked in a lower level language but might be a surprise if you come from a language where that isn’t the case.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I'm curious to know why you think so, I thought it was a great article, showcasing how simplicity in the language doesn't make complexity go away, it just moves it to programs written in it.
And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive.
The read situation is literally not understanding or even looking up the interface, there is another return value that will tell you the channel is closed.
Nil channel reads make sense for it to do what it does if your familiar with the interface but at the same time you are literally holding it wrong. Vs a language where that would be UB its an improvement. Compared to a language like rust sure the information isn’t available at compile time but on the same not you would need to be developing in rust, and no offence but if you think golangs concurrency story is difficult to grasp just wait until you meet async rust…
These are the unintuitive, these are generally complaints of you failed to even begin to read the documentation and then complain when things aren’t doing what you expect, leave your preconceived notions at the door and you will be fine.
The faster than lime take needs to be updated, comparing golang from 5 years ago to modern golang is about as useful as comparing rust fron 5 years ago to rust now.
And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing.
Because you don’t know how doesnt mean it’s unintuitive, it means you don’t know how.
Not having to call into ffi/c libraries to modify files is the normal use case. Windows is the largest used operating system.
> Because you don’t know how doesnt mean it’s unintuitive,
Do you know what the definition of unintuitive is? If it was intuitive you wouldn’t be able to “hold it wrong”.
A “systems” language designed by some smart people that is mostly targeted at the most deployed os in the world “cough not windows”, definitely does not need to make windows the default.
> If it was intuitive you wouldn’t be able to “hold it wrong
No unintuitive means if you understand the domain and idioms yet the interface still does not make sense. Returning multiple values when reading and passing context around (even in a wrapper) is normal intuitive golang.
So is allocating complex object instead of simply instantiating them, sure this point is slowly moving out of idiomatic golang but at the same time the history is important.
Not understanding CSP and not liking explicit return values does not mean it is unintuitive.
I can see this conversation will go no where though. This is the typical conversation with Go users when you point out any criticism of the language. Cheers man.
You don’t. Normal operation like reading writing modifying and creating works just fine in windows.
The only thing that doesn’t is explicitly permissions where windows is the outlier and uses (imho a better) method of managing permissions. However they are the outlier and it is an uncommon operation. Why would the stdlib cater for that?
If you need to alter permissions at a more granular level on windows than is possible using golangs interface then call into the ffi, but in general you don’t need to to that.
If that is your only criticism then I agree we will not agree on this point, it is however also trivial to make ffi calls using go
Of the few technical advantages Go had for us is that we don't need a single dependency outside of the standard library, which can't live in isolation. We use SQLC and Goose, both are run in containers that only have rights and access on the development side of things.
I'm not sure I would say that Golang has a lot of weird, pointless quirks, but it has opinions and if you happen to dislike them, well... that sucks. I hate the fact that they didn't want runtime assertions as an example, so it's not like I don't understand why people dislike Go for various reasons. I've just accepted that those strong opinions is the reason Go is so productive.
The challenge for us is that it's not exactly as productive as Python. So while you'll need to do a lot of toolchain work to get Python anywhere near Go's opinionated stucture, that is often a better choice if you're not a hardcore software engineering team. At least for us, it's been much easier to get our business intelligence people to adopt UV, pyrefly, ruff and specific VSC configs for their work than to have them learn Go.
I suspect that is why Rust is also doing so well. Go is a better Java/C# for a lot of places, but are you really going to replace your Java/C# with Go if you have dacades worth? If you're not coming from Java/C# will you really pick Go over Rust? I'm not sure, but I do know, Go failed to become a Python replacement for us. It did replace our C#, but we didn't have a lot of C#. Eventually we'll likely replace our Go with C/Zig and Python to keep the language count lower.
So you hate writing:
if (something != 1) {
panic("oh no!")
}
assert(something != 1, "oh no!")
You're taking it out of a context of me praising Golang, however, and while I do hate the fact that they didn't just do runtime assertions, it's not like I dislike Go as a whole because of it.
So compared to... very niche languages? Go has exceptionally few quirks compared to mainstream languages.
This isn't meant to be allegorical or anything specific. I guess it's just an observation that sometimes your lunch can be cheaper than you thought.
Rust is more appropriate for areas where the problem boundaries are relatively fixed and slow-moving: libraries, backend services, and infrastructure.
By better allowing you to model your program domain, Rust actually lets you finish projects that are feature complete. I have multiple Rust projects in production for years that have needed at most one or two bugfix releases after their initial rollout on top of a half a dozen feature updates. For a very slight additional startup cost in doing that modeling, I’ve gotten massive dividends back in the volume of maintenance programming that hasn’t needed to be done.
But if your problem domain changes frequently enough that the model needs to be changed all the time, that extra inflexibility isn’t worth it. On the other hand, I don’t know much go software that isn’t beset by the same number of bugs as every other modern language.
There are numerous interviews with Rob Pike about the design of Go from when Go was still being developed, and Erlang doesn't come up in anything that I can find other than this interview from 2010 where someone asks Rob Pike a question involving Erlang and Rob replies by saying he thinks the two languages have a different approach to are fairly different:
https://www.youtube.com/watch?v=3DtUzH3zoFo
It's at the 32 minute mark, but once again this is in response to someone asking a question.
Here are other interviews about Go, and once again in almost every interview I'd say Rob kind of insinuates he was motivated by a dislike of using C++ within Google to write highly parallel services, but not once is Erlang ever mentioned:
https://www.informit.com/articles/article.aspx?p=1623555
The point of my comment is that to say that Go is basically Erlang style CSP without the weird syntax is not justified as an actual quote nor as a paraphrasing or summary of anything that anyone involved in the design or promotion of Go has ever said. It's best to reserve quotes for situations where someone actually said something or as a way to summarize something for which there are ample references available.
One should not use quotes as a way to present mostly original claims that are presented as if it's some kind of already well established knowledge.
And performant enough.
Engineers ship with them, and do not care if there’s a purer system elsewhere.
I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the framework level. Most channels that developers interact with is the `Context.Done()` channel with <-chan struct{}.
Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.
Non-buffering channels are much simpler to reason about and have very useful semantics in pipelines.
Are these people here in the room with us right now?
Go is like C but with concurrency/strings/GC/a good stdlib
Go is like C++ but simpler/fast compilation/no generics/a good stdlib
Go is like Python but statically typed/multithreaded/fast/single executable
Go is like Java but native/no OO
---
One thing Go haters rarely reckon with is that Go is the only popular modern language (ie from this millennium). Everything else is way older. Well, I would actually say that this is probably the cause of Go hate--if it weren't popular no one would care.
This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.
- TIOBE [0]: Go 7 :: Rust n/a (> 10)
- IEEE Spectrum [1]: Go 8 :: Rust 11
- Stack Overflow [2]: Go 13 :: Rust 14 (they're pretty close here)
- GitHub [3]: Go 10 :: Rust n/a (> 10)
- PYPL [4]: Go 12 :: Rust 10
- HackerRank [5]: Go 8 :: Rust n/a (> 13)
- Pluralsight [6]: Go 9 :: Rust n/a (> 10)
- Redmonk [7]: Go 12 :: Rust 19
Although I admit we probably don't have great measures of this, there's clearly a sizable gap here.
Maybe you'd want to argue about TypeScript, Swift or Kotlin? I consider TypeScript JavaScript (because TypeScript wouldn't be popular unless all JavaScript programs were TypeScript programs), and I think Swift and Kotlin only survive because of their mobile platforms (they're also all below Go in these lists, on average).
[0]: https://www.tiobe.com/tiobe-index/
[1]: https://spectrum.ieee.org/top-programming-languages-2024
[2]: https://survey.stackoverflow.co/2024/technology
[3]: https://github.blog/news-insights/octoverse/octoverse-2024/#...
[4]: https://pypl.github.io/PYPL.html
[5]: https://www.hackerrank.com/blog/most-popular-languages-2024/
[6]: https://www.pluralsight.com/resources/blog/upskilling/top-pr...
[7]: https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
The claim made was "Go is the only popular modern language (ie from this millennium)"
That's a binary, either a programming language is "modern" (from this millennium) or not and either it is "popular" (undefined) or it is not, Go is popular and modern according to the claim.
On your lists you find Go is anywhere from 7th to 13th in popularity. So apparently "popular" might mean 9th like Ada on TIOBE's list right? Or maybe "modern" includes Typescript, on several of these lists?
No, the whole contrivance is silly. Go is a relatively popular modern language, nobody is surprised to discover that. Is it the most popular? No. Is it the most modern? Also no.
>> This requires you to squint so that "popular" happens to identify only a handful of languages but conveniently catches Go and not say Swift or Rust. It's not difficult to do this, but it's not very honest to yourself.
> You seem to be arguing that Go is more popular than Rust, but that's not what we're talking about.
Isn't this exactly what we're talking about? I don't think you have to squint too hard to invent the gap between Go and Rust (et al).
> So apparently "popular" might mean 9th like Ada on TIOBE's list right?
No because it's only on that list.
> Or maybe "modern" includes Typescript, on several of these lists?
No because TypeScript is JavaScript, which is from the last millennium.
> No, the whole contrivance is silly.
Emotionally I agree with you, but in practice you gotta pick a stack, and there's a lot of benefit to choosing Go over Rust/Kotlin/Swift/TypeScript/Java/C#/C/C++/Ada.
> Go is a relatively popular modern language, nobody is surprised to discover that.
Eh I'm making the Stroustrup "there's two kinds of programming languages" argument. IMO, at this point Go criticisms are just jeers from the cheap seats.
So, if you don't count the lists where it isn't in the top ten, and you don't count languages like Typescript? Does that feel like an important distinction to you with the exceptions, rather than an arbitrary post doc justification ?
> Isn't this exactly what we're talking about? I don't think you have to squint too hard to invent the gap between Go and Rust (et al).
Likewise for Go and Python or Javas, so why the "top 10" ? Arbitrary.
> TypeScript is JavaScript
No. Javascript is (very bad) Typescript, but Typescript is not Javascript. That's why they have a transpiler.
If you contend that the similarity means they're the same language that makes C++ also C and I don't think you want to start that fight.
My pithy response to the Stroustrup argument is a T-shirt I own which says "Haters gonna make some good points". Yes of course people will criticize your popular language, but this observation does not make the criticisms untrue, and resorting to Stroustrup's argument is best understood as an admission that he has no response to the actual criticism.
C++ is remarkably bad. You're looking at popularity lists. What else is on those lists which has similar levels of criticism? Go is a long way short of perfect but it's nowhere close to C++. If Go is the Stallone "Judge Dredd" then maybe C++ is "Batman & Robin".
I feel like we both understand each other at this point so I'll ask because I'm curious, what languages are you into? I'd really like a chance to dig into Erlang, OCaml, or Racket, but I can never really justify it. Mostly I'm a boring C/Python person (believe it or not, I don't like Go all that much)
I currently get paid to write, among other things, C#, Python, PHP, Perl, and bash. Historically I have also been paid to write C, Java, and Go, among other things.
In contrast "Batman & Robin" is terrible. Clooney said he didn't want friends and family to see it because he is rightfully ashamed to have done it. Sometimes an actor does good work but it's hard to see because the technicians are incompetent and the editor destroys their effort in the cut - however it's clear Clooney was not trying.
Alicia Silverstone has been in utter trash, some of which I have watched because I used to live with a guy who was obsessed with her - but it's notable that even the icky "technically this isn't pornography" stuff she did as a teenager is more competent than "Batman & Robin" for which she was presumably much better paid.
Joel Schumacher can do excellent work so why is "Batman & Robin" so awful? Did the Studio tell him nothing else matters so long as the branding is there because comic book fans will show up anyway? If so maybe it's partly their fault, but a good artist should have more pride in their own work than to do this.
I have more recently (well, this century) gone to a "live MST3K" type event where they screen the original film but talk over it. They warned us that "Batman & Robin" is too awful for this format to save it, but I didn't listen and yeah, long before the closing credits lots of people walked out because they were right and it's unsalvageable.
I actually lived near a movie theater that got bought out by someone very weird and ostensibly rich, and they just played bad movies to jeer at and mock, and every... Friday was Rocky Horror Picture Show night. I think the small town I was in revolted and raised money to then buy that guy out, but man what a time. Surprised they didn't screen this steamer lol, is all I'm saying.
How do you figure Swift is not a general purpose language ?
Rust. TypeScript. Swift.
28.0M JS+TS
...
5.6M Swift
5.1M Rust
5.0M Go
There aren't a lot of reports presenting absolute numbers and not biased toward a handful of platforms or ecosystems. If you know of other good free ones, feel free to share.
https://research.slashdata.co/reports/6814fddffed4a97023eab0...
EDIT: also I gotta say these numbers seem kinda high. It's hard for me to imagine there's ~28m JS programmers worldwide; that's 1/286 people in the entire world, and the ratio gets less believable as you shrink down the number of people who might have any access at all to a computer/internet/etc. Unless this definition is super broad, I'm quite skeptical.
But golang/newsqueak was developed much earlier, in the early 80s by Rob Pike.
https://en.wikipedia.org/wiki/Newsqueak
```
type point: struct of{ x, y: int; }
a:=mk(array[10] of int) // mk renamed to make
select{ case i = <-c1: a = 1; case c2<- = i: a = 2; }
```
In the late 2000s, this language updated somewhat (for example, the mk function was renamed to make).
Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.)
Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk of the ecosystem. There are other issues too with having fibers in a C-like systems programming language - see https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... for a nice summary of them.
The plan9 libthread (which reimplemented the Alef concurrency model for C) did have seamless use of the C API/ABI.
The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. It was then easy to share data as the CSP model (with channels) worked between both coroutines, threads, and coroutines within a thread.
So if one wishes to use stackful coroutines, and still have that seamless compatibility, an approach mixing the Go and Alef approaches would seem necessary. i.e. the Go migrating coroutines as a default, but with the option to use Alef like thread bound coroutines when necessary.
This reintroduces the colored functions that we were trying to get away from in the first place, by adopting stackful coroutines/fibers. Why not use async at that point? I can understand that Alef didn't, because stackless mechanisms were not well understood at the time. But it's plausible that we can do better.
In micro-service world there are many service which read request over the network (HTTP or some RPC), send multiple requests, may be read something from disk, write logs all mixed with some business logic. A significant fraction of time is spend on waiting so a single modern server can handle a large number of parallel connections to the service without saturating hardware resources.
Async allows to do the same (handle many network connections in a single thread) but: 1. It's less ergonomic (less easy to write code) IMHO 2. In pure async if you do a long CPU intensive task in between I/O all other connections in the same thread will wait, which Go solves (at least partially) by using M:N model (pure async is M:1 - connection tied to a particular thread and even if you have many threads you cannot move connections around).
I would not argue that Go concurrency model is the best we can get but it's a good fit for micro-service architecture and a good balance between performance and easy development.
> Linux doesn't even allow you that many file handles.
Not by default but it's easy to rise limits for this and if you are running a loaded server you should not rely on defaults anyway. To get to 100M descriptors you likely need to tune only ulimit (LimitNOFILE in systemd) because default value for fs.file-max is likely large (AFAIR default scaled to the RAM size).
Which is ironic, maybe kinda funny. The first "larger" project I've tackled in Go was a chat server. I wanted a simple supervisor for each connected client; in case a goroutine encountered a recoverable error but needed to be restarted. I don't have any practical experience with OTP, but I've always been a big fan of daemontools/runit/etc: just let it crash, restart, and recover.
So in Go, you can't (easily) obtain a handle to a goroutine. The authors' entire argument seemed to be that this would allow developers to implement "bad" patterns, like thread-local storage. You can of course still come up with some wrapper code, like this:
type Service struct {
err <-chan error
run func(*Service)
}
s := &Service{err: make(chan error)}
realRun := func() error { ... }
s.run = func(s *Service) {
s.err <- realRun()
}
go s.run(s)
err := <-s.err
run := func() error { ... }
g := go run()
err := <-g
Correct me if I'm missing anything obvious.
While I like the language, threads in Go are not any easier than any other language (which is to say, most devs can't use them correctly, and your program will have bugs), and suffer from a ton of ergonomic issues, like being hard to keep track of, difficult(ish) cancellation(how do you cancel a big synchronous I/O operation), and channels suffer from backpressure related hard-to-debug issues.
They are though. Even Java people agree, Java recently got their implementation of goroutines (green threads). It's a superior model to async for application level programming.
Immutability is the actual core and power of Earlang
- Java (popular among people who went to college and learned all about OOP or places that had a lot of "enterprise" software development)
- Ruby on Rails (which was the hot new thing)
- Python or Perl to be the P in your LAMP stack
- C++ for "performance"
All of these were kitchen sink choices because they wound up needing to do everything. If you went back in time and said you were building a language that didn't do something incredibly common and got in the way of your work, no one would pick it up.
Rails was "hot" 20 years ago? lol, and you have completely missed IIS, .Net, and (dun dun duuuuuuuuunnnnn!!!!!) PHP. I bet you don't even know what ASP was.
Also...wth with C++ or python on a web server...20 years ago? Ok maybe this is entertaining now. Since you know so much, tell me about the framework libs needed for C++ web apps 20 years ago. eats popcorn <- that...is from BBS, maybe look that up too.
Are you an LLM bot or real person?
You're not just kind of wrong here; you're not just a little wrong; you're "having a bad day" level of wrong.
Take the afternoon off, and drink a Jamba Juice. Maybe call some family and tell them you love them.
>More amorphous, but not less important is Rust's strong cultural affinity for correctness. For example, go to YouTube and click on some Rust conference channel. You'll see that a large fraction of the talks are on correctness, in some way or another. That's not something I see in Julia or Python conference talks.
And it creates an interesting chicken and egg approach. The borrow checker may indeed be too strict (and of course, has its edge cases and outright bugs), but its existence (rather than the utility it brings) may have in fact attracted and amassed an audience who cares about correctness above all else. Even if we abolished the borrow checker tomorrow, this audience may still maintain a certain style based on such principles, party because the other utilities of Rust were built around it.
It's very intriguing. But like anything else trying to attract people, you need something new and flashy to get people in the door. Even for people who traditionally try to reject obvious sales pitches.
That's exactly what people say about Rust: just get good, use some tools, and be careful - and you can achieve the same memory safety.
I am curious what the second language with a borrow checker will look like.
Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also attract the sort of people that made its culture what it is.
Otherwise, IMO Rust would have ended up just like D, a language that few people have ever used, but most people who have heard of it will say "apparently it's a better safer C++, but I'm not going to switch because I can technically do all that stuff in C++"