Slashdot Mirror

C++'s days are numbered.

https://en.wikipedia.org/wiki/...

"The designers were primarily motivated by their shared dislike of C++."

References:
"Dr. Dobb's: Interview with Ken Thompson": http://www.drdobbs.com/open-so...

"Less is exponentially more": http://commandcenter.blogspot....

""The Evolution of Go": https://talks.golang.org/2015/...

And I'm not the only one who agrees.

"Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C"
https://slashdot.org/story/334...

You do know that 'go' is moving to a backwards incompatible version 2.0, right? https://blog.golang.org/toward...

You sound like a Fox News viewer.

Fox news huh? How about right from another horses mouth. Don't worry, they ARE going after you on your other social media accounts.It's not like we don't have examples. Holy fuck! Look at that, we've got just another case for wrong think. Oh, and this one too. Just to show that the Mike Pence rule applies too.

I personally think go is a miserable language, steeped deep in mediocrity. I don't need to imagine what programming with generics is like: I already know what it's like and it sucks for anything of moderate size and up. I also believe that the world of programming and types has evolved since the early 1970s.

So yeah no fan but... ...based on what you wrote, I read the code of conduct. I can't see anything objectionable in it. So what, specifically, do you not like.

https://golang.org/conduct

Go is memory safe, but uses full GC. Java and. Net already do that.

Not exactly. .NET allows exceptions under certain conditions (C# unsafe). Apparently (I didn't use it in that experiment), Go also allows unsafe (= no GC) conditions.

The reason I wanted Kay to give an explicit answer about what Engelbart got right that HTML didn't is that I'm wary about these judgements in hindsight.

I was reading Rob Pike this morning.

Go at Google: Language Design in the Service of Software Engineering — 2012

When Go launched, some claimed it was missing particular features or methodologies that were regarded as de rigueur for a modern language.

How could Go be worthwhile in the absence of these facilities?

Our answer to that is that the properties Go does have address the issues that make large-scale software development difficult.

Would s/Go/HTML/g be a correct map for Kay's opinion? Because HTML really was designed more for engineering at scale than anything else.

And this always draws a chorus of criticism from the conceptual purity boo birds.

Kay is a pretty smart guy, but did he ever learn his billion times tables really? I rather suspect that was never native to his cognitive style.

Part of the fault can go to the Go programming language for their API design.

But most of the blame goes to the developers.
I haven't coded in Go, but I googled this quickly.
https://golang.org/pkg/math/ra...
The Go documentation clearly says it panics if n = 0.

They could have
1. validated their inputs.
2. Handle the panic and assign a default value (I am assuming this is possible in Go. I have never used it)

In the end, it seems like this is just used to distribute requests. Worst case, it should log the error and then assign say the 1st upstream (default value).

But I guess then you're in the exception handling debate on whether you swallow the error and keep going or have your application crash so that you detect the weird condition.

I'm a defensive; keep the system going developer.
But others prefer to be more exact.

A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.

What is simple about that? Have you got any idea about the nature of the mechanism that is required to make code execute concurrently with other code on the same or different processor?

Push state, execute some scheduler, pop ready state. Cooperative userland concurrency is trivial. Implemented it myself for S&Gs.

It is lightweight, costing little more than the allocation of stack space.

Oh, you mean like a Linux thread created by the clone syscall, with all resources shared.

No, that is hundreds of time more expensive. Hundreds to thousands of time more expensive once you start including the context switching overhead of threads.

And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Oh, you mean like a Linux thread created by the clone syscall, which only allocates a virtual address range for the stack and faults in actual memory as required.

You falsely assume there is a lot of shared stack data. Goroutines are magnitudes more efficient even when not using CoW.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.

Oh, you mean like green threads which used to be the threading scheme of choice on Linux until the native threading support exceeded it in scalability, efficiency and reliability long ago.

Kind of similar, not sure how much. One thing about Green threads are the pseudo-async IO calls made to look async, but actually starts a new process to marshal the call.

Their design hides many of the complexities of thread creation and management."

And calling them "goroutines" hides the inconvenience of calling them what they are: threads with syntactic sugar.

There are many types of threads. The term thread can mean a wide range of implementations, all similar at the abstract level, but hugely different in the implementation level. Starting a new process is also a new thread, but we make a distinction for good reason.

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter

Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are. Emulating the clone syscall in user space may not necessarily be a win, quite the contrary. Note that the compiler does not need to call the syscall every time a new thread is needed, it can keep a pool, which would most likely be a way better design than unnecessarily emulating native OS threads in userspace.

Just to put things in perspective: to implement threads (aka goroutines) you need a scheduler, there is no way around it. Without even looking at the implementation I can tell you that the Go scheduler is naive and will be prone to undesired behavior compared to the native kernel scheduler.

"Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are" ROFL!!! It's called negative scaling, look it up. The optimal number of threads is about 2-4 per core. Based on everything you just wrote, you should not touch multi-threaded code, you have no clue what you're talking about. Typical cargo-cult programmer, lots of knowledge but only understanding a topic skin deep.

sync.Mutex?

Don't get me wrong, this is otherwise a valid criticism, but Go provides sane locking mechanisms to ensure safe concurrent access to shared resources so it's not the end of the world.

Sheeze. Ok, to wrap it up: goroutines are not OS threads like you originally suggested. There's not a a clone syscall associated with every goroutine; in fact, you can limit the number of concurrent threads on a Go process to 1 if you like and have them all run under a single process. See GOMAXPROCS.

Now, the concept of goroutines is arguably much closer to what's commonly known as "green threads". But again, this is not what you originally stated.

A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space.

What is simple about that? Have you got any idea about the nature of the mechanism that is required to make code execute concurrently with other code on the same or different processor?

It is lightweight, costing little more than the allocation of stack space.

Oh, you mean like a Linux thread created by the clone syscall, with all resources shared.

And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Oh, you mean like a Linux thread created by the clone syscall, which only allocates a virtual address range for the stack and faults in actual memory as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run.

Oh, you mean like green threads which used to be the threading scheme of choice on Linux until the native threading support exceeded it in scalability, efficiency and reliability long ago.

Their design hides many of the complexities of thread creation and management."

And calling them "goroutines" hides the inconvenience of calling them what they are: threads with syntactic sugar.

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter

Rob Pike may have gottent out of touch with just how efficient and scalable Linux threads really are. Emulating the clone syscall in user space may not necessarily be a win, quite the contrary. Note that the compiler does not need to call the syscall every time a new thread is needed, it can keep a pool, which would most likely be a way better design than unnecessarily emulating native OS threads in userspace.

Just to put things in perspective: to implement threads (aka goroutines) you need a scheduler, there is no way around it. Without even looking at the implementation I can tell you that the Go scheduler is naive and will be prone to undesired behavior compared to the native kernel scheduler.

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

From the documentation itself: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter.

Let's not pretend that go has some magic concurrency primitive that is anything other than a normal thread launched by the clone syscall.

Oh, but it does - though i wouldn't call it "magic". Don't take my word for it: write a small program spawning, let say, 100000 goroutines. See how many system threads are launched.

From the documentation itself: "They're called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management."

You're mixing up concurrency with parallelism. Rob Pike had a couple of very interesting talks on the matter.

Expanded tabs are a waste of space. The reasonable solution is using tabs for leading indent, and space otherwise. Tabs provide proper semantic meaning for indent, allowing editors to respect user preference.

Fundamentally though, the question shouldn't even need to be considered. Code is necessarily structured and should have a canonical format, enforced by a tool like gofmt, which makes mechanical transformations of code much simpler. The amount of time wasted on formatting, both for writing and reading code is absurd.

I'll even suggest that a free-form text editor is an annoyingly primitive tool for programming. Given a suitable language and a canonical representation of the code, a contextually aware coding environment with full knowledge of the syntax could allow a significantly better development experience.

Go is a programming language designed by Google to help solve Google's problems, and Google has big problems.

I suppose Google could abandon the language, but if they developed it to specifically address problems they were having, then I would expect it to be around for some time.

Is this AI software written in Rust?

Obviously, they used Go to play Go.

(Just kidding, I think it was C++ actually)

dlopen(3) and its friends allows a C developer to dynamically link to symbols at runtime, the ClassLoader.forName() method allows a Java developer to dynamically load classes at runtime, and other languages have similar constructs. Runtime linking is an extremely useful feature for implementing a module system so in-house developers or 3rd parties can create new implementations of well-defined interfaces; Apache HTTPD is a good example of how to use this effectively. Runtime linking has a number of benefits, not the least of which is security: a user (at runtime) can disable large chunks of code to limit the attack surface.

The May 2015 The State Of Go talk addressed this feature in the execmodes document, specifically:

• Go code as a shared library plugin with a Go style API
• Go code that uses a shared library plugin

It states that neither of these are to be available in 1.5 and indeed they do not appear to be. What's your take on runtime linking? Do you consider it a priority and do you think it'll be available in the next release?

These statements come from experiences in other languages with obnoxious GCs. This is a performance-focussed language with great multiprocess primitives. The GC causes far less latency.
https://talks.golang.org/2015/...
Pauses average 1ms and will be halved again next release to 1/2000 of a second which is plenty workable for games & audio mixers
Further, intelligently-written code can massively reduce GC frequency.

A certain high-throughput web service I've built runs GC roughly once per hour (yet services 1000s of concurrent requests). And this is without any serious effort at tuning. This is because (unlike Java, Python, and JS) GC is avoided if possible for stack space (whenever provably-safe) which is freed when it leaves scope. The proving algorithms are improving too.

Embedding

I usually use the following method: https://play.golang.org/p/iF_d... - Attempting to run this will give a compile error. Once you implement MyType.Foo(); it will compile and run successfully.

The only added part is line 10.

There is nothing wrong with C++ exceptions. There are many features in C++ that can make your code difficult to reason about, but this doesn't mean that these features are mistakes. It just means that you don't know the language well enough to safely and readably employ such features.

I can hear your objections now. "But Google bans the use of exceptions in their C++ codebases! Surely they must be a mistake!" This is the same company that brewed up its own language because one of their senior developers basically came out and said that Google's younger developers are too stupid to be trusted with C++.

He's probably right.

Face it. Most "C++ developers" don't actually know C++. They know bits and pieces of C++, and are mystified and spooked by the parts that they don't know, be it templates, exceptions, whatever.

For those of us that have actually bothered to learn the entire language and keep up to date on its development, "mistakes" like exceptions mean that I can write less code with less bugs in less time.

The Go 1.5 release includes preliminary support for shared libraries. You can now build your Go programs to use shared libraries, on x86_64 GNU/Linux. You can also build shared libraries that can be linked into a C/C++ program, on several platforms.

Go has had an FFI for calling into C from the beginning: https://golang.org/cmd/cgo .

Go offers most of these, or has very similar functionality. Many are also in common with other languages.

As for Go, the differences from what you listed above are:

1. Go implements optional types using pointers (and, as with most languages, implements pointers in a much safer way than C).

2. Go's error handling is just as explicit, but does require you explicitly return the error (Go natively supports multiple return values). I'm not sure whether this is good or bad.

3. Go doesn't have tuples explicitly, but the ability to have multiple return values makes them less necessary. It's also possible to define structs inline (It's a little verbose, as you have to specify the type, but it's not too bad).

4. Named parameters are one nice thing that Go lacks.

5. Guard is just syntactical sugar around an if statement. It's nice, I guess, in that it helps to enforce better programming practices, but it's not anything particularly interesting.

6. Swift isn't a particularly fast language, except perhaps compared with Objective-C, which has some truly horrible performance characteristics in places.

They are different languages, with their own benefits and drawbacks, but I just don't see anything here that Swift offers that is all that special (and yes, Go has a playground as well).

Go's big differentiator, for instance, is its support of channels. Channels offer a paradigm for multithreaded processing that is quite different from what other languages offer. Most languages, for example, make use of mutexes to keep concurrent processes safe. Go, on the other hand, implements multithreading as communication: if thread A writes to a channel, and thread B reads from it, thread B will wait until thread A has its value ready. This is the main feature that makes Go so useful for server applications.

Some also appreciate the language's simplicity (the main design philosophy of Go was to make the base language as small as possible while supporting all of the main programming paradigms). One result of this decision is that generic programming can be extremely verbose (you can use interfaces to allow a function to accept anything that implements that interface, and there's a reflection API that lets you do different things with different types passed...it's rather clunky, but functional). Overall, this makes programming in the language rather weird.

Pretty much the only thing that sets Swift apart is the fact that Apple is pushing the language. It does appear to be quite a bit better than Objective-C (which has some truly horrific functionality, such as no type safety for containers and runtime errors for invalid message calls). But I really doubt it will make all that much headway into projects which aren't targeting Apple products. It's good, but I doubt many teams will see a reason to switch.

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

Please file bug reports at http://golang.org/issue .

Several of the main Go developers use Mac OS X every day, so it can't be that bad.

The iota enumerator in Golang is elegant and unique. Writing idiomatic Golang code is so implicit in the language itself that I've been able to easily read almost any Go code I find.

http://golang.org/doc/effectiv...

Python is the right answer (because it's general and popular), but Go should be considered. It's native to web development (big surprise) and it's *clean* in a way that no other language is (very small language with automatic formatting, and won't even compile if there is a single warning.)

That code looks like the bastard child of Dart and Go.

I've long wished we could find crypto libs that were well-engineered, both internally and in their APIs.

Have you looked at the Go standard library's crypto packages? I have not done any thorough examination of them and could NOT vouch for their quality - but they were written by security conscious folks (including Ken Thompson) at GOOG, and the code is fairly easy to read.

I've long wished we could find crypto libs that were well-engineered, both internally and in their APIs.

Have you looked at the Go standard library's crypto packages? I have not done any thorough examination of them and could NOT vouch for their quality - but they were written by security conscious folks (including Ken Thompson) at GOOG, and the code is fairly easy to read.

http://golang.org/

Why CGI interfaces? You don't need to use CGI at all. Perhaps you even shouldn't these days. Also, would this satisfy your criteria?

http://golang.org/ You won't regret it.

Liar.

http://golang.org/doc/effective_go.html#goroutines

We're not pissed with change. We're pissed at reinventing the wheel. Again.

http://golang.org/

go go!

Summing up my recent comment on another story:

Historically C has been irreplaceable for serious system programming, and on the other side of Ousterhout's Dichotomy we had decent scripting languages like Python, Ruby, Tcl, Lua, etc. Now we're seeing the slow emergence of a new generation of languages that are close enough to the power and efficiency of C, and also offer much greater developer productivity and safety: D, Go, Rust, Nimrod, etc.

--libman

If there was a smaller copyfree C compiler available (no C++ / ObjC bs), then it would have been much preferable to LLVM / Clang as part of FreeBSD base. Unfortunately projects like pcc / ack / etc are further behind. Perhaps Open / Net / DragonFly BSD are holding out for those, but FreeBSD needed to ditch gcc ASAP.

C is the system language of the UNIX generation. UNIX uses a very specific modular approach to managing complexity that is much better than OOP. C++ / ObjC add nothing to system programming but useless complexity. They were designed for the very opposite of the UNIX philosophy: huge chaotic app / game projects where dozens of programmers are all stepping on each-other's toes. They might have some virtues when it comes to Web browsers and widget toolkits, but that's not what UNIX is centered on. Languages that aren't particularly distinguished on either side of Ousterhout's Dichotomy (Java, C#, Haskell, etc) are a complete waste of noosphere. Plenty of decent scripting languages are available for people who want productivity (Python, Ruby, Lua, etc), and the small parts of their code that are performance-critical can then be optimized with C to get the best of both worlds.

The supremacy of C as the system language may be challenged someday, but not by C++ or ObjC. It will be a whole new generation of languages, of which D / Go / Rust / Nimrod are very early examples, and the post-POSIX OS'es of the future will be written from scratch in such languages. But UNIX should remain C.

--libman

Learn Go. It's clean, beautiful, and feels to me today like Python felt ten years ago. It's a very young language, and doesn't have the rich set of libraries you'll get with a more mature language. But community support is great, and more importantly, programming in Go is fun. If you're writing web stuff, host it on Heroku and stop worrying about system administration. Make your app 12-Factor compliant, and worry somewhat less about scaling. Play with Neo4j or other graph databases, and start to see the graphs all around you. (But note, there is no working, complete Go library for Neo4j - life can be rough at the edge.)

Most importantly, write what you find fun to write. :)

I'm thinking my next application will use Go for the API, and Ember.js for a fully decoupled client. The client needs to rely 100% on the public API not any special backend magic. Python & Ruby are both good solutions, and have lots of useful libraries; but both have some performance issues, and I'm getting less & less enamored of dynamic typing. Go gives me all the stuff I liked about Python, plus the typesafety and speed I was craving. Ember.. well, I dunno, it looks cool. Javascript is gross tho.

Try Go. It's like Python and C had a child, that turned out to be both strikingly beautiful and a great athlete. I've been writing Python professionally for a long time, and I think there's a good chance Go will completely displace Python for new development in 5 years time.

Android is here to stay and won't move away from Java and Oracle knows that very well

Yeah, it's not like Google has made their own language or uses popular, high level language internally that could replace java.

Since there's already C++ support for those needing the support, python could easily replace new development. Freeze the java API, only release the goodies in the new python API, and watch as java rides off into the sunset wrt new development.

Have you looked at go?

Strong typing, ridiculously fast compiles, garbage collection, python-like maps and slices, and a decent standard library.

http://golang.org/

This is one reason why I love Go, it is more safe than C while it actually removes layers of complexity, it doesn't even depend on libc and its stdlb is extremely clean and lean.

Take a look at type embedding: http://golang.org/doc/effective_go.html#embedding

Go does not provide the typical, type-driven notion of subclassing, but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface.

That's interesting. I can see that they have gone full hog with the composition paradigm and given some innovative ways of implementing it. I will really have to take a look at this.

It seems to me that go is almost the direct opposite of Scala. Scala takes the approach that anything that the compiler can possibly infer it should do, regardless of impact on compile time, whereas go takes the approach of designing the language to facilitate fast compile time. Scala draws from the inheritance model - introducing mixins to give a well-defined multiple inheritance pattern - which can get complex. Go eschews inheritance and goes with composition.

I need to take a good look at go, because I am a Scala fan and want to avoid getting locked in to a single way of thinking.

The syntax is obviously C-inspired, but with some changes, many of which seemed like experimentation -- doing something different just because it's different. Although I don't object to the philosophy, I'd like to see how those changes work out before investing a lot of time into them. In particular, the declaration syntax feels very strange to people who are used to C-style languages.

Perhaps this section of the FAQ might be useful in explaining some of those changes. Another page explaining the declaration syntax in particular can be found here.

The syntax is obviously C-inspired, but with some changes, many of which seemed like experimentation -- doing something different just because it's different. Although I don't object to the philosophy, I'd like to see how those changes work out before investing a lot of time into them. In particular, the declaration syntax feels very strange to people who are used to C-style languages.

Perhaps this section of the FAQ might be useful in explaining some of those changes. Another page explaining the declaration syntax in particular can be found here.

http://golang.org/doc/go_faq.html#Why_is_my_trivial_program_such_a_large_binary

Don't forget vitess, which is a Google project aimed at making MySQL databases scale better, and is used in YouTube. The Thanksgiving Google Doodle was also written in Go, and developed in 24 hours. Google does eat their own dogfood.

Take a look at type embedding: http://golang.org/doc/effective_go.html#embedding

Go does not provide the typical, type-driven notion of subclassing, but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface.