Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Go, Google's New Open Source Programming Language

kdawson posted more than 4 years ago | from the blatently-bracist dept.

Software 831

Many readers are sending in the news about Go, the new programming language Google has released as open source under a BSD license. The official Go site characterizes the language as simple, fast, safe, concurrent, and fun. A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop. Ars Technica's writeup lays the stress on how C-like Go is in its roots, though it has plenty of modern ideas mixed in: "For example, there is a shorthand syntax for variable assignment that supports simple type inference. It also has anonymous function syntax that lets you use real closures. There are some Python-like features too, including array slices and a map type with constructor syntax that looks like Python's dictionary concept. ... One of the distinguishing characteristics of Go is its unusual type system. It eschews some typical object-oriented programming concepts such as inheritance. You can define struct types and then create methods for operating on them. You can also define interfaces, much like you can in Java. In Go, however, you don't manually specify which interface a class implements. ... Parallelism is emphasized in Go's design. The language introduces the concept of 'goroutines' which are executed concurrently. ... The language provides a 'channel' mechanism that can be used to safely pass data in and out of goroutines."

cancel ×

831 comments

Sorry! There are no comments related to the filter you selected.

Build-in function library (4, Insightful)

sopssa (1498795) | more than 4 years ago | (#30056494)

One of the things I immediatly noticed is the lack of build-in libraries. The reason I've always preferred Delphi and C# over C/C++ and PHP over Perl is that they all come with a comprehensive build-in function library for wide area of things.

Programming now a days tend to be mostly high-level, so you would expect that new languages would provide that. I personally hate to find tons of different libraries for C++ projects just to do a basic thing. And lets be honest, theres no sense of everyone of us to code the basic functions again (and probably in worse code than the regularly checked build-in functions)

That is why I love PHP, and because it provides a great manual on its functions. That is also why I love Delphi and why I started using it as 10 year old, without internet too - the reference guide that came with it was comprehensive and the build-in libraries and components for different things allowed me to rapidly try out to code apps and games. Only time I needed to find some libraries/components was when I was looking for a more rapid and better graphics library to do the drawing in my games.

That is what would be "fun" in a programming language. It comes a lot before "fast builds, clean syntax, garbage collection, methods for any type, and run-time reflection."

Re:Build-in function library (1)

cptnapalm (120276) | more than 4 years ago | (#30056562)

According to the go page, it is supposed to be a system language. So the niche it is aiming at is, perhaps, lower level.

Re:Build-in function library (5, Insightful)

Anonymous Coward | more than 4 years ago | (#30057024)

I think the niche it's aiming at is the, "Look! We made a programming language, too!" niche.

Re:Build-in function library (4, Insightful)

Blakey Rat (99501) | more than 4 years ago | (#30056570)

Perhaps it's designed to be embedded, like LUA or Javascript? In that case, comprehensive libraries aren't necessary or even desirable.

Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.

Re:Build-in function library (3, Insightful)

DerekLyons (302214) | more than 4 years ago | (#30057082)

Or, more likely, they just did the fun part of designing the language, and are leaving the hard part of creating libraries to somebody else.

They pretty much explicitly state that in TFA - the 'simple' and 'fun' stuff is done, now it's up to the [currently theoretical] community to dig in and do the hard stuff.
 
Of course, being Google branded and Open Source (two of the top 'auto orgasm' buttons among a huge swath of geeks) there will be, at least in the beginning, a fairly large community. I'll be very surprised if there isn't a Wiki by morning, and I'll be there's half a dozen or more Waves about it by now.

Re:Build-in function library (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30056574)

You're a bitch and i'm gonna rape you like one. Bend over fag.

Re:Build-in function library (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30056874)

Ok Ballmer, last time you said you were gonna kill Google, now you gonna rape 'em.

Make up you mind, dumbass.

Re:Build-in function library (3, Interesting)

Toonol (1057698) | more than 4 years ago | (#30056594)

If they could at least include a subset of OpenGL... or just an SDL wrapper, maybe with some high-level features for simple 2d-3d manipulation... this looks like it would be a great learning language. I see they have a DRAW library with a very limited number of features.

They also have a "spacewar" directory, currently empty...

Whenever Google announces something, you have to make the decision... jump on it immediately and get ahead of the curve, but risk wasting all that time if it doesn't take off? Or wait?

Re:Build-in function library (3, Interesting)

michaelmuffin (1149499) | more than 4 years ago | (#30057030)

They also have a "spacewar" directory, currently empty...

the documentation directory is empty, but the original pdp1 code is there as well as a pdp1 emulator to run it on: http://golang.org/src/pkg/exp/spacewar/ [golang.org]

Re:Build-in function library (3, Insightful)

Al Dimond (792444) | more than 4 years ago | (#30056630)

PHP? Where they dump all their million built-in functions into one namespace? Lame. In Perl you have a lot more control over what libraries you pull in and how you use them -- you have to search CPAN for packages sometimes, but then you have a choice on what packages to use. And every Perl module I've pulled from CPAN has been well documented.

I can see wanting lots of libraries around in a default install back before the Internet was big. These days that stuff should be separate and the language's core should be its core.

Re:Build-in function library (0)

Anonymous Coward | more than 4 years ago | (#30056946)

How do you automate the pull for end user with CPAN?

Re:Build-in function library (0)

Anonymous Coward | more than 4 years ago | (#30056672)

Just means someone has to code in said libraries. They don't grow in trees, you know.

Re:Build-in function library (1)

daniel_mcl (77919) | more than 4 years ago | (#30056888)

Not so. The point of standardized libraries isn't that they're better than third-party ones, but that there aren't competitors. That way all development goes into the same library which everyone is familiar with and there's no bizarre fragmentation to deal with.

Re:Build-in function library (3, Interesting)

AuMatar (183847) | more than 4 years ago | (#30056924)

I view this as a defect, not a feature. Without competition, bad ideas and poorly implemented libraries (see large parts of Java's IO library with its 1 billion inheritances and its slow migration from old windowing toolkits) get used because its standard, where with competition they would die and better ones would quickly be written. I prefer the C/Perl system- preferably with a site like CPAN or boost that aggregates the good ones.

Re:Build-in function library (4, Insightful)

palegray.net (1195047) | more than 4 years ago | (#30056714)

Perl developers know about this thing called CPAN [cpan.org] . PHP doesn't even come close in this regard, and you really can't get a better language reference than perldoc [perl.org] . Honestly, if you can't write an app using Perl's built-in functions and the thousands of modules from CPAN, you probably shouldn't be programming. While choice in languages can vary widely according to the individual coder's personal preferences and particular suitability for a given task, the weakness you've cited is imaginary.

Re:Build-in function library (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30056784)

Failed to read the parent. Parent's complaint is that you have to start loading a bunch of modules to do anything. The reason everything that I write is in bash, perl or visual basic is because I don't start with "uhh, okay, #include , #include ... etc.

Nope, I'm not a dickhead, I mean a programmer. I used to employ a few, but they were generally dickheads, so I outsourced them. The brilliant ones (not a single one with a CS or CE degree) I kept, but not as programmers.

Re:Build-in function library (4, Interesting)

palegray.net (1195047) | more than 4 years ago | (#30056920)

Didn't fail to read the parent. Perl has an immense amount of built-in functionality; I'd easily say it eclipses PHP in this regard (perusing the documentation site I linked bears that out). My points regarding CPAN is meant to point of the fact that it augments that built-in functionality in a very standardized manner, and even in cases where you might "use Foo;" a large number of those modules are distributed with Perl's core (in other words, they're installed by default).

I have to agree with a couple of your points, however. It's an unfortunate truth, but a heck of a lot of programmers do qualify as dicks. I've worked with my fair share of them over the years, and I have to say I've never met a truly gifted coder with a CS degree. I'm not saying they don't exist, but I'll be damned if I've found one yet. Oddly, out of the "real asshole" crowd, many of them had a CS degree in addition to sucking at their jobs. The best coders I've worked with never even went to college, didn't finish, or graduated with a degree completely unrelated to computer science or IT.

Re:Build-in function library (1)

DuncanE (35734) | more than 4 years ago | (#30056736)

It seems to have a number of packages already including a image package and http package? (http://golang.org/pkg/)

Im sure it wouldnt be to hard to write a package that wraps sqllite or something for DB access.

My question is, given that its so close to C what does it give me the C doesn't?

Re:Build-in function library (2, Informative)

sabernet (751826) | more than 4 years ago | (#30056816)

It's got garbage collection and limits as to what you can do with pointers for starters.

Re:Build-in function library (1)

adamkennedy (121032) | more than 4 years ago | (#30056832)

One of the things I immediatly noticed is the lack of build-in libraries. The reason I've always preferred Delphi and C# over C/C++ and PHP over Perl is that they all come with a comprehensive build-in function library for wide area of things.

The release of Strawberry Perl Professional in January [perl.org] should resolve your issues then, as we're going to be rolling a ton of stuff into a single install, so it will come with comprehensive built-in function library for a wide area of things.

Or at least, it will fix it on Windows...

Re:Build-in function library (1)

onefriedrice (1171917) | more than 4 years ago | (#30057124)

Or at least, it will fix it on Windows...

I'm not on Windows, but fortunately I've never considered perl's slim "built-in" library a deterrent. Actually, I'm glad it doesn't come with everything anyone might possibly need. If I need something, it's probably already on CPAN, and it will be installed in a couple of minutes.

Re:Build-in function library (0)

Anonymous Coward | more than 4 years ago | (#30057056)

By your logic, we shouldn't build trucks because you drive a car.

Now let's at the intent of GO, as listed in the FAQ:

Go is fully garbage-collected and provides fundamental support for concurrent execution and communication.
By its design, Go proposes an approach for the construction of system software on multicore machines.

Go is an experiment. We hope adventurous users will give it a try and see if they enjoy it. Not every programmer will, but we hope enough will find satisfaction in the approach it offers to justify further development.

The Go project was conceived to make it easier to write the kind of servers and other software Google uses internally, but the implementation isn't quite mature enough yet for large-scale production use. While we continue development we are also doing experiments with the language as a candidate server environment.

Go was designed with an eye on felicity of programming, speed of compilation, orthogonality of concepts, and the need to support features such as concurrency and garbage collection.

Gosh, it's not PHP, but the goal was not to build the next version of PHP. But you don't have to worry about that, since you clearly are never planning on learning anything new for the rest of your life.

Re:Build-in function library (3, Insightful)

MemoryDragon (544441) | more than 4 years ago | (#30057142)

Easy, make it compile java bytecode and you probably have the biggest library around on the planet. Why a language nowadays should provide its own libraries is beyond me. That is so 90s...

Sponsored by Inspector Gadget (5, Funny)

Yvan256 (722131) | more than 4 years ago | (#30056500)

Go Go Google Language!

Re:Sponsored by Inspector Gadget (1)

el_tedward (1612093) | more than 4 years ago | (#30056740)

Don't you mean, "Go Go Go Google Language!"

Lightweight languages do not remain lightweight. (5, Insightful)

reporter (666905) | more than 4 years ago | (#30057048)

Ars Technica writes, "A video illustrates just how fast compilation is: the entire language, 120K lines, compiles in under 10 sec. on a laptop."

If this language becomes as popular as Perl, then 120,000 lines will soon become 1,200,000 lines. That is exactly what happened to the Perl interpreter and compiler.

Also, just like Java, the new Go language (due to the immense respect for Google's scientific prowess) will likely receive accolades: "it is the best, final language that we will ever need". The same was said for Java. It was sold as the ultimate final language built on 50 years of accumulated knowledge of language design and computer architecture. Upon the introduction of Java, company after company blindly adopted it.

Was Java the final language satisfying humankind's computing needs? No. Was adopting it worth the cost? Maybe.

Now, we have Go. Is it a massive improvement over C and Java, thus justifying spending milions of dollars to train programmers? Only the future will tell.

Re:Sponsored by Inspector Gadget (1)

CarpetShark (865376) | more than 4 years ago | (#30057066)

$ go
No
$

Re:Sponsored by Inspector Gadget (0)

Anonymous Coward | more than 4 years ago | (#30057130)

*Guitar riff* dun DUN dun dun dun.. dun DUN dun dun dun..

*Cue background images of Google developers doing random gymnastics moves and changing into Google colored fighting suits*

Re:Sponsored by Inspector Gadget (1)

EspressoFreak (237002) | more than 4 years ago | (#30057140)

co-sponsored with the power rangers...

I suppose this is Windows-only once again... (4, Funny)

Yvan256 (722131) | more than 4 years ago | (#30056514)

Go compilers support two operating systems (Linux, Mac OS X) and three instruction sets.

Can somebody call hell to see if they can host the next Winter Olympics?

Re:I suppose this is Windows-only once again... (3, Insightful)

TejWC (758299) | more than 4 years ago | (#30056702)

I think it supports Linux and MacOS X only because the three main developers (Ken Thompson, Rob Pike, Robert Griesemer) seem to only have those two OSs between the three of them. I know Rob Pike is a Mac user and Ken Thompson loves Unix; I am guessing Robert Griesemer likes Unix as well.
Its hard to support an OS when its not your primary computing platform.

Re:I suppose this is Windows-only once again... (0)

Anonymous Coward | more than 4 years ago | (#30056758)

Plus google doesn't use Windows internally -- all their desktops run Linux

Who programs on Windows, anyway? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30056780)

Besides people who work at Microsoft, that is.

Re:Who programs on Windows, anyway? (1)

palegray.net (1195047) | more than 4 years ago | (#30056938)

People who write software that runs on Windows. Thankfully, I'm not one of them anymore; it's all Linux and MacOS X for me these days.

Re:Who programs on Windows, anyway? (1)

onefriedrice (1171917) | more than 4 years ago | (#30057014)

I target Windows even though I don't run it, just because it's so easy. The mingw32 toolchain is fantastic. Otherwise, yeah, I probably wouldn't bother...

Re:I suppose this is Windows-only once again... (2, Informative)

abdulla (523920) | more than 4 years ago | (#30056834)

That's not true. You have a choice as to what OS you want to run on your desk, and what machine you want to run it on. Mac OS X, Linux and Windows are officially supported - I haven't seen anything else.

Re:I suppose this is Windows-only once again... (5, Informative)

Temporal (96070) | more than 4 years ago | (#30056926)

Ken Thompson loves Unix

Loves Unix? Ken Thompson [wikipedia.org] invented Unix. Along with Dennis Ritchie. In 1969.

So yeah. It would be kind of silly if he created something Windows-only...

Re:I suppose this is Windows-only once again... (2, Informative)

cheesecake23 (1110663) | more than 4 years ago | (#30056838)

It almost certainly will be frozen over, so weather won't be a problem. But with a population of 352 [wikipedia.org] , I suppose lack of infrastructure could be a problem for having Winter Olympics in Hell.

Attempting to install it... (4, Informative)

cptnapalm (120276) | more than 4 years ago | (#30056532)

Not having much luck. It can't find /etc/passwd, /etc/group or /etc/hosts. All of which do exist. I'm inserting fmt.Fprintf statements to attempt to figure out why it is having problems.

A novel idea: make people learn Go by requiring them to modify it in order to install it.

Re:Attempting to install it... (0)

Anonymous Coward | more than 4 years ago | (#30056666)

Learn Go? For that? Why, you always can strace it to find where it looks, and find this literal string in source to edit!. Well, they need to build "/etc/passwd" string in a nontrivial way in runtime..

Re:Attempting to install it... (1)

Jah-Wren Ryel (80510) | more than 4 years ago | (#30057080)

Not having much luck. It can't find /etc/passwd, /etc/group or /etc/hosts. All of which do exist. I'm inserting fmt.Fprintf statements to attempt to figure out why it is having problems.

Is there no debugger support? Printfs are PainAss.

Google search "Go" (5, Funny)

sshore (50665) | more than 4 years ago | (#30056542)

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

Re:Google search "Go" (1)

cptnapalm (120276) | more than 4 years ago | (#30056610)

You're having that problem too, eh?

Re:Google search "Go" (5, Funny)

TejWC (758299) | more than 4 years ago | (#30056616)

Perhaps we should abbreviate the "Go Programming Language" to "GPL"? That way, we can google for "GPL" and find Go code all over the place.

Re:Google search "Go" (0)

Anonymous Coward | more than 4 years ago | (#30056654)

Mod parent funny and I'll give you a dollar on monday.

Re:Google search "Go" (2, Interesting)

cheesecake23 (1110663) | more than 4 years ago | (#30056692)

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

Yeah, why couldn't they use unambiguous names like all other programming languages, like C, Java, Python and Ruby?

Sarcasm aside, I agree that the naming is unfortunate (although I love the Go Ogle debugger pun [golang.org] ). The parent was probably referring to the common verb, but this will also make it much harder for Go players like myself to find books and stuff for the board game. This guy [google.com] isn't happy either.

Re:Google search "Go" (3, Informative)

Animats (122034) | more than 4 years ago | (#30056808)

It's a small complaint, I'm sure.. but couldn't they have given it a name that you could, you know, Google?

One could do worse. There was a language called "C+@" developed at Bell Labs. It's derived from C, with classes, dynamism, and safety, much like Java. It predates Java by a few years. Try to find it.

Re:Google search "Go" (2, Insightful)

michaelmuffin (1149499) | more than 4 years ago | (#30056910)

the go authors have a decades-old practice of deliberately choosing annoying names "in the Bell Labs tradition of selecting names that make marketeers wince."

http://plan9.bell-labs.com/wiki/plan9/FAQ/index.html [bell-labs.com]

Re:Google search "Go" (1)

reSonans (732669) | more than 4 years ago | (#30056984)

And what's with their mascot? It's cute, but my first impression was an accelerating potato.

Well said (1)

CarpetShark (865376) | more than 4 years ago | (#30057044)

I was just about to bemoan the naming, which conflicts with Go (the board game), which is already difficult enough to google. The fact that it's GOOGLE making this mistake is pretty bad. On the other hand, maybe they'll fix the bug in their search engine now, and make it easier to google both :)

Re:Well said (0)

Anonymous Coward | more than 4 years ago | (#30057104)

Search: Go programming language
Search: Go board game

Unless the site you want is a programming site with a forum about the board game then this should work perfectly well with Google Search.

fmt (5, Insightful)

Duradin (1261418) | more than 4 years ago | (#30056554)

Vowels aren't nearly as expensive as they used to be back in the day.

It'd be a nice touch if they'd add vowel support in package names.

use Microsoft then... (1)

tjstork (137384) | more than 4 years ago | (#30056824)

and have the pleasure of intellisense adding stuff like String.Format...

I'll take fmt any day of the week.

Re:use Microsoft then... (0)

Anonymous Coward | more than 4 years ago | (#30056850)

Will do.

Re:use Microsoft then... (1)

nschubach (922175) | more than 4 years ago | (#30057106)

Honestly, I still love how StringBuilder is a separate class from a String. Why is it so hard to make String blah; blah.Append("goo");? Recently reading through Code Complete (published by Microsoft) touches on this subject in Chapter 6.4 if I remember right...

compiled in under 10 sec? (2, Funny)

martin-boundary (547041) | more than 4 years ago | (#30056646)

I don't think so. I have an old Thinkpad 701C laptop which ain't compilin' this in under 10 seconds, if at all.

Not actually safe (3, Interesting)

jfjfjdk (1260722) | more than 4 years ago | (#30056648)

From a brief review of the language and implementation, this doesn't appear to use what we've learned about correctness over the last thirty years. Buffer overflows are just one bug class among dozens, and if you're going to create a language from scratch, why let integers overflow without making people explicitly request that behavior? Why ignore what we've learned about verification and formal languages? Microsoft has actually been far more responsible about this recently, thanks to the Java people they hired (Rustan etc); see Spec# [microsoft.com] for details.

Re:Not actually safe (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30056750)

You're pretty bold giving MS any credit here. This is the home of the Google fanboi, for reasons I don't understand other than some people hope Google will take down Microsoft.

I'm an AC because of companies like google.

Named after the most difficult-to-master game ever (4, Funny)

Culture20 (968837) | more than 4 years ago | (#30056652)

This bodes well.

Re:Named after the most difficult-to-master game e (3, Insightful)

cheesecake23 (1110663) | more than 4 years ago | (#30056762)

The game may well be the most difficult to master of all games in history, but it is simultaneously one of the easiest to learn and to enjoy. Which actually does bode well for the language. If Go (language) is to C as Go (game) is to chess, then they nailed it.

But, as I just posted in another thread here [slashdot.org] , there are other problems with the naming.

Wonder? (1)

bongey (974911) | more than 4 years ago | (#30056662)

Does Go have goto statement ?

Re:Wonder? (3, Informative)

michaelmuffin (1149499) | more than 4 years ago | (#30056744)

Does Go have goto statement ?

why wonder when you can look it up? http://golang.org/doc/go_spec.html [golang.org]

tl;dr yes, it has goto

Re:Wonder? (1, Funny)

Anonymous Coward | more than 4 years ago | (#30057010)

But disappointingly, they went with the well-worn keyword "goto" instead of following Common Lisp and calling the statement simply "go".

Re:Wonder? (1, Funny)

Anonymous Coward | more than 4 years ago | (#30057076)

Does Go have goto statement ?

why wonder when you can look it up? http://golang.org/doc/go_spec.html [golang.org]

tl;dr yes, it has goto

It doesn't have comefrom though. Words alone cannot express my disappointment.

No Exceptions?! (2, Insightful)

CarpetShark (865376) | more than 4 years ago | (#30057088)

tl;dr yes, it has goto

But apparently not exceptions? It sounded good in theory. Lack of assertions was going to bug me. Lack of exceptions and try...finally blocks is most likely a deal-breaker. I'll read the thing in detail at some stage and see if they provide a decent alternative though.

Found it... (3, Insightful)

CarpetShark (865376) | more than 4 years ago | (#30057126)

Found confirmation of this in Go's "Language Design FAQ":

Why does Go not have exceptions?

Exceptions are a similar story. A number of designs for exceptions have been proposed but each adds significant complexity to the language and run-time. By their very nature, exceptions span functions and perhaps even goroutines; they have wide-ranging implications. There is also concern about the effect they would have on the libraries. They are, by definition, exceptional yet experience with other languages that support them show they have profound effect on library and interface specification. It would be nice to find a design that allows them to be truly exceptional without encouraging common errors to turn into special control flow that requires every programmer to compensate.

Like generics, exceptions remain an open issue.

So in other words, they left every single user of the language to do it, over and over again, because it seemed like a lot of work for the team to do well, once. Sorry, but that just doesn't cut it.

As for exceptions increasing control flow compensation... Java had this right; if a function's interface specifies what it throws, then you by definition save yourself a lot of control flow headaches, as you know exactly what calling a function can result in.

Intolerable (1, Funny)

Anonymous Coward | more than 4 years ago | (#30056696)

I don't like how this language uses "func" instead of "function", therefore this language is terrible and everyone who uses it or thinks about it in any way except for about it sucking is also terrible.

Re:Intolerable (1)

Javaman59 (524434) | more than 4 years ago | (#30056844)

Congratulations, you just saved yourself the trouble of reading past the first 4 lines of the language's home page. I trust you've put the time you saved to good use :)

"Systems" language? (4, Interesting)

TopSpin (753) | more than 4 years ago | (#30056700)

They're billing Go as a "systems language." If by "system" they mean "application server in a Google data center" then I suppose that's correct. Previously the term "systems language" referred to languages suitable for operation system implementation, including device drivers, virtual memory management and other persnickety low-level software. Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions [microsoft.com] to that thinking.)

There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention. Not that trying is bad; by all means keep at it. Can't afford the mental bandwidth to jump on more new bandwagons, however.

Re:"Systems" language? (2, Interesting)

michaelmuffin (1149499) | more than 4 years ago | (#30056818)

Lack of pointer arithmetic and explicit memory management probably precludes any attempt to use Go as a "systems" language by that definition (although there are exceptions [microsoft.com] to that thinking.)

inferno is another exception to your definition of systems language. much of it is written in limbo, a direct ancestor of go. it too has automatic memory management and no pointer arithmatic and it works just fine

http://en.wikipedia.org/wiki/Inferno_(operating_system) [wikipedia.org]
http://en.wikipedia.org/wiki/Limbo_(programming_language) [wikipedia.org]

Re:"Systems" language? (0)

Anonymous Coward | more than 4 years ago | (#30056878)

corrections:
- the language is called "limbo"; the system is called "inferno".
- the kernel was not written in limbo; it was written in c.

Re:"Systems" language? (1)

michaelmuffin (1149499) | more than 4 years ago | (#30056958)

the language is called "limbo"; the system is called "inferno".

well they're both exceptions to op's definition whichever way you phrase it, right? yes

the kernel was not written in limbo; it was written in c.

like i said, much of it is written in limbo. there is more to an operating system than a kernel, especially in an os such as inferno which tries to do as much code as possible in userspace

Re:"Systems" language? (0)

Anonymous Coward | more than 4 years ago | (#30057096)

there is more to an operating system than a kernel,

But there is nothing more to a traditional "systems language" than a kernel. Other uses may be possible, but they don't fall under the traditional definition of systems language.

Re:"Systems" language? (1)

cheesecake23 (1110663) | more than 4 years ago | (#30056918)

There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention.

Personally I think that with C-like syntax, Javascript-like garbage collection, closures and general simplicity, ridiculously straightforward concurrent programming constructs, a novel relaxed approach to Object Orientation and backing by Google, this will be a language to keep an eye on.

Re:"Systems" language? (1)

shmlco (594907) | more than 4 years ago | (#30056964)

"...a novel relaxed approach to Object Orientation..."

No inheritance? Yeah, that's a "relaxed" approach all right...

Re:"Systems" language? (1)

mister_dave (1613441) | more than 4 years ago | (#30057002)

Is it backed by Google? I thought it was an engineer's "20%" project.

Objective C, which has recently introduced [arstechnica.com] many of the features you admire in Go, is backed by Apple, but has never taken off outside the MacVerse.

Re:"Systems" language? (4, Insightful)

Animats (122034) | more than 4 years ago | (#30056990)

Actually, you don't need pointer arithmetic for a "systems language". Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath. You need the ability to explicitly place arrays in memory as a form of privileged hardware access, but it's not something that's used in most code.

Garbage collection, though, implies there's a layer of software underneath your code. Garbage collectors either freeze the whole program, or need some help from the MMU to track pages altered while the collector is running. Hard real time and reference counts do not play well together. Reference counted systems don't inherently have that problem, and if the compiler optimizes out reference count updates they can be efficient. But most reference counted systems are slow and dumb.

It's sad to see yet another C++ alternative that can't actually replace C++. We need a C++ replacement. C++ has stagnated. C++ is the only major language to have hiding ("abstraction") without memory safety, a bad combination never tried again. Strostrup is in denial about this being a problem, and the C++ standards committee is of in template la-la land, fussing over features few care about and fewer will use correctly.

The previous poster is right, though. This is a language for writing applications to run on servers. Google needs something less painful than C++ and faster than Python. (Python is a reasonably good language held back by an archaic naive-interpreter implementation. Making Python fast is hard, though, because the compiler has to do type inference to figure out the variable type information the user isn't asked to provide. ShedSkin shows that can work, but that project only has one person on it.)

Re:"Systems" language? (3, Funny)

ClosedSource (238333) | more than 4 years ago | (#30057090)

"Neither Ada nor the Modula family had it, and those languages have been run on bare machines with no other OS underneath"

Or customers above either.

Re:"Systems" language? (1)

DerekLyons (302214) | more than 4 years ago | (#30057050)

There is too much competition from other fresh and well regarded "new" languages for yet another new entrant to gain much headway without something really novel to attract attention.

Open Source.
Google branded.
 
It doesn't need anything novel when it hits two of the top orgasm buttons among many geeks, techies, and wanna bees. All that's missing for a grand slam is a connection to Apple.

C++ incomplete. C# windoz. Java slow elephant. (4, Insightful)

upuv (1201447) | more than 4 years ago | (#30056796)

I've been around for a long time.

C great language did exactly what it was designed to do. But carries a lot of burden.
C++ come on it didn't even have a string class. Thus pointer math hell.
C#, Ok it learned a lesson and found the joy of a string class. But really it's a windows only lang.
Java. Excuse me web apps that take 8Gig of ram spread across a farm of servers. This slow elephant remade the hardware business.

All of the above never really understood concurrent / multithread / parallel. ( Sorry Java devs still have issues with the concept. GC & log4j come to mind as things that forgot they were in a threaded env. )

So the "Go" lang it just might deserve a look. Clearly web centric. Clearly built for tons of concurrent comms. Recompiles in a blip thus useful for real time compiling alla jsp. I'm very performance centric. If I can replace my J2EE bloat ware with a trunk full of tiny Go apps I will.

I'm definitely watching this space for developments.

Re:C++ incomplete. C# windoz. Java slow elephant. (0)

Anonymous Coward | more than 4 years ago | (#30056980)

C++ standard library has string class. Somehow most C/C++ coders has this strange fixation to write everything from scratch. Thanks to them it data type conversion hell every time when you use two or more libraries in your project.

Re:C++ incomplete. C# windoz. Java slow elephant. (1)

CarpetShark (865376) | more than 4 years ago | (#30057078)

Somehow most C/C++ coders has this strange fixation to write everything from scratch.

That's probably because the C++ standard library isn't so easy to remember.

Re:C++ incomplete. C# windoz. Java slow elephant. (1, Informative)

Anonymous Coward | more than 4 years ago | (#30057012)

C++ come on it didn't even have a string class. Thus pointer math hell.

I'm not going to suggest you should use C++ but seriously, can you at least use real criticism? What is std::string [cplusplus.com] then?

And no, "that was only added in 1995" doesn't count as a criticism since C++ was not defined as an ISO standard until 1998 and std::string has been there ever since.

Not Google Branded (1)

M3gaBight (968603) | more than 4 years ago | (#30056798)

One thing that suprises me about this is that there's no reference to this being a Google project on the front page. Is this a deliberate move to seperate it from normal Google activities? To give it more of a chance as something other than the latest Google fad? Any ideas? It doesn't even look like it's geared specifically towards web apps.

Re:Not Google Branded (1)

exley (221867) | more than 4 years ago | (#30056988)

They should have called it Go Beta; then we would know without it being explicit.

Re:Not Google Branded (1)

palegray.net (1195047) | more than 4 years ago | (#30057008)

without it being explicit

What, Go supports naked data structures?

Fixes problems misguided people think C++ has. (5, Insightful)

pslam (97660) | more than 4 years ago | (#30056846)

Go has garbage collection and lacks pointer arithmetic. So... it won't replace C++, then?

Why was that so easy and quick to say? I really don't understand the repeated banging-head-against-wall that language inventors are doing. There's a good reason why C++ is still in wide and very popular use: precisely because it does have explicit memory management and pointer arithmetic. C++ is a static, explicit language. Go is not. It will not replace C++, and no language will until that is understood.

The problems C++ need fixing are elsewhere. The syntax needs cleaning up. The ABI needs rationalizing between architectures. Multiple inheritance needs some taming (ditch 'virtual' multiple inheritance - it's insane), but not removing. Interface-only classes need promoting to a full type rather than inferred from being 100% pure virtual (and even then there's usually a non-pure-virtual destructor for stupid foot-bullet-avoiding reasons). There needs to be saner syntactic sugar for repeated operations (like python's 'with' keyword). Templates syntax needs to be less verbose and more automatic (already being worked on for C++0x but at this rate will be C++1x, keyword 'auto').

Stop trying to replace C++ with a language that does not fulfill every aspect C++ covers. If you ARE a language inventor and reading my comment, answer this: can you write a cache/MMU interface or an interrupt handler in your language? If the answer is no, go back to the drawing board.

Maybe C really is "it" for now... (2, Interesting)

cgenman (325138) | more than 4 years ago | (#30056902)

Despite the large amount of enthusiasm for language design, modern mainstream programming languages don't fall far from the C tree.

Perhaps, like Qwerty, our C-based languages have evolved to be "good enough" for programming needs for the foreseeable future. Make objects, make functions, operate between the two.. sure DVORAK might provide 20% faster typing if you work at it for 3 years, but that's not really enough to warrant the switch. We're unlikely to see a jump again of the size from C to C++ before we hit a major structural change. I had thought the web might be that structural change, but that was well absorbed by extending existing ideas.

Personally, I just want to see programming languages that are more programmer fault-tolerant. I can type "pizza" into my phone and have Chuck-E-Cheese offer to bake one while I drive over, but if I accidentally type "plaeyrArray" instead of "playerArray," the whole world is clearly on fire and everyone is going to die. Why can't compilers be more intelligent about the types of errors they encounter in routine usage? For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

Re:Maybe C really is "it" for now... (1)

Delwin (599872) | more than 4 years ago | (#30057094)

massively parallel systems may be that structural change... but things like CUDA are filling that gap so maybe?

Re:Maybe C really is "it" for now... (1)

ClosedSource (238333) | more than 4 years ago | (#30057108)

"..sure DVORAK might provide 20% faster typing if you work at it for 3 years, but that's not really enough to warrant the switch."

Sure, if you're typing code, but if you were typing documents it would be a big advantage. I don't know where you get the 3 years idea - DVORAK is much easier to learn than QWERTY.

Re:Maybe C really is "it" for now... (0)

Anonymous Coward | more than 4 years ago | (#30057134)

Why can't compilers be more intelligent about the types of errors they encounter in routine usage?

Ummmm... I don't think it's a good idea to let the compiler "fix" misspellings in my code. Will it change "plaeyrArray" to "playerArray" or "payerArray"? I don't see anything wrong with just reporting an error.

For that matter, why are we still defining code chunks via brackets instead of the indentation that's already there?

Aren't you confusing elements of language syntax with visual formatting? I think some languages use indentation for defining functions and whatnot but it seems like a bad idea. to me. Would 6 spaces mean the same thing as a tab and 2 spaces? Would the program change operation if I format it to print the source differently? Yikes!

PS. Isn't using var names like "xxxArray" considered poor form? It brings back bad memories to me of 1980's Windows programming, heheheh!

GoLibs? (0)

Anonymous Coward | more than 4 years ago | (#30056906)

Or maybe we should drop the term "Library". M$ probably has it trade marked. I vote GoNads!

Instant Language Build-O-Matic (4, Funny)

Tablizer (95088) | more than 4 years ago | (#30056940)

Joy, yet another programming language :-) Programming languages are personal. We all have our favorite way to do things and most of the choices are subjective preferences. At c2.com we played around with the idea of a Build-To-Order form to generate a compiler/interpreter for a language with the combination of features you ask for. Below is a rough re-creation of the form:

-----INSTANT CUSTOM LANGUAGE FORM-----

(Features in each group are mutually-exclusive if they have round brackets, but not if square brackets. )

Compile Level

        * (__) Compiled: product of language targeted to direct run by a machine (possibly a virtual machine) or operating system.
        * (__) Interpreted: language is processed as data by a process called an interpreter, especially in some sort of ReadEvalPrintLoop. May support a hidden JustInTimeCompilation, but that should be considered an implementation detail rather than a language detail.
        * (__) Both but select on Program: language allows programs to be written for scripting or written for compilation, but programs written for compilation might not work for interpretation (e.g. due to late-binding dependencies) and programs written for interpretation might not work for compilation (e.g. due to top-level commands). This provides a lot of flexibility. However, it also partitions the user community because sharing will be difficult.
        * (__) Both for any Program: language ensures that every program is suitable for both compilation and interpretation. Supporting interpretation requires abandoning a model of external linking and requires ensuring the syntax is suitable for one-pass reading (i.e. preprocessors are a bad thing). Suitability for compilation implies abandoning (or at least distinguishing) imperative commands at the toplevel: those that are to be executed at compile-time vs. those that are to be executed at runtime.

Model for Linking and Modularity

        * (__) No Linking: product is always fully declared from a single page or file. No linking occurs. There is no model for modularity. Many EsotericProgrammingLanguages have this model. Support for CompileTimeResolution may provide an interesting workaround.
        * (__) Includes: product may 'include' other pages, which are linked in place. There might be a system to selectively avoid duplicate includes. All pages are effectively parsed with each compile or execution.
        * (__) Single Page, Modular: language semantics allow 'importing' or 'loading' of other components. Allows useful optimizations such as compilation of components... or at least preprocessing and pre-parsing, of language components, because the semantics of the 'import' are held independent of the page into which it was imported.
        * (__) External Linking: a linker can combine a product by pulling multiple components together, but does so from outside the language. This model is incompatible with interpretation, and offers no real benefits over the 'Single Page, Modular' model except that it can be hacked into a language that doesn't have a concept of modularity (as was done for CeeLanguage).

Modularity and Linkage Features

        * [__] Resolution of Circular Dependencies: the language or linker will correctly handle circular dependencies, ideally with minimal reliance on forward declarations.
        * [__] Provisionals and Overrides: the language allows you to override global objects, values, or procedure that are declared in other modules in a manner such that those other modules use the overrides, too. Ideal form would be as though they had always used the override, but this ideal form is somewhat difficult to reconcile this feature with interpretation.
        * [__] Inverted Constructs: one can automatically build or construct a shared value from scattered bits and pieces. Normal modularity works the other direction, allowing other components to access a value or function provided by a module, but this opposite direction is useful for building registries and dynamic methods. Often performed procedurally.
        * [__] Properly Ordered Startup and Shutdown Procedures: the language can determine a proper order in which to initialize and destroy global objects based on forming a dependency graph between them. This would ensure, for example, that a global mutex object isn't destroyed before it is no longer in use. (Note: The easiest means of achieving this is to reject the notion of startup and shutdown execution, but that may harm other features.)
        * [__] Framework abstraction techniques: a semantic mechanism exists to modularly factor the decision-making process for issuing a behavior from the behavior itself. We call these things 'frameworks'. Example solutions include FunctorObject, function pointers, and HigherOrderFunctions.
        * [__] Decentralized framework abstraction techniques: as per framework abstraction, but the decision on which behavior to select is itself constructed modularly instead of all in one place. The best known approach to achieve this is MultiMethods (as opposed to regular polymorphism).
        * [__] Delimited Exports: programmer control over exactly what is exported from a module. This provides encapsulation and helps prevent implementation details from leaking or being coupled to in other people's projects, and thus makes easier the maintenance of shared modules. Coupling to implementation details can generally be considered a bad thing, as it raises backwards compatibility issues.
        * [__] Namespaces: support for namespaces (even just 'modules ARE namespaces') vastly reduces probability of naming collisions. Proper namespaces are more necessary with 'includes' based modularity.

Resource Management:

        * (__) Fully Unmanaged: programmer is responsible for destruction/closing of all resources.
        * (__) Partially Managed: some resources will be automatically cleaned up. C++ stack operates in this manner. Programmer is expected to manage others.
        * (__) Fully Managed: programmer is expected to leak resources, which will generally be collected by the system at some point. Programmer might be able to release resources earlier.
        * (__) Strictly Managed: same as fully managed, except that the programmer has no ability to clean up resources directly.

Language-supported Models of Computation: (requires a convenient syntax, and support via the standard language or standard libraries)

        * [__] ImperativeProgramming: describe program behavior in terms of actions to perform and contingencies based on immediately observable phenomena, usually via mutations on cells or variables and the sending/receiving of messages. Support for describing procedures and sub-procedures usually qualifies.
        * [__] FunctionalProgramming: describe program behavior as an expression whose value needs to be calculated.
        * [__] ConstraintLogicProgramming: automated searches in an ambiguous space for results meeting a specific patterns. Inverted evaluation ordering from functional (e.g. can determine parameters to a function given its output). Backtracking implied.
        * [__] ObjectOrientedProgramming: describe a program in terms of components living in the language runtime that are dynamically built and hooked together to form something of a 'virtual machine'. These components then interact by passing either messages (immutable values) or components between one another.
        * [__] DataflowProgramming: declaratively hook together components between data sources and data sinks to produce workflows. Not quite object-oriented, in that the dataflow and the components themselves might not be dynamically constructed... but combines very nicely with asynchronous OOP.
        * [__] ReactiveProgramming: a persisted, event-driven form of FlowBasedProgramming where updates or changes are streamed continuously.
        * [__] LazyProgramming?: language support for delaying computations (and even communications) until need arises. Explicit (laziness requires extra syntax) or implicit (lazy by default). Note that this is semantic laziness, which is different from laziness or reordering as an optimization: semantic laziness allows infinite structures.

Language Primary Decision Logic (the one integrated with common libraries and predicates)

        * (__) Boolean
        * (__) ThreeValuedLogic
        * (__) FuzzyLogic
        * (__) Higher logic that Tracks causes for Unknowns (intuitionist, modal, etc.)
        * (__) Full Confidence, Belief, and Knowledge System (you've probably got a logic language...)

Language support for Collections: (assuming SymmetryOfLanguage: features should apply to all 'standard' collections).

        * [__] Support for dynamically-sized collections, be they represented as values or objects.
        * [__] Support for efficient iteration over collection values.
        * [__] Support for high-level collection operations: union, intersect, difference, append, fold, sum, join, product, etc.
        * [__] Support for efficient small deltas over collections; ability to share structure
        * [__] Support for very large collections that shatter the memory limits of the language runtime.
        * [__] Support for automatically parallelizing operations over very large collections (though these operations may need to have certain properties like associative ordering and merging.)
        * [__] Adaptive and/or Declarative indexing of collection objects based on needs (e.g. 'index on ...'). Automatic maintenance of these indexes as collections are updated.
        * [__] Support for fuzzy likeness and nearness indexing (e.g. spatial clustering)
        * [__] Language Integrated Queries, automatically Optimized based on available indexes.
        * [__] Support for efficient views over collections, in particular without copying the larger collections.
        * [__] Support for efficient updating of views over collections, e.g. ReactiveProgramming with DataDeltaIsolation.
        * [__] Support for efficient versioning of collections... which really requires cheap deltas with structure sharing. Necessary for efficient SoftwareTransactionalMemory or FirstClassUndo.

Language support for pattern-matching:

        * [__] Case Equality with Dispatch. If-then statements and CeeLanguage 'switch' statements qualify.
        * [__] Pattern Matching with Variables over arbitrary values, e.g. Haskell or OCaml style.
        * [__] Regular expressions: simple pattern matching over simple collections.
        * [__] Full value-based EBNF parsers: arbitrary pattern matching and folding over arbitrary value collections.
        * [__] Fuzzy matching and heuristic nearness (aka 'best match')

Language standard support for User Interface:

        * [__] Console input and output (read, print; console is 'special' assumed to always be there)
        * [__] Standard support for dialogs (a'la TK)
        * [__] Standard support for formatted text displays (HTML, PS, TEX, SceneGraph based on DocumentObjectModel)
        * [__] DirectManipulation or ObjectBrowser UI (viewed objects directly represent language runtime objects; SmallTalk)
        * [__] Standard support for arbitrary 2D graphics (LogoLanguage, PS)
        * [__] Standard support for arbitrary 3D graphics (PovRay, VRML)
        * [__] Standard support for InteractiveSceneGraphs (pointing, clicking, zooming, performing actions according to rules)
        * [__] My language doesn't have a standard User Interface, and I think that is a feature.

Language standard User Interface Features:

        * [__] User Interface support subject to stylistic interpretation layers on output (e.g. CSS for dialogs or scenegraphs)
        * [__] User Interface support subject to stylistic interpretive indirection on input (useful for handicapped accessibility)
        * [__] Language supports versioning and FirstClassUndo over internal constructs, offering these by default
        * [__] Language UI follows principles of CapabilityUserInterface
        * [__] Default support for ProgressiveDisclosure, LevelOfDetail?, ZoomableUserInterface
        * [__] ImmediateModeGui: the UI refers entirely to internal state and (emphatically) not the process by which it got there. This enables the UI for persistence, regeneration, and other features.
        * [__] User Interface subject to queries to determine the 'view' (especially neat with ObjectBrowser); requires ImmediateModeGui

Language support for Parallel Operation:

        * [__] FirstClass threads or processes: language provides a standard, portable version of a semantically asynchronous components.
        * [__] SeparateIoFromCalculation: language-enforced SeparationOfConcerns between communication and calculation. Can be done by dividing a 'pure functional' component from a 'pure imperative' component. This division exposes a great deal of latent parallelism because referentially transparent functional evaluations can occur in arbitrary orders. Note that one might be able to take advantage of latent parallelism even if the language has no semantic asynchronous components.
        * [__] Asynchronous Message Send: language provides features for asynchronous delivery of messages, including message queues.
        * [__] Synchronous Message Send: language provides features for synchronous delivery of messages; queues can be synthesized via separate threads. Replies to earlier message sends are, themselves, also message sends.
        * [__] Promise Pipelining: passing promises to get stuff done or return certain values back and forth so that one can do the more interesting stuff immediately.
        * [__] RealTime: language is designed to make and keep promises about when certain actions will occur even with a large amount of resource competition. Fairly cross-cutting.
        * [__] Concurrent Logic and Data Programming: Language automatically exploits heavy parallelism when performing searches, joins, filters, and other operations over large collections.

Language support for Safe Shared Memory access:

        * (__) No Safety: No language support for safety. Not a problem if there is no parallel operation. Also includes cases where safety and parallel operation is non-standard.
        * (__) Low Level (e.g. Mutexes): Simple exclusions, semaphores, etc. These can be used to achieve safety, but cannot be composed readily without high risk of deadlock. See LanguageInhibitsRefactoring.
        * (__) SoftwareTransactionalMemory: transactions are provided over memory with at least Atomic and Isolation semantics and whatever degree of durability is achieved by the memory involved. Using hierarchical transactions allows one to safely compose operations.
        * (__) No Shared Memory: Memory is safe because it isn't shared. Communication occurs by passing of immutable message values. Any state exists internally to each process. Erlang chooses this model, but it isn't as good as one might initially believe for distribution (one still occasionally ends up emulating shared memory by sharing references to process handles, and one then must emulate mutexes or transactions...).
        * (__) TransactionalActorModel: DistributedTransactions? between FirstClass processes, with No Shared Memory between them. Essentially, even the unshared memory is SoftwareTransactionalMemory, and even the process life-cycle is subject to transactions (i.e. if a new process is started as part of a transaction, that is undone if the transaction is aborted).

Support for Distributed Operation:

        * [__] Official representation of Process Object: A process object can be folded up, serialized, and transported to a remote machine, then continued.
        * [__] Distribution of State: locality of state must be modeled and enforced or all state in the language is global. A pointer to someone else's local variable is prevented.
        * [__] Distributed Resource Management: state and process handles that become globally known are collected globally. Not entirely necessary, but the other option is to rely far more on heuristics and deal with broken links.
        * [__] Persistence: support for persisting operations and objects in a delay-tolerant and disruption-tolerant manner; handles spurious connectivity.
        * [__] Model for parallel operation: it is difficult to optimize a synchronous programming model in an inherently asynchronous medium.
        * [__] Shun Shared Mutable State: while mutable state may be possible, disfavoring its use within the language standard libraries is better for distributed operation.
        * [__] Stateless Services: support in standard library the notion of stateless unsynchronized service objects, represented as immutable values, that can be copied, containing references only to global state. These may 'distribute' via duplication rather than migration, such that copies are available any place they might be needed.
        * [__] State Services: recognize and specialize sate-services as opposed to implementing them as regular process objects. This allows optimizations such as orthogonal security, distribution, caching, redundancy, change of ownership, collection, versioning, merging after offline use, etc.
        * [__] Automatic Distribution: language has model of locality such that you can assert (in component configurations) that certain objects have certain locations, most likely specified relative to one another (object A is near object B in the configuration) instead of absolute locations. A single object-configuration could, when constructed, be split into two or more parts and distributed to different machines. Objects with unspecified location subject to decisions by optimizer.
        * [__] Redundancy, Resilience, and Regeneration: language support for redundancy without explicit implementation by users... i.e. such that a distributed process-object graph can usually automatically recover after a partial failure, node loss, or a GarbageCollection heuristics failure (since DistributedProgramming cannot support perfect GarbageCollection).
        * [__] Support for Security: programmers can toggle and transport communications channel encryption and other security things easily, at least when working distributed within the language. This can be optimized to avoid encryption when on a single computer. Distribution may be restricted based on secrecy requirements (see discussion in DigitalRightsManagement).
        * [__] DisruptionTolerantNetworking: the language internal network protocols are designed with minimal handshaking and minimal need for hearbeats or keepalives. GracefulDegradation and recovery during disruptions or delays.
        * [__] Offline Support: design to go 'offline' in a prepared way; language runtime can track the things it needs to download to perform offline work, and the language itself is designed to avoid external dependencies. There is a big difference between recovering gracefully from an offline experience and preparing to continue work in anticipation of going offline.

Language Supported Forms of Implicit Context:

        * [__] LocalVariable?: one can (via a 'let' statement or in a scope) declare local variables that are then accessible to code written within that scope.
        * [__] GlobalVariable: variables accessible to all parts of a process.
        * [__] DynamicScoping: DynamicScoping for all variables.
        * [__] SpecialVariable: DynamicScoping for some variables.
        * [__] Thread Local Storage: support for variables global to the process but local to the thread.
        * [__] Implicitly Threaded ContextObject: Haskell-style syntactic sugar for threading a large object (like a Monad) that represents the current context. (see also ExplicitManagementOfImplicitContext).

Syntactic Abstraction

        * (__) None
        * (__) Keyword Based (most forms of macros)
        * (__) Full Syntax Manipulation (new operators, new keywords, etc.)
        * (__) Non-Monotonic Syntax Manipulation (as Full, but can also remove old operators, keywords, etc.)

Syntactic Abstraction Features:

        * [__] Hygienic by default (avoids variable capture without explicit symbol generation)
        * [__] Allows variable capture
        * [__] Support for spatially limited syntax support (e.g. just for a block or namespace)
        * [__] Support for modular syntax manipulation (syntax can be an export from a module)
        * [__] TuringComplete; capable of fulfilling arbitrary requirements
        * [__] Structure aware (as opposed to source text substitution)
        * [__] Semantics aware (e.g. type-sensitive macro dispatch; generally elides preprocessor-based)
        * [__] Design capable of tracking original source for debugging (generally elides preprocessor-based)

Semantics Manipulation

        * (__) None (this is usual)
        * (__) 'Implementation-based' Extension Support (e.g. C++ #pragma) - not good for portable code!
        * (__) Manipulation or overrides of some runtime components
        * (__) Manipulation of Postprocess pipeline (e.g. add extra stages of processing, AST transforms, etc.)

Semantics Manipulation Features

        * [__] Homoiconic: an official AbstractSyntaxTree is available from within the programming environment.
        * [__] FirstClassTypes: ability to construct new types functionally.
        * [__] Reflection and Decomposition: operators exist to break down constructs. E.g. ability to ask objects for all their fields, or break down a function.
        * [__] Evaluation/Compilation: ability to build a FirstClass construct (like a function) from its Homoiconic AST or a text description, this object having the same properties as one built at initial parse time.
        * [__] CompileTimeResolution: (e.g. ability to query a database to obtain a schema at compile-time)
        * [__] Continuations: ability to construct one's own operation ordering structures; ability to return to arbitrary locations in program.
        * [__] MetaObjectProtocol
        * [__] Support for spatially limited manipulations (as opposed to global only)
        * [__] Ability to add and process (in context) entirely new AST components (requires advanced syntax manipulation)

Language Versioning Support (prepare to fail to get it right the first time...)

        * (__) None; compatibility is ad-hoc or just not a concern for language application.
        * (__) Language version statement near top of page. Compiler/Interpreter keeps old versions.
        * (__) Leverage non-monotonic syntax extension. Syntax is set from with in the language.

Default Failure Handling: internal handling of errors (as observed in standard libraries)

        * (__) Crash: standard libraries crash when misused.
        * (__) Limp: no mechanism to detect or internally report errors
        * (__) Die (crash... gracefully and explicitly)
        * (__) Error codes; reserve part of the return range to indicate errors.
        * (__) Exceptions
        * (__) Exceptions with continuations (AbortRetryIgnore) so another part of the code can decide policy for returning to work.
        * (__) Restart/Condition Mechanism (as in CommonLisp)
        * (__) Transaction Failure (with rollback).

Default Failure Reporting: support for external indications of errors

        * (__) No Support; errors will need to be reported via regular actions
        * (__) Error Output Stream (e.g. 'cerr' or STDERR in C++/C respectively)
        * (__) Alert message box
        * (__) Exposure of error-reporting hooks (useful for frameworks or standard libraries) so users can capture and process errors.
        * (__) Distributed Exceptions or Exceptions with Continuations (probably a PinkyAndTheBrainLanguage)

Failure Reporting Features: as observed in the standard mechanism

        * [__] Verbosity Levels and Semantics (error cause) for filtering
        * [__] Support for dual logging of error reports.

Syntax Design Principles: (perhaps order these in terms of priority?)

        * [__] Familiarity with existing language. You'll accept ugly syntax if it's familiar.
        * [__] Full Compatibility with existing language. Do realize that you'll be updating your language continuously if the other language is still versioning.
        * [__] Error Resistance (ability to catch certain errors by static analysis)
        * [__] Leverage/Avoid Ambiguity (see ambiguity handling, below)
        * [__] Terseness (keep programs small)... but do keep in mind that terseness is more readily achieved by good semantics that ensure ideas need to be stated OnceAndOnlyOnce.
        * [__] Readability: you think your program will be more readable because of the syntax you're choosing. Not that you've confirmed this.
        * [__] Easy Computation: language aimed to be easy to parse, refactor, or perform syntax highlighting
        * [__] GraphicalProgramming: hook code together with reduced use of explicit names.

Ambiguity Handling: ambiguity is not always an enemy; it can be used to simplify syntax and even leveraged (e.g. Polymorphism is designed to take advantage of ambiguity).

        * (__) Ambiguity Prevented (prevented in syntax)
        * (__) Ambiguity is Error (error reports: "action on line X is ambiguous; please clarify")
        * (__) Ambiguity is Heuristic Best Bet (chooses any one meaning that makes sense in context, then applies it everywhere else)
        * (__) Ambiguity is CompileTime Polymorphism (similar to C++ programming using templates for polymorphism; meaning varies at each place of application).
        * (__) Ambiguity is Runtime Polymorphism (actual dispatch is deferred; meaning varies at each time of application).

Block Syntax

        * (__) C-style braces
        * (__) Pascal-style bracing (explicit BEGIN/END pairs)
        * (__) Modula-2/Oberon-style bracing (FOR/END, IF/END, WHILE/END, etc.)
        * (__) End-X style (see TheRightWayToDoWordyBlocks)
        * (__) Significant whitespace (python/ruby)
        * (__) Parenthesis (Lisp-style)
        * (__) Square Brackets (TCL-style)
        * (__) Compiler-detected based on context (e.g., as with Haskell)
                    o Perhaps we should make the actual blocking symbol(s) a parameter rather than a radio button for each possible character.

Statement Delineation

        * (__) Token separates statements without support for empty statements
        * (__) Token separates statements with support for empty statements
        * (__) Token terminates statements

Statement Delineation Token

        * (__) Semicolon
        * (__) Colon
        * (__) Period
        * (__) Natural line with [ ] (please specify) wrap marker (e.g., use _ for VB-style)
        * (__) Parse-based determination

Type Indicator Syntax

        * (__) Before variable
        * (__) After variable (Pascal-style)
        * (__) Unspecified (DynamicTyping or ImplicitTyping)
        * (__) Unspecified with optional aspecting (optional type requirements or partial type requirements).

Native Null-Handling

        * (__) No native nulls,
        * (__) Null is a special 'invalid' reference.
        * (__) Null is semantic overloading of a domain or range value, such as using the empty string or a simple string containing "".
        * (__) Null supported in tagged union (e.g. Haskell 'Maybe' monad).
        * (__) NullObject pattern followed in standard libraries; using a NullObject for certain operations can result in exceptions, but it may be okay for others (e.g. the 'length' of a null string may be zero, but the 'isNull()' property may be different than for an empty string).
        * (__) NullObject pattern is language-enforced; for each class, you can build a companion 'Null' class with its own method implementations, with a default 'Null' class being built automatically. Assigning 'null' to a pointer automatically results in a pointer to its null-class object.

Etc...

more languages than programmers (2, Insightful)

OrangeTide (124937) | more than 4 years ago | (#30057032)

It's simple. It's a lot of fun to design and even implement your own programming language. It is not too hard, depending on how big of a problem you choose to bite off with your language. And then there are the oohs and ahhs you get from other developers when you have implemented a language, especially if it compiles to some real or virtual architecture.

Too bad learning to use a programming language effectively is a lot of work, and is usually pretty frustrating. It has been easy for me to find the time and energy to implement my compiler. But I totally don't have the time to learn C++, Haskell, Python, OCaml, Ruby, PHP, Perl, et cetera.

As a developer, and I realize this is a very silly and irrational, I tend to avoid using programs written in languages I don't understand. True, I almost never look at the source for the program. But take Gentoo emerge for example. The fact that it is written in Python instead of C, awk, shell script, Tcl, Lua, or Java is mainly why I don't run Gentoo.

Holy Shitbags Binaries Are Static And *Huge* (4, Interesting)

FrankDrebin (238464) | more than 4 years ago | (#30057018)

$ cat hello.go
package main

import "fmt"

func main() {
fmt.Printf("hello, world\n")
}
Size of resulting binary: 581054 bytes on x86 Linux.

Re:Holy Shitbags Binaries Are Static And *Huge* (1)

michaelmuffin (1149499) | more than 4 years ago | (#30057068)

Holy Shitbags Binaries Are Static And *Huge*

but they fork faster. try it: http://9fans.net/archive/2009/02/422 [9fans.net]

"Go" name already taken for programming languages (5, Informative)

qw0ntum (831414) | more than 4 years ago | (#30057042)

This fellow has been working on his own programming language, also called "Go", for a decade. Even released a book about it. He filed an issue in the tracker for the Google language: http://code.google.com/p/go/issues/detail?id=9 [google.com]

Re:"Go" name already taken for programming languag (-1)

Anonymous Coward | more than 4 years ago | (#30057116)

Actually his language is called "Go Factorial".

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>