Why I Don't Want to Learn Go
arantaday.com
arantaday.com
One key feature is that the Go compiler itself is the style guide: it automatically reformats your code to remove style guide violations. This makes it easy to work on a codebase the size of Google's because everything looks like it was written by the same person. We try to do the same thing for C++, Java, and Python, but it doesn't work as well because the process is manual.
Similarly, compilation time and runtime for every component, no matter how unimportant, is of utmost importance for Google's codebase. It may not matter how long it takes to run one one-off script, and it may not matter to you how long it takes to compile, but it does matter at Google because we compile every project and run every test after every commit. (OK, builds and tests that are obviously unaffected are skipped. But it's still a lot of code being built and tested.) So your Python project that takes 5 seconds to run tests instead of 1 second ends up wasting decades of CPU time throughout its life time. Same for C++ projects that take many hours to compile. Go tries to be as expressive as Python and run as fast as Java (and compile faster than anything else), and this saves lots of time in aggregate. (Remember, when you break someone's build, the delay between submitting your change and the system knowing about the breakage can result in a lot of hair-pulling for the developers on the project you broke. But if we can know the build is broken before the change is even submitted, then many hours of developer productivity are saved.)
Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go. Google is a special case and just because we have some problem doesn't mean you should have the same problems. One-man shops should optimize for individual efficiency instead of aggregate efficiency like Google does.
They've enforced style by mandating committers hook a linter into a git pre-commit hook, and compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).
I can imagine that not working at Google-scale.
Style-related presubmit hooks are a part of every project at Google. Plus readability requirements, etc - style is kept pretty damn consistent.
> compilation time hasn't been a huge problem since the languages always support incremental/partial compilation (Java/Lisp for the most part).
This is the far more interesting problem to solve at scale with a single centralized repository.
Aren't most serious languages designed for large code bases?
(and compile faster than anything else),
So, why not invest in incremental compilation for an existing language? E.g. the ECJ compiler for Java has done wonders in terms of immediate feedback while developing. clang aims to do the same for C code and slowly makes editors and IDEs more effective.
Anyway, don't take this to mean that you're doing software wrong if you don't see the value of Go.
I fully agree with the author, on the one hand Go does not provide the performance of C or C++, on the other hand it nearly no useful new abstractions to manage complexity. Languages such as Haskell, OCaml, F# or even D provide a better type system and have similar or better performance.
Google is a special case
Out of curiosity: how much is Go used in Google? What percentage of new projects use Go compared to e.g. Java or C++?
Of course it's still a horrible kludge. But the reality is that C++ exists and is widely used ;).
Haskell is definitely interesting. If I wanted to build a large system that was super-performant, I'd look at C, Haskell, and Go. I don't know enough to make a great decision, but all three look good.
Go has the advantage of being designed for the kind of thing Google does - massive concurrency. It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C. I'm not saying Haskell programmers aren't good programmers, but Google probably doesn't have enough of them, and they'd have to port their existing code to a completely different base (bad idea).
The original article complains about Go's GC. For a single process application, this could be murder. I don't think Google uses a single process.
I intentionally said most, since, obviously there are serious domain-specific languages. But stating that Go is designed for large code bases, creates a false dichotomy.
Go has the advantage of being designed for the kind of thing Google does - massive concurrency.
So, claims the C fan since there's GCD, so claims the Erlang/Scala fan since it has actors, so claims the Haskell fan since it has green threads, STM, and purity.
Also, is Google interested in massive concurrency or parallelism?
It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C.
That's a good point. But as a result it provides only a marginally better type system, at the cost of performance compared to C. Why not make it a lot better than C, with the same performance?
It's kind of a domain anti-specific.
I would. I used the gtk-perl bindings for a project and I thought they were very well done. Previously I had only used the C bindings and taking the step to a higher level language (and more importantly, one with closures) was a very nice step. It was a much better experience than doing Cocoa with Objective-C, IMO, but that could have also been related to the specific (smallish) project I was doing.
For many things, GC is a huge productivity boost. I've heard good things about C99, C will probably evolve into a language with a better type system anyway. I don't use C myself, but I don't see why there couldn't be a flag to ensure code only uses a saner subset of the type system.
Maybe the big companies like Google and Facebook are approaching a new meaning of a “large codebase”. They have a huge number of programmers, the development is much more distributed into different locations and time zones, and the release cycles are much smaller than they used to be with large codebases in the past. There’s for example this very interesting discussion about the way these companies use their versioning systems:
https://news.ycombinator.com/item?id=3548824
Some of the practices (like keeping their whole codebase in one big repository) look quite questionable, if not downright stupid from a smaller viewpoint, but make sense in their case. Go could be a similar thing – most serious languages are designed with good modularization, encapsulation and other features that support large scale code bases as most of us know them, but that does not mean these languages are a great match for software at the Google scale.
If codebase is that large, language alone can't solve all the problems. Be it compiling time, testing time, or whatever problems large codebase may have. I guess that's exactly what Steve Yegge tried to say in his famous Platform Rant blog post.
Well, C is basically designed for Version 6 Unix, the Programmer's Workbench http://en.wikipedia.org/wiki/PWB/UNIX and troff, not a very large code base by today's standards.
Unless something changed in the last six months that's not the case, there is a tool called gofmt that will do the reformatting if you call it.
I'm not really sure I see publishing a style guideline in the form of code rather than english text makes any difference, at least it didn't make it for my go code.
I suspect it has more to do with the fact that some of the developers behind go use acme than anything else.
Why the seemingly almost complete lack of love for Pypy from Google then? It's not like you can stop using Python anytime soon even if you keep extending Go. I believe Google's made one tiny donation to Pypy. Given their benchmarks (http://speed.pypy.org/) and given Google has literally tens of billions in hard cash lying around I can't see how you can't get them some money. A few hundred thousand to Pypy would be justifiable on the performance improvement YouTube would experience alone. Sure the motto is "don't be evil" rather than "do good" but this seems like a no-brainer. Can you give reasons why it's not happening?
IIRC, the original research was going to be into making Haskell for .Net, but there were enough issues (in particular, being purely functional makes interop with C# and the existing .Net libraries radically more difficult) that ML seemed like a better fit.
It is. When you launch Visual Studio >= 2010 it's there alongside C# in the Project Creation wizard.
http://msdn.microsoft.com/en-us/vstudio/hh388569
Microsoft also sponsors Haskell and OCaml research via Microsoft Research centers.
Java and C# helped their companies do that.
But with Python,Tcl and Haskell its a little different. Its good for the companies if they off, but if they don't they don't loose anything.
I don't suggest otherwise. It's known that Python is one of Google's three languages approved for internal use (or apparently four now that JS has got a foothold). But I'm sure I've seen reports that people are nonetheless being pushed towards Google's other two officially blessed languages, at least on production code - and in fairness, Google is a place where developer time is often cheaper than the machine time you have to spend to save developer time. But moveover it seems that, even when people in Google do want to fix their Python performance issues by making Python perform better rather than by reducing its use, they tend to want to do it in-house rather than by adopting or supporting other people's work: look at Unladen Swallow. That would be in line with the rather hubristic, command-economy approach - "let's hire all the world's smartest people, then order them to build the future" - that seems to determine Google's actions in general. Hiring GvR fits that pattern too (as well as making plenty of sense).
But I'm sure other people here are much better informed about this than I am.
This creates a dilemma for a lot of people while choosing a technology. If you have to choose a language where you don't want to develop stuff quickly. Then you now have sufficient time to choose a static language and then develop stuff at the speed desired.
For other quick stuff there is Perl anyway.And it doesn't make sense to use Python, which is slow(compared to java), which doesn't give quick development cycle(compared to perl).
If you wish to relevant for a long time, then you have to do at least one thing properly.
(2) Last thing I heard, Google's trying to minimize their Python usage in favor of Java.
But Django and Rails seem to be the major reasons why people continue to use Python.
Having said that no company that is making billions in profits is going to bet their very survival on a framework written and maintained by volunteers. Frameworks come and go, Every 5 years there is something new.
This is a remarkable claim. Well beyond what the most dedicated perl enthusiast could make with a straight face.
Do you have any supporting data or evidence to back it up?
Even in such cases one you infrastructure begins to expand, one you are a reasonably sized team. Perl usage becomes inevitable.
Even among the heavy Python using companies like Google, its becoming clear why anybody would not use Python or even deprecate it in production. Because it doesn't quite really have a strong dedicated niche. Php has the web, Perl has the scripting/glue part on the Unix environment. Java has the static large app part.
Python/Ruby have great web development frameworks.But when it comes to scripting, there are no real alternatives to Perl. And besides if you wish to develop large applications, Static languages serve well. There is no point in using Python when you don't want to cook things quickly.
You will be shocked how many places apart from web communities and forums like these people haven't even heard of Ruby and Python. Most of my friends in big companies some of who also lead big teams over the years 'have just had a look at Python'.
I realize that I have posted this in a community that likes Python a lot and I'm likely to be downvoted. But I'm writing just what I've seen over time.
Regarding your other comments they seem to be way off base and just using your personal bubble/ "what I've seen over time". Ruby and Python have crushed Perl in modern web development (Twitter and Reddit come to mind among many others). Python has vast user communities in research and science (including computer science teaching now, MIT, Stanford). Perl might be before Ruby in the pack behind R/Matlab/Mathmatica/Python in some research settings, but that's not saying much. Python additionally is the chosen admin utility language of Red Hat and Ubuntu for their Linux distributions, so it seems there are real alternatives to Perl.
I'm not saying Perl is bad, I am just saying objectively it's been in decline since the 1990s against its rising competitors in all areas: universities, other research, Linux systems administration, application development and web development.
Still, I assume this is fixable, and it's getting more and more competitive in terms of the megabyte-second cost of computation (i.e. if you use twice as much memory but run four times as fast, that can be OK depending on the circumstances).
If Go is really designed for large code bases, then IDE support for go with code browsing, refactoring, debugging and profiling would be developed in parallel with the Go language itself.
Since Go IDE support go only as far as petty Vim and even pettier Emacs modes, I couldn't call go "made for large codebases".
Use http://astyle.sourceforge.net and add it to your build process and/or commit or push/pull hooks of your source control.
(I am surprised I have to give this tip to anyone on HN!)
However, Python, because space is significant, tends to look fairly similar "in the wild". Add minimum adherence to a style guide and you're pretty close to that goal.
The authors believe that they can make GC a low overhead operation in Go and they believe that it's essential to take memory management out of the hands of the programmer to save programmer effort. Lastly, they say that should you need to you can always work around the GC by doing your own memory management (linked example).
It feels like they are trying to honor Hoare's "premature optimization is the root of all evil" by considering non-GC languages to have optimized the wrong thing.
It's that it's a contradiction of terms to say that you are offering a "systems" language but the language in question has non-optional GC.
Go isn't competing with C and C++, it's competing with Java and C#.
This is exactly why I'm taking a wait & see approach. If it gains enough momentum to develop the kind of tool & library ecosystem Java & C# enjoy I'll learn it but I've wasted enough time chasing dark horse language contenders already.
I don't even have to do that. In my world, I'm free to oscillate between C and Python, depending on the problem being solved. Bonus: One can call the other.
I have no need for mid-tier corporate languages like Java and C# anymore. Go can be a "better" mid-tier language all it wants, I still won't learn it because it doesn't do anything better than Python or C currently do.
I actively avoid using or creating codebases so grossly-huge that you need the "bug-avoidance" and performance of something like Java and C# to the point where Python is no longer practicable.
When you need more "performance" because your codebase is too fat, you've got a bigger problem that can't be solved with a faster runtime.
But what do I know? I'm just a startup kid who ran screaming from the .NET ecosystem.
And often the large codebase finds you, no matter how hard you try to avoid it, and there you start to appreciate some of the design decisions of Java.
>Ruby or Python or C because it's not that much more verbose
I've seen some shocking differences in LOC and comprehensibility between Ruby/Python vs. Java code, even when a concerted effort has been made to avoid the typical sins of Java codebases.
You might just be more patient than I am, or a better Java programmer. I don't know. All I know is that I end up experiencing kidney failure every time I have to interact with Java code.
I don't experience kidney failure, just a sudden urge to scrape my skull against a rough, brick wall. Life is too short for me to spend it dealing with that crap and the community that insists that "Java's not slow", even though it needs gigs and gigs of memory to run (which takes forever to populate and blows your cache), has no shared libraries, no copy-on-write, no memory protection, and no dozens of other things that Unix has had for decades for a reason.
And that using Java is almost impossible without such tools and 'frameworks' doesn't tell you much good about the language itself.
With Go there is little need for such extra stuff, and the tools that exist are very simple and very useful (eg., gofmt, gofix) without being required to make up for deficiencies in the language.
The inherent problem with GC is when you put it into hands of people without that knowledge. Then the GC will save them and reclaim their data, whereas it would otherwise be a space leak and dead program. This means that you will have programs that work, but they will run slowly. GC-fanatics like me say that the program has bad productivity since it spends all its time in the garbage collector.
The advantage of GC though is this: If you know what you are doing, you don't need to manage memory in about 90% of your program. It is often either good enough or way faster than doing it yourself. Both in raw performance and in programmer time. A hint is that most modern parallelizing malloc routines use garbage collection internally to make them run more concurrently and faster :)
For the last 10%, the solution is the same as in any other language. You allocate large chunks of memory and then you handle that memory yourself. The advantage is that you only have to do this for a small part of your program and that means you can build software much faster.
The only place where GC is provably a bad idea is in hard real time systems.
It's tangential, but in my experience coding in Java or any other GC enabled language doesn't mean you can completely ignore the memory management. You still have to watch for leaks, unefficiencies or anything you would have cared for if you managed memory yourself.
Programmers "should" do lots of things, but designing as if they actually do is usually a mistake. (If vehicle passengers behaved appropriately, air bags wouldn't be a good idea.)
It's better to design wrt what programmers actually do or get new programmers.
If anyone wants to prove any shortcoming, than maybe they should come up with a more technical analysis, or at least some sort of benchmarking.
My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world examples to that effect.
If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation
More predictable, very likely. Much faster, this is simply not true. E.g., quotes from an article by Brian Goetz[1]:
The common code path for new Object() in HotSpot 1.4.2 and later is
approximately 10 machine instructions, whereas the best performing
malloc implementations in C require on average between 60 and 100
instructions per call. ... "Garbage collection will never be as efficient
as direct memory management." And, in a way, those statements are right
-- dynamic memory management is not as fast -- it's often considerably faster.
Not true, either. With escape analysis, Hotspot JVM can do stack allocation. The flag of doing escape analysis is actually turned on by default now.
[1] http://www.ibm.com/developerworks/java/library/j-jtp09275/in...
Go's memory management story is basically the same as Java's with the "use escape analysis to place objects on the stack" flag enabled. (To be fair, there is one extra thing that Go provides: the ability to allocate objects inside other objects.)
Go will never replace C/C++ for embedded systems and operating systems. Go will never replace JavaScript in the browser. And Go will never replace Haskell, Lisp, ML, Scheme, etc, for those who have a very deep interest in programming languages themselves.
In essence: Go is not a system-level language (GC) and for problems where performance does not hurt so much there are other alternatives.
To add my personal opinion: I would not consider Go for another reason - I will not invest in a language that is backed by one company. I did this once with Java and I will not hurt myself again. Java's start was fantastic but then came all the business crap like EJBs and tons of frameworks.
You could replace occurrences of GC with malloc, switch the language to C, and it would be just as factual. Basically, what the author is saying is equivalent to, "Real projects have to optimize." Well, yes. This isn't deep. It certainly isn't surprising, and it doesn't strike me as a good reason for not learning a language.
I argue that makes a language with has a GC that you can't avoid (as far as I know, it's impossible to allocate an 'object' off-heap in Go) a fairly poor choice for much system level work.
Which means, if Go is to find a niche, it's got to be at a 'higher-level.' And that requires competing more directly against Java or Python - a much higher bar than trying to be better than C.
> I'm saying that much system level work has to optimize by not using malloc(). I've literally implemented off-heap malloc()/free() in C because malloc() is so untenable.
Anyone who has had to write fast C programs that make a lot of small objects eventually ends up here. You end up incorporating some sort of pool based allocator, which I'm sure you can come up with in Go just as you can in C (or Java, or whatever).
2 - You can rig the game so generational GC beats malloc/free.
3 - It's not a criticism, it's a general principle. One always pays for performance. If your performance requirements are low enough, you can even take out a loan on them, so to speak, by using a more expressive language.
The overlap between problems that I'd like to solve with node.js and go is pretty large and I prefer being able to use a statically typed language with coroutines and multicore support built in.
The libraries are great for server side programming.
Go optimises for both speed and memory usage. Folk who run benchmarks often seem to ignore the latter but given how the cloud is priced, optimising for memory usage can be a big win.
Go's GC is suboptimal at the moment. That said, I suspect that it'll improve pretty quickly. Go benefits from all those lessons learned during the man centuries spent building the Java GC.
I have a naive question: could GC in Go be replaced with something like Apple's Automatic Reference Counting (ARC)? It could be an optional feature backed by inserting real alloc(), retain(), release(), and destroy() calls, so you'd still have full control if you wanted to turn it off.
Go has better integration with C than any other language I've seen.
You surely have lots of free time available.
"Lots of free time" would be dicking around with cryptic STL error messages.
I have nothing against Google, but as a community of web developers our interest lies in diversifying and ensuring that no one gets more powerful than us.
Also looking at the features of Go itself, it seems to me that the languages caters to many needs of Google and not many of us may have those needs.
It is a fair point. If anything it illustrates that Google have mis-marketed the product rather than anything else.
I just want a cleaned/tarted up C. Something that doesn't make the critical mistakes of Go and Obj-C (adding runtime overhead), but adds optional compile and runtime semantics that can be very helpful and powerful.
Some ideas:
No GC. This is NOT negotiable. I'm tired of belabouring that point.
Give me something nicer than the current C bitfield syntax.
Bounds-checked arrays...optionally. Make the distinction very obvious in the code/type-signature.
Higher-order functions, optionally. I don't really want an object system, just the ability to utilize callbacks in perhaps a nicer way than how function pointers currently function. I'd actually be happy with a standardized syntax sugar for function pointers.
Compile-time (only!) duck-typing and polymorphism. This part I think Go got right, but its sins were too great and the problem it was solving too poorly defined to make up for this.
Unicode-native from the ground up.
Clean up the string/array/pointer conflation, adopt the semantics of the bstring library as the default string type for the language, but leave open the door for 'raw-er' string implementations.
Don't reify language types without enabling people to implement their own data structures at the nitty-gritty level.
Cross-OS green-threads might be nice. Let people define their own concurrency models and semantics on top of what the language provides by default though. Same problem as the language type reification, don't delude yourself into thinking you've solved the world's problems with your subset of solutions. Let people use things like ptrheads without punishing them for doing so.
But most profoundly of all:
Make a language that would make writing a library like libev or libevent less bug-ridden and a lot more fun.
P.S. I sincerely hope someone writes a "pragmatist's" systems language like this.
Interesting that you disqualify Objective C? It use reference counting which should have a more predictable memory handling behaviour.
Or is the dynamic stuff too much overhead for you? To me, it looks cheap (but I'm a scripter since quite a few years).
(Not knowledgeable on this; I'm asking, not making an argument.)
Let me try to summarize:
There can be no limitations of any kind in terms of expressing to the machine, precisely how the machine should behave.
Period. No ifs-ands-or-buts about it.
This means you must be able to define memory layout, management, instruction behavior and semantics, and optimally, be able to predict cache locality (arrays vs. linked-lists are the trivial but canonical example)
The moment the programming language, at any fundamental level, precludes me from defining how the machine should behave with respect to memory, semantics, or otherwise...it ceases to be a language that can be used for systems programming.
Disintermediating the meddling of C compilers is hard enough, languages like Go and Java are 'intractable' to say the least for actual systems programming.
Obj-C is only acceptable in the context of systems programming when you stop using everything that makes it Obj-C and just write C code.
I outlined additions/improvements that could be made to C and utilized in the context of systems (rather than applications) programming.
In a single sentence, it's about fundamentally about POWER and not "speed". That's why the desert-island language is C.
Actually it seems you don't understand that people mean different thing by "system's programming".
Not all system programming is about no-compromise, i.e as it would if it was only about driver or OS coding.
I'd trust Ken Thompson and Rob Pike to understand what system programming is better than some random dude on HN.
You'd be surprised, Pike has more or less retracted the "systems" moniker due to the reaction it got. He avoids the term now as a result.
I know this because I've been watching Go itself very closely.
But hey, it's just Rob Pike. Maybe ken still calls it a "systems" language. I'm still just a random dude on HN who thought plan9 was a fantastic idea and keeps track of Pike's work as a result :)
As for your 'what people mean by systems programming', how about you both stick to the definition/description used here:
http://en.wikipedia.org/wiki/System_programming
That would make it much easier to communicate. From the looks of it systems programming is all about no compromise, specifically for the reasons outlined by the GP. Now I wouldn't know him from Adam but even outside the realm of driver and OS programming there is plenty of room for software that is 100% deterministic in terms of time and space consumed.
Note that the 'alternate usage' term in the page linked above was specifically not what the GP was talking about if I understood it correctly.
Most code isn't inner loops in device drivers.
My point was that Obj C's behavior should be more or less deterministic, and method calling reasonably fast?
So "more or less" is just not good enough for you. [Edit: E.g. cache interaction is too hard to reason about when doing lookup for method dispatch, etc?]
Well, I'm too laid back to work on your problems. :-) I decided a long time ago that what I really liked most was to create lots of functionality in as short time as possible. But I admire people that care about things and learn about them relentlessly, so thanks for the information.
That's what I do now, but it's not what I've always done and I'm keenly aware of the limitations my peers are dealing with on a daily basis.
I hear what you're saying but you're overselling C here. Straight up ANSI C has a lot of limitations in telling the machine what to do. Even the various proprietary extensions have limitations right up until you stop writing anything that looks a little bit like C, e.g. you start using "asm" style intrinsics that let you do assembly inline.
http://www.mikeash.com/pyblog/performance-comparisons-of-com...
Read 16-byte file 100000 iterations 2.1s for 100k reads 21219.3ns per read
This appears to be testing... the filesystem cache? It's certainly not seeking on a rotational disk, "SSD" isn't on the page, so... not sure where he's getting 21 microsecond reads from.
Correct reference counting in multi-threaded code running on a multi-core machine adds significant cost to a simple pointer copy (aka "add reference").
An other option you might want to look into is Rust[0], especially since the language is still in its early days (0.1) and the developers are more than willing to fix things which don't work.
* It does not have bit fields or bounds-checked arrays (which it calls vectors) at this point I think
* A bit of GC: it has a reference-counted pointer type, which is task-local, which might be possible not to use at all (not sure) if you don't want it. It also has unique pointers (reclaimed when they vanish out of use) and stack allocation.
* HoF, unicode-native strings (although they're char vectors so maybe not ideal), pointers cleanups (and more than one pointer type which you may or may not agree with), "tasks" ("green processes"), absolutely trivial C interop (so you should be able to easily use pthreads I think), structurally typed records, tuple types, lots of pattern-matching love (for dispatching and unpacking), explicit mutability marker
Rust gets a lot closer than Go, but is still straddling this awkward territory between C and Java.
I would imagine that Rust would be fantastic for implementing a database or a web browser or anything else equally complexity-management and performance driven. The concurrency and safety semantics seem to make that case even stronger for making it an excellent language for a database.
The non-optional runtime overhead that I have to imagine is endemic to the purported feature-set would seem to be a non-starter for systems (kernel, driver, embedded) programming.
Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.
Yeah that's about what I'd expect considering the language's goals.
> Safety is one thing, mandatory safety means a mandatory runtime overhead with a mandatory reduction in control and power over the code which is unacceptable.
Rust has the `unsafe` escape hatch for this, unsafe blocks can do whatever the hell they want and are "unsafe function" and "unsafe pointer" types which are known to bypass Rust's safety mechanism and can only be used in unsafe blocks.
In general I have to work off of their purported goals and priorities to get a feel for where the final destination of the language will be when it's more complete.
If they say they aren't going to prioritize machine semantics, C-level runtime performance, or systems-grade control over code generation then I have assume those priorities will fall wayside to the established priorities of safety and concurrency.
I'm not saying Rust will "fail" like Go seems to be doing so far, I'm just saying I don't think they're going to prioritize making Rust useful for driver development[1].
[1] Which I think is brilliant anyway. It's solving a very hard problem that needs solved.
It's interesting to see that the domain of "systems" programming languages appears to be splitting into "kernel-level" domains and "perfomance-critical application-level" domains. In this light, it seems more like C++ is the one caught straddling the gap. Should be interesting to watch this space for the next decade or so.
I think it's way too early to tell if Go is failing or not; it was announced less than three years ago. How successful was, e.g. , Ruby in '98?
I'd like to see a "runtime-less Rust" myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.
If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help.
(1) Regions, when you want safe, low-overhead allocation. The downside is a more complex type system. (Usually you don't see the complexity unless you're returning pointers that contain references to the stack, at which point you have to convince the typechecker that you aren't creating dangling pointers by doing so.)
(2) Safe, garbage collected heap allocation. This gives you maximum flexibility at the cost of runtime overhead.
(3) Unsafe pointers. This lets you manage your memory manually, like C++. Of course, this is unsafe.
Also, I suspect we're going to add fixed-length vectors; we've been discussing this quite a bit lately and I think there's general consensus that they should be present in the language in some form.
Clay seems to understand that you cannot compromise.
Perhaps I'm cynical, but having had no experience with Clay this statement fills me with dread. Care to elaborate?
Edit: ah, I see elsewhere you've defined what you mean by "no compromises." Still, I'd be interested in hearing what makes Clay the front-runner in this field if you care to tell. :)
I leave it to your Google skills to get the cultural context for that. :)
Clay seems to have a lot of potential in the systems programming space. The language is still in a bit of flux, but it's the first C alternative that still has me excited after using it (which can't be said for C++, D, Go, or Rust).
The folks in #clay on freenode are very friendly and helpful. You can tell that they've been keeping up with advances in PLT but that they also understand the kinds of low-level things systems programmers need to do.
[1]: https://en.wikipedia.org/wiki/Vala_%28programming_language%2... [2]: https://en.wikipedia.org/wiki/Chicken_%28Scheme_implementati...
A lot of the questions re speed bumps on the mailing list are answered with "those are microbenchmarks, what matters is real cases" and generally a "lalala hands in the ears approach", even when it's obvious that the problem is deeper than some microbenchmark only case.
Like this example:
https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
[Downvote? Something very controversial about hashmap O behavior?]
But to compare Go to Python is a bit weird.
Of course, you could do it, but why would you, almost every metric that you'd want to use would be off. You're comparing a compiled language with lightweight threads aimed at just-above-low-level programming backed by a single vendor with an interpreted language that is mostly geared towards single threads of execution with a very high level of expressiveness that is developed by a bunch of open source gurus under the supervision of a benevolent dictator.
Don't get too caught up in the marketing.
Yes, I can imagine that too. But there are also a very large number of problems where either one is a (much) better fit, and it would seem to me that that is the majority of problems, not of the 'toy' variety.
The biggest factor in picking a language for a specific project is (in my opinion) availability of libraries and familiarity with the language by the team. Python scores very high for a large number of people in both those categories but it has been around for a while.
Go is backed by one of the largest software companies on the planet so it stands a chance but google has a bad rep when it comes to cutting off projects in mid stride.
The devil is always in the details with choices like these and without knowing more about a specific problem and the people that you intend to do the work with it is hard to say which one is the better fit beforehand.
The development model (benevolent dictator/backing company) does not have anything to do with the comparison. The license is also orthogonal. Not sure why you are adding those to the table.
The comparison I made is all about runtime behavior re: speed/memory usage here.
And, what I am saying is that despite Go being static and compiled and touted as "very fast", it's slower in a lot of respects to EVEN plain old Python, not to mention Java, which runs circles around it.
I'm not saying one would/should use Python and Go for the same tasks (though many people do, seeings as Go feels a little like a dynamic scripting language thanks to the easy syntax and the nice type system).
I'm saying "Hey, isn't the basic reason for someone to use Go over something like, say, Python, that it's supposed to be faster and with better memory handling? How does that play in practice?".