Is Go Google's Programming Language, Not Ours? (utoronto.ca) 172
Chris Siebenmann is a Unix sys-admin for the CS department at the University of Toronto. He recently saw a tweet asking about the possibility of community-implemented generics for the Go programming language, and posted a widely-read response on his blog.
"There are many answers for why this won't happen, but one that does not usually get said out loud is that Go is Google's language, not the community's." Yes, there's a community that contributes things to Go, some of them important and valued things; you only have to look at the diversity of people in CONTRIBUTORS or see the variety of people appearing in the commits. But Google is the gatekeeper for these community contributions; it alone decides what is and isn't accepted into Go. To the extent that there even is a community process for deciding what is accepted, there is an 800-pound gorilla in the room. Nothing is going to go into Go that Google objects to, and if Google decides that something needs to be in Go, it will happen.
(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)
Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team. (As a corollary, sinking a lot of time and effort into a community effort that doesn't have enthusiastic buy-in from the Go core team is probably a waste of time....) On the good and bad scale, there is a common feeling that Go has done well by having a small core team with good taste and a consistent vision for the language, a team that is not swayed by outside voices and is slow moving and biased to not making changes.
The essay also concedes that "I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly.
"But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes."
UPDATE (1/29/2024) In a 2023 talk, Rob Pike -- one of Go's original creators -- addressed the question head-on. "People often assume Google tells the Go team what to do. That's simply not true.
"Google is incredibly generous in its support for Go, but does not set the agenda. The community has far more input. Google has a huge internal Go code base that the team uses to test and verify releases, but this is done by importing from the public repo into Google, not the other way around. In short, the core Go team is paid by Google but they are independent."
"There are many answers for why this won't happen, but one that does not usually get said out loud is that Go is Google's language, not the community's." Yes, there's a community that contributes things to Go, some of them important and valued things; you only have to look at the diversity of people in CONTRIBUTORS or see the variety of people appearing in the commits. But Google is the gatekeeper for these community contributions; it alone decides what is and isn't accepted into Go. To the extent that there even is a community process for deciding what is accepted, there is an 800-pound gorilla in the room. Nothing is going to go into Go that Google objects to, and if Google decides that something needs to be in Go, it will happen.
(The most clear and obvious illustration of this is what happened with Go modules, where one member of Google's Go core team discarded the entire system the outside Go community had been working on in favour of a relatively radically different model. See eg for one version of this history.)
Or in short, Go has community contributions but it is not a community project. It is Google's project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team. (As a corollary, sinking a lot of time and effort into a community effort that doesn't have enthusiastic buy-in from the Go core team is probably a waste of time....) On the good and bad scale, there is a common feeling that Go has done well by having a small core team with good taste and a consistent vision for the language, a team that is not swayed by outside voices and is slow moving and biased to not making changes.
The essay also concedes that "I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly.
"But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes."
UPDATE (1/29/2024) In a 2023 talk, Rob Pike -- one of Go's original creators -- addressed the question head-on. "People often assume Google tells the Go team what to do. That's simply not true.
"Google is incredibly generous in its support for Go, but does not set the agenda. The community has far more input. Google has a huge internal Go code base that the team uses to test and verify releases, but this is done by importing from the public repo into Google, not the other way around. In short, the core Go team is paid by Google but they are independent."
EditorDavid, you gotta ask us? (Score:1)
"go" is google's thing, just like "swift" is apple's and of course facebook just had to have its own also. And mozilla, with its groupies. And sunacle. And the entire language zoo shitshow from redmond. This isn't hard to figure out.
It's the thing to do for a tech giant. Own that "ecosystem". And if you're a fanboi, then yes, you have an owner too.
Re: (Score:2)
We probably learned our lesson with Java.
Re: (Score:2)
learned what? Java has been out for 20+ years and still doing important business work. It's a job requirement, not something "the community" chooses to use or not.
Re: (Score:2)
It wasn't always. 20-some years ago it was one of those newfangled fad languages - not very powerful, atrociously slow, and owned by a particular company. Nobody took it seriously, but it was being marketed hard as the magic bullet for cross-platform and web development.
Re: (Score:1)
The community has rammed everything into the Java specification, which is over 700 pages today. This was not the case back in 1995 when it was introduced to the world. You see feature creep in other languages too.
Re: (Score:2, Interesting)
You mean the 4 distinctly different and incompatible
Java versions released over the last 20 years?
I'll stick w/C. If I need a "higher-level" language, I'll
write the mutherfarkin language myself in C.
CAP === 'bashes'
Re: (Score:2)
No. Java is horrible at unicode...better than C, but that's faint praise indeed. Java doesn't have structs that support byte layouts. (Well, C++ doesn't really, but implementations seem to always support it.) Java doesn't have unsigned numbers. Java doesn't have decent enums. (That class thing is horrible.) Etc.
What is does have is, it's faster than Python, it has more libraries than D, it has better garbage collection than C. I'm sure there must be some other good feature...but it sure isn't file h
Re: (Score:2)
Boehm https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
How about Objective C's documentation was (and is) horrible. Whenever I tried to figure out how to do something with it, I'm directed to a page about using an Apple library...which I didn't have.
Re: (Score:2)
There's a tradeoff: more power generally goes with being easier to shoot yourself in the foot (and blowing off more of your leg along with it). As for C++, I get the impression that no-one outside the standardisation committee can keep up.
Re: (Score:2)
no-one outside the standardisation committee can keep up.
You think the standardisation committee is keeping up. That's cute.
Re: (Score:2)
Re: (Score:2)
You win the internet today.
Okay, but so what? (Score:3)
Couldn’t you say similar things about the Linux kernel, for example? Or Apache’s web server?
Re: (Score:2)
Re: (Score:3)
Sure, but Google is the one profiting off of the community's free labor.
And the community is profiting off of Google's labor as well, since they get to use Google's work free of charge.
Anyone who wants to is free to fork the language (all of the code is under a BSD-style license). The fact that they don't indicates that they find more value in staying with Google's version of the language -- and therefore receiving the benefit of the labors of Google's employees -- than in striking out on their own.
Re: (Score:2)
Re: (Score:2)
They stay with Googles version because Google will quickly make any fork an unsupported dead fork.
Unsupported by whom? By Google? Obviously Google isn't going to support a fork. Why in the world would you expect them to -- and if you decide to fork because you don't like Google's decisions about the language, why in the world would you want them to support your fork? Wouldn't you be worried that they'd screw it up in all the ways that caused you to decide to fork it to begin with?
It sounds to me like you're saying that people stay with Google's version because they appreciate the fact that Google c
Re: (Score:2)
Yes and no (Score:1)
"Is Python Guido's programming language, not ours?" (until very recently, at least)
"Is Linux Linus' kernel, not ours?"
There are multiple freely licensed Go implementations and a language spec document you can copy and modify to make your own Go variant. In the case of modules it's not even really a breaking language change, it's a tooling behavior issue.
This guy's complaint boils down to: someone who doesn't answer to me made a decision I don't like. Welcome to reality, friend. We would all prefer some thin
Re:Yes and no (Score:5, Interesting)
Perl 5 was Larry Wall's rewrite of Perl 4.
Perl 6 is the community's rewrite of Perl 5.
And it completely destroyed the community, and "nobody" uses Perl anymore.
I say like Pike and Thompson keep it.
It is already created, we know what it does, the interesting thing after that is choosing libraries. And nobody controls that.
Re: (Score:2)
I use Perl 5. I will not touch the Perl 6 mess with a very long pole.
Re: (Score:2)
And it completely destroyed the community, and "nobody" uses Perl anymore.
No they don't. But that's not because of Perl's internal politics. It's mostly because most folks find it very difficult to read Perl code -- any version. Even code they wrote. Python has much the same capability and is far easier for most of us to read, so Python has largely replaced Perl. see ftp://ftp.ntua.gr/mirror/pytho... [ftp.ntua.gr]
Re: (Score:2)
No. I spent years as a Perl programmer wondering if Perl 5 or Perl 6 was the future! Now we're in the future, and it was Perl 5 all along.
For me personally, if I had known the answer to that, I would probably still be using Perl. It was the uncertainty that dragged on for years, starting from "new version coming" and moving towards "not sure if anybody will switch" that caused the desire to look around at other options. And once I was looking around, the difficulty of reading old code really did start to st
Re: (Score:2)
And it completely destroyed the community, and "nobody" uses Perl anymore.
That guy shows up a lot in my syslog files.
[And I still use Perl for many things.]
Re: (Score:2)
Sad that that practice is still around, since adding a user for each daemon is so cheap.
There's nothing wrong with Perl. It didn't disappear.
But the "Perl community" largely did. That's why I quoted "nobody;" because I know that there is a mouse that is stirring, and yet, it is still a very quiet night on Perl Street.
Re: (Score:2)
I was still using Perl 5 and waiting on Perl 6 to be usable when I switched to Ruby in 2004.
It wasn't just the press, it was the people making the schedule who were also fooled. I'm glad I jumped ship when I did!
What about Dart? (Score:1)
...
Re: (Score:2)
And Python Is (Was) Guido's (Score:4, Insightful)
And python was Guido van Rossum's programming language (he effectively had final say over all decisions) and many other programming languages have a single leader or small inner circle who effectively dictate what changes are accepted.
I suspect this is a desirable and necessary part of building a good programming language. Many ideas that are good in their own right may need to be abandoned to achieve greater overall consistency or simplicity. It's necessary to have a small group in charge who can ensure a consistent vision.
The fact that Google is a for-profit company rather than a lone developer is actually a good thing not a bad one. It ensures that Go is responsive to many real world concerns (and scalability concerns that developers without massive data centers might not run into) and provides a certain assurance of continuity. There is no profit motive for google to make the language worse or limit it. If they do abandon it...well fork it.
Re:And Python Is (Was) Guido's (Score:5, Interesting)
I would go a bit further and say it's an unfortunate requirement for any good project to have "centralized" design/approval structure.
I have seen some "decentralized" projects in open source land. They have thus far always sucked, lacking any semblance of consistent vision and direction.
Sometimes there have been very successful forks, where someone couldn't get their vision through current leadership and forked and ultimately "won" the disagreement by becoming the new gatekeepers, but always there is some core leading small team.
provides a certain assurance of continuity.
Eh, I wouldn't assume that. Companies tend to assert branding, but the technical will behind it usually isn't all that much stronger in a company. People think google and imagine the thousands of employees standing behind it. In practice about a dozen people are the bulk of the project (which is actually on par with the most popular open source projects). Particularly Google is notorious for changing their minds in very public ways that impact people who have adopted their technologies. The almighty fork remains the option for an abandoned or bad direction for such a project.
Re: (Score:2)
I know very well that it's a dozen people on each project. I used to work there. The difference is that for any project that is used widely internally if those dozen people leave or quit Google will make sure that someone else with the expertise and background needed to run the language will be hired/assigned to keep it going.
It's basically like the small inner circle making the calls for any programming language but backed by a big pot of money to hire replacements if they decide to do something else.
Re: (Score:2)
Re: (Score:2)
Is this supposed to be something that should be stopped? Doesn't sound like it. I'm confused about the relevance.
uhmm.... thats a wonderful thing (Score:5, Insightful)
I read the link and basically this dude is sour grapes for working on something then the people who built it from scratch refuse his contribution.
I know because -- I was that guy --. I have spent a lot of time writing stuff that gets rejected from open source projects.
What I have learned is that basically, the Buddhists are way ahead of us on this. Monks travel around the world making sand paintings. They are huge, they are beautiful, they are intricate, they take many many days to create, its hundreds of hours of work. Then, they sweep the sand into a bucket and leave.
The point is not to be attached to the things we create. It is the act of creation that is important, and the appreciation, the focus, the experience. The final product is out of our control most of the time anyways.
When I became on the "other side", having to tell people their pull requests were rejected, it became full circle. A lot of contributions are not good. A lot of contributors lack respect for what came before them. It might take 1 hour to implement a feature... it might take 100 hours to make sure that feature works on all platforms, doesnt have weird bugs, integrates with test cases, doesnt confuse people in the UI, wont restrict further developments, doesnt complicate the underlying structure too much, etc.
Why is open source great ? Because it is a market place of ideas (without much of a money exchange yet but...) and you can always start your own thing if you dont like how things are going.
But if you are angry because someone didnt take your contribution, that is a lesson in life, not in code. Life is about rejection. Rejection from jobs, rejection from relationships, rejection from business partners. It is not the rejection that is important, it is how you feel about it, and how you handle those feelings. In fact, how you handle your feelings is pretty much the only thing you actually have control over.
Re:uhmm.... thats a wonderful thing (Score:4, Insightful)
A lot of people fail to realise the costs involved. Creating a patch is one of the least costly parts. It might take someone a few minutes to a few hours to create a tested, working patch. But integrating it might take many hours, or even weeks. Checking it matches the existing design specification, updating specifications if needed, checking it has correct test coverage, and that the tests work on every supported platform, and that there are no behaviour or compatibility breaks for downstream users, all takes significant amount of time and resources. Far in excess of the initial patch creation.
Of course it is, so... (Score:2, Insightful)
Of course it's Google's language.
So why have anything to do with it?
I never understood why people are so keen to throw free labor to one of the richest corporations on the planet.
You wanna contribute something to something? Go find a small OSS project of volunteers that needs help with something. They're all over.
But FFS, don't donate your time and energy to Google, Microsoft, or bloody Oracle.
This is nothing new or unusual (Score:2)
Check out the informative table here [wikipedia.org].
Re: (Score:2)
>"Check out the informative table here [wikipedia.org]. [Benevolent_dictator_for_life]"
Yet Google is neither an individual nor to many people, "benevolent." Dictator- that fits, though.
Just wait... (Score:2)
I mean, yes it's Google's. So just wait a couple years until they abandon it and then you can do whatever you like.
Re: (Score:2)
That doesn't change anything, you can already do all that stuff.
This is about "they didn't accept my pull request, and they don't even care about the letters next to my name!"
It's Google's Programming Language... (Score:2)
...We just live in it.
Community development... (Score:2)
... doesn't necessarily lead to better tools or software.
Linux is case in point, while it is well enginered for proffesionals, it is badly enginered for end users. Programmers have this weird fetish where they want to adapt/modify/write standards for tools they are using and that's all well and good the problem is the human mind is just not capable of dealing with all that complexity well. We saw this with C++ standards over the years where a tool keeps growing in complexity to meet different needs of dif
Re: (Score:2)
... doesn't necessarily lead to better tools or software.
I agree on that. The current crop of SJWs does think the complete opposite though. One of the easiest ways to demonstrate that they are stupid.
Language (Score:2)
Having your own in-house programming language is something all the major tech companies are trying to do. It allows a level of vendor lock-in, making talent hard to transition elsewhere.
Microsoft: .net (Visual Basic and C#), TypeScript
Facebook: Hack / HHVM, React
Apple: Swift
Google: Go (the language name is even basically the company name!)
Amazon: Actually, I'm not sure they have any yet?
Re: (Score:2)
With flex and bison, anyone can make their own in-house programming language. It used to be (still is?) a requirement for CS masters programs that students create their own programming language.
Re: (Score:2)
Oh yes. There is basically zero need for any of these languages besides training chap bad coders (that usually only can code in one language) in it and then having them unable to get a job anywhere else.
Also:
Mozilla: Rust
Re: (Score:2)
Oh yes. There is basically zero need for any of these languages besides training chap bad coders (that usually only can code in one language) in it and then having them unable to get a job anywhere else.
If "I can't learn a language" keeps you from getting a job somewhere else, then you should be prevented from getting a job in the industry at all. None of these languages are very hard (ok, Rust is a little hard but not a lot hard).
Re: (Score:2)
Sure, it should. The sad state of affairs is that most "coders" these days fall into that class though.
Re: (Score:2)
The sad state of affairs is that most "coders" these days fall into that class though.
Not really. They're afraid to try, but if they tried, they would actually be able to. Cowards should not be programmers, they're afraid to try.
Re: (Score:2)
No, they would not. They can only think in the one language they learned, they have no general concepts.
Re: Language (Score:2)
Things belonging to Google die after a while (Score:2)
It is an endless pattern. They care about search and ads, everything else may get killed without much warning. Relying on any Google-owned tech is a really bad idea.
NoSQL movement... (Score:3, Interesting)
Golang is akin to the NoSQL movement.
Features most appreciated by Go's proponents are easy to learn and great compilation speed. Does that sound familiar: with NoSQL databases you didn't have to learn the clumsy SQL query language and they were fast due to lack of ACID guarantees.
But for years the top voted tickets on NoSQL databases were usually 1) SQL and 2) ACID compliance or 3) at least some sort of consistency guarantees (Json-schema or something).
Because initially, people weren't aware of that baby that they threw out with the bath-water, was called 'relational algebra' - a useful concept that some guy invented in late 1960ies, in times before these new kids were even born.
So have a look at Golang ticket tracker with top voted issues being:
1) generics
2) error handling
3) discriminated union types (ideally with pattern matching)
I personally don't think Go should add these features, because with those features added, it won't be fast to compile, nor will it be simple anymore. If you need these features, there are actually great programming languages already in existence. There is a space for a NoSQL programming language called Go. There will always be people who wish to screw things up out of their ignorance and they should have a language to Go to. There will always be moronic managers who think that having a simple language like Go is a the most important feature of the company, because you can always find stupid inexperienced programmers, who can at least learn Go. There will always be people who think that fast compile times lead to faster turnaround, more unit tests and faster bug squashing (as if such bugs are unavoidable). In short, there is a space for Go.
However, each time a proponent of Golang speaking of it as a 'means to everything programming language', it reminds me of people praising NoSQL databases, while having totally zero awareness of the theory of relational algebra or benefits of ACID compliance.
So if you like Golang, but would like to be objective, then first learn some 1960ies theory, like Curry-Howard isomorphism, Hindley-Milner type systems and similar things, then learn a language that uses them (the OCAML, F#, ReasonML group is a great starting point and show what languages can do for you), and then come back to praise Golang if you will.
Re: (Score:2, Interesting)
And yet, there are languages with those features that compile fast, or even hot-code replace stuff.
I can't imagine using a language without generics anymore, the expressiveness of the language increases by a whole order of magnitude.
And I didn't buy into NoSQL either. I did however find that storing JSON structures into a database, structures that don't benefit from further relationships or indexing, is a neat way to save spelling out every table and field (and easier to change). Fields that do benefit fr
This could only be a bad thing! (Score:1)
My impression of Go (Score:2)
My impression of Go: it is a language with a number of good points but some glaring gouge your eyes out bad flaws, because of catering far too much to the whims of an opinionated, authoritarian dictator for life, backed up by Google's smarter-than-you dystopia. Sad. It could have been good.
Re:Everything Google does... (Score:4, Insightful)
Re:Everything Google does... (Score:5, Insightful)
Re: Everything Google does... (Score:1)
Go is a fine language designed by very smart people. It's not perfect, but I quite like it, as a language.
Unfortunately, Big Brother Google anti-democratically imposed a very unpopular nazi "Code of Conduct" on anyone wishing to contribute to the language project itself.
Fuck you, deplorables, that's why!
Re: (Score:2)
Go is a fine language designed by very smart people. It's not perfect, but I quite like it, as a language.
To be fair, you have to be fairly smart to design a language, even a bad one.
Oh hey... :) (Score:2)
Gee, thanks. :)
Why use Go if you want generics? (Score:1)
What I don't get about this whole situation is why this guy would even bother with Go if he wants generics so badly.
There are numerous other languages out there that have generics or templates or something similar. These languages are just as capable and portable, if not more so, than Go.
I wouldn't use Perl if I wanted maintainable code, and I wouldn't beg for Perl to be changed because of my desire.
I also wouldn't use Go if I wanted generics.
Re: (Score:2, Informative)
> Go is licensed under BSD which is more permissive than GPL.
Stop spreading FUD about GPL. You can fork /any/ GPL code, that's what GPL was made for. GPL is more permissive for its end users, BSD is more permissive for its (re)distributors.
Re: (Score:2)
Providing that the stewards of Go are responsive to reasonable community involvement and don't reject contributions for irrational or selfish reasons, they should be fine.
Re: (Score:2)
Re: (Score:2)
Re:Millenial languages (Score:5, Informative)
Yeah, but new languages should at least learn from their predecessors. Golang doesn't[1] support dynamic libraries, which makes it mostly no-go for real-world distributions. Static linking is usable for a small controlled ecosystem like Google's servers where they can rebuild world daily then push to all machines, but for distro usage, any bug in a library would require a cascade of rebuilds. For this reason, Debian declared anything in Golang to be not covered by security support.
[1]. The was a partial implementation, but it's broken.
Re: (Score:1)
Re:Millenial languages (Score:4, Insightful)
I just want to say how under-appreciated this viewpoint is in this day and age.
There are two disastrous fads in play right now:
-Statically linking or effectively statically linking by shipping your application as a container first and frequently un-runnable outside of the specific container from the developer (incidentally, part of this is because developers frequently want to add a dependency and then *never think about having to update to support a newer version*.
-"Just install arbitrarily new version of some random developers code from a repository with no semblance of curation"
core libraries (Score:3)
that, and no core libraries, with then either everybody re implementing their own bit, or pulling core functions from the random repos mentioned in your point 2.
And mayhem happens and half of the Node.js ecosystem is down because somebody took their a repo with a function to align strings.
Re: (Score:2)
IIUC, in a large enough system there is an automatic compactor running where different chunks of the same code will be mapped to the same address in real memory. Of course, this doesn't work very well if you're going to be changing pieces of it, but that doesn't describe code libraries, whether in a container or not.
Re: (Score:1)
Right, it is an infrastructure language. With static libraries, you don't really care about bugs in features you didn't use. And not every bug is hugely important. Protecting from unexpected changes is a bigger deal.
Re: Millenial languages (Score:2, Informative)
The problem is that libraries have bugs and without shared libraries authors will embed some hoary old version and never update.
Aside from the fact that not using newer versions means newer hardware, newer APIs, newer file formats etc donâ(TM)t get supported.
Static linking breaks one of the great advantages of open source which is that people can work in a decentralized uncoordinated way and keep a system up to date.
Re: (Score:2)
And projects that make updates that break working code for trivial reasons break that same advantage.
You can't really say that one approach is better than the other. It depends. There's a good reason why some updating systems allow you to specify the exact version(s) of a library you can work with.
Re: (Score:2)
I heard that somewhere there is still a steam train being used today.
Re: (Score:2)
Re: (Score:2)
Re:Millenial languages (Score:5, Interesting)
He said why, because there is existing cobol code and the cost and risk to start from scratch means no one is going to do that and instead just maintain their COBOL..
If COBOL was a good choice to start a new project without legacy requirements, then you would see more programmers and more projects.
I think a better example would have been Fortran, which was still a popular choice for new scientific applications up until a few years ago due to its design mapping more closely to the way those disciplines use math (though recently python has usurped its place and Julia is a strong contender to supersede Python in that field).
Of course, Go is not a particularly domain specific sort of language, so this argument in general doesn't apply to it. Design wise it is a language that liked some features of newer languages, but really liked C better and basically made a "C" with safer pointer management, less tedium, and yet another "classes but not classes" syntax to bring OO thinking back to a struct centric world. It might make for a decent C replacement, though I'm not crazy about how go developers say "just go get to run whatever the hell is currently in my git repo", this isn't a hard requirement of how go fundamentally works.
I personally favor languages with less tedious error handling requirements, but Go's model is pretty much exactly like C's model, albeit with a more up-front syntax so the programmer is unlikely to "forget" about a secret channel for errors to be flagged.
Concurrency (Score:2)
Go also provides considerable inroads on issues of concurrency, which is something that isn't common in other languages.
Not a huge fan of Go - c/c++ is my goto for performance, and Python for tasks where performance isn't much of an issue.
But still, credit where credit is due.
Re: (Score:2)
I'm not really sure about that one. Go does talk a lot about concurrency, but the first implementations had concurrent execution disabled by default, so it was just a fancy form of coroutine. I've never been able to find any decent documentation as to the costs of using channels. They talk a lot about how goroutines are cheap, but they never mention the costs of channels for interroutine communication.
My current feeling is Python for fast development, and C/C++ for fast execution. And that means segment
Re: (Score:2)
As with any language, the only way to be sure is to benchmark your particular needs.
Canned benchies are next to useless to really see how a particular approach will work, I have found.
Re: (Score:2)
Actually, for a long time Fortran's big benefit was the way it handled multi-dimensional arrays. Having everything predeclared of fixed size allowed efficient access to any cell in the array. This allowed much faster results in many cases. Early fortrans didn't even implement the idea of pointers as a language construct, but required you to either drop into assembler or use a library. So C was much better at dynamic allocation and string handling.
Re: (Score:2)
I heard this in the past and cast a net around to check, and there is nearly no demand for new COBOL code.
If they really need a bugfix, and senior developer can spend a day writing some COBOL. They don't have enough changes needed to bother replacing the old people. Instead the new people will have different core skills, different titles. But COBOL is still easy to write.
Re: (Score:3)
Cobol is mostly used in banking, and how you do banking has not changed a lot since the 17th century, other than the numbers have more decimal places, and its done in Cobol instead of Latin.
Disclaimer: I wrote a pay roll system in Intel's PLM once. Cobol is definitely better than PLM.
Re: (Score:2)
If they really need a bugfix, and senior developer can spend a day writing some COBOL
The point I was making is that all developers of COBOL are "senior". There are very few new developers. And the senior developers are retiring.
They don't have enough changes needed to bother replacing the old people. Instead the new people will have different core skills, different titles. But COBOL is still easy to write.
The problem is that there are no immediate changes required. But just like Y2K, a problem came up that required COBOL programmers to come out of retirement. The next problem I can forsee is Y2038 problem. COBOL may be easy to write but can you untangle a massive amount of code in a current system and figure out everything that is being done.
Re: (Score:2)
Re: (Score:2)
Only an idiot would make that claim
You mean like the OP: "Instead of FAD LANGUAGES just use C/C++ and asm, for fuck's sake!"
It is equally foolish to mention COBOL in a discussion about other languages that serve as better solutions, or even as a language to consider, for any modern project.
Why not? The OP mentioned C/C++ and ASM as the languages that should be used. These are not modern languages. These are very old languages. My point is that by that logic there are even older languages like COBOL that he should instead.
And stop with the attempts at sounding like you are saying anything everyone doesn't already know. Your use of the hammer cliche isn't insightful.
So repeating what you know offends you in some way?
Re: (Score:2)
Re: (Score:2)
The problem with Lisp and Scheme is that you'll NEED to implement features like this...over and over. When I tested them out most of the libraries in the "repositories" didn't work on my system. (I'm being charitable, and assuming that they worked on other systems.) Also the syntax is verbose, and the systems for documenting the code that you write were quite poor. Possibly as bad as Sphinx. (FWIW, the best documentation systems I've encountered were Javadoc, Doxygen, and Epydoc [which doesn't work on
Re: (Score:2)
Correction (Score:2)
Not "the purpose." A purpose.
Re: (Score:2)
I think you are confusing syntax and semantics a little. Yes, you are writing something which is close to a AST, and there is little abstraction over that as a syntax. That has some disadvantages (lots of irritating single parenthesis) and some advantages (the syntax is very small, it's very regular, and it's very easy for an IDE to understand rapidly without parsing to a format that is unrelated, so you can use structural editing like paredit; oh and macros which are as easy to build as the language is to
Re: (Score:1)
Car car = new Car();
You forgot the Cdr cdr = new Cdr();
Re: (Score:1)
Re: The Wikipedia problem. (Score:1)
Decentralizing had it's own problems. You can wind up with an incoherent mess as features are added just because people thought they were cool and those features create bloat and security headaches.
The best way is usually to have a central committee that keeps things same, but that takes feedback from the users.
Re: (Score:2)
Decentralizing *does* have it's own problems, but every management team of any description tends to decide what the project will do and how it will change. A decentralized project is forkable, and the fork is still maintainable by skilled people. (Recent example Devuan forking from Debian.) This is because each piece of the project is controlled by different groups, so the interconnects need to be spelled out, and the fork needs to only be for a smaller, maintainable, part of the code. When OpenOffice f
Re: (Score:3)
ISTM that the reason that keeps happening is that Interfaces don't list the "well known instances" that implement them and implementations don't list the "well known Interfaces" that they implement in the documentation. This results in a great deal of confusion until you've memorized a huge quantity of inter-relationships.
Admittedly I've never been a heavy user of go, but every time I go back to it I need to search google to figure out how to read data from a file. In practically any other language that c
Re: (Score:2)
Well, no. But it C++ had remained a language that compiled to C which you then compiled it would probably have been better.
Managing hash tables and variable size arrays, etc. in C is a real pain. But that shouldn't mean that you couldn't EASILY combine the parts that didn't need or want the fancy stuff.
That said, I think C should have included references and const values. (Does the most recent one?) And *BOTH* C and C++ need a decent way of handling utf-8 or utf-32.