Usury FAQ (2014) - <AUTHOR> https://zippycatholic.wordpress.com/2014/11/10/usury-faq-or-money-on-the-pill/ <comment><USER2> God bless him. He wrote extensively and very concisely on the topic. He was struck by a car last year and killed. He left behind a wife and many children.</comment>


Kyoukay: a flask inspired framework built with asyncio - <AUTHOR> https://mirai.veriny.tf/en/latest/ <comment><USER2> Tornado[1] is another (stable, mature) async python web framework, if people are curious. This looks really cool though! I think Kyoukay is to Flask as Tornado is to Django.

[1][http://www.tornadoweb.org/en/stable/](http://www.tornadoweb.org/en/stable/)

<comment><USER3> The great thing about Tornado is that's it's been battle-tested in production for years, yet it's compatible with the new asyncio stuff.</comment></comment>


Show HN: Di-ary – a math note-taking app built on Ruby on Rails, React and Redux - <AUTHOR> https://github.com/mkalygin/di-ary <comment><USER2> Very nice! A bit of flickering as you type, though.

<comment><AUTHOR> Thanks! I'm using MathJax for LaTeX support. This is how it processes LaTeX (with flickering). I have no idea how to improve this. Any clues?

I would probably try to prerender Markdown+Latex and update with a small throttling. But I haven't found a way to do this with MathJax.

<comment><USER2> So, my first hypothesis would be to have two divs, one showing the latest result of marked, the other (not visible) showing the current result of marked; in the Typeset callback you could then swap the two divs.

<comment><AUTHOR> This sounds like a two frame buffers in a rendering pipeline, good idea. I'll try to implement this.

</comment></comment></comment></comment><comment><USER3> Awesome! Can't wait to try it out in a few months :)

</comment><comment><USER4> $\pmatrix{1&0\\\ 0&1}$ does not work.

<comment><AUTHOR> Good catch. This works (3 slashes):

$\pmatrix{1&0 \\\\\ 0&1}$

I'll investigate this bug.</comment></comment>


Site for sharing ideas - <AUTHOR>

Is there any website where people can go to and submit the ideas for projects that they like to get developed or will use once developed (not like a freelancer site but just sharing an idea)?  Then developers can browse through what people want to get build and build it for the public.<p>Not a freelance site or job listing. Just idea sharing! <comment><USER2> What is better than HN itself. Post your idea here and check for feedback. This is what i have personally done. I keep track of my ideas in my blog and post them here on HN. If people read it and think it has some potential, they will respond back to it. And it could be your lucky day, and PG himself will give u some inputs (kind of like limited version of virtual office hrs). I do share my ideas with my friends too as some time they give the best of the advice.

<comment><AUTHOR> i am just looking for a list of real world problems experienced by people so we can pick an interesting web project to tackle.

</comment></comment><comment><USER3> Someone posted this a couple months back on HN: <http://captainobvio.us/>

It says to get feedback but if I remember correctly, it was a place for people to just submit ideas as well.

</comment><comment><USER4> <http://moderator.appspot.com/> <http://www.ideascale.com/></comment>


The Mighty Named Pipe - <AUTHOR> http://vincebuffalo.com/2013/08/08/the-mighty-named-pipe.html <comment><USER2> Nice article. Really easy to follow introduction.

I only discovered process substitution a few months ago but it's already become a frequently used tool in my kit.

One thing that I find a little annoying about unix commands sometimes is how hard it can be to google for them. '<()', nope, "command as file argument to other command unix," nope. The first couple of times I tried to use it, I knew it existed but struggled to find any documentation. "Damnit, I know it's something like that, how does it work again?..."

Unless you know to look for "Process Substitution" it can be hard to find information on these things. And that's once you even know these things exist....

Anyone know a good resource I should be using when I find myself in a situation like that?

<comment><USER3> A bit OT but I don't understand why Google doesn't supply a way to do strict searches where everything you input is interpreted literally.

<comment><USER4> They have, I have complained loudly about this[1], never hard anything back (this is SOP I understand), but I have seen improvements last year.

Double quotes around part of a query means make sure this part is actually matched in the index. (I think they still annoy me be including sites that are linked to using this phrase[2], but that is understandable.)

Then there is the "verbatim" setting that you can activate under search tools > "All results" dropdown.

[1]:And the reason they annoyed me was because they would still fuzz my queries despite me doublequoting and choosing verbatim.

[2]: To verify this you could open the cached version and on top of the page you'd see something along the lines of: "the following terms exist only in links pointing to this page."

<comment><USER5> They still ignore any special characters: [https://www.google.com/search?q=%22%3C()%22&tbs=li:1](https://www.google.com/search?q=%22%3C\(\)%22&tbs=li:1)

</comment></comment></comment></comment><comment><USER6> Once you discover <() it's hard not to (ab)use it everywhere :-)

        # avoid temporary files when some program needs two inputs:
        join -e0 -o0,1.1,2.1 -a1 -a2 -j2 -t$'\t' \
          <(sort -k2,2 -t$'\t' freq/forms.${lang}) \
          <(sort -k2,2 -t$'\t' freq/lms.${lang})

        # gawk doesn't care if it's given a regular file or the output fd of some process:
        gawk -v dict=<(munge_dict) -f compound_translate.awk <in.txt

        # prepend a header:
        cat <(echo -e "${word}\t% ${lang}\tsum" | tr [:lower:] [:upper:]) \
            <(coverage ${lang})

<comment><USER7> > # gawk doesn't care if it's given a regular file or the output fd of some > process:

Something wonderful I found out the other day: Bash executes scripts as it parses them, so you can do all kinds of awful things. For starters,

        bash <(yes echo hello)

will have bash execute an infinite script that looks like

        echo hello
        echo hello
        echo hello
        ...

without trying to load the whole thing first.

After that, you can move onto having a script append to itself and whatever other dreadful things you can think of.

<comment><USER6> That's actually one of the things that I really dislike with bash, that it doesn't read the whole script before executing it. I've been bitten by it before, when I write some long-running script, then e.g. write a comment at the top of it as it's running, and then when bash looks for the next command, it's shifted a bit and I get (at best) a syntax error and have to re-run :-(

<comment><USER8> There are several ways to get Bash to read the whole thing before executing.

My preferred method is to write a main() function, and call main "$@" at the very end of the script.

Another trick, useful for shorter scripts, is to just wrap the body of the script in {}, which causes the script to be a giant compound command that is parsed before any of it is executed; instead of a list of commands that is executed as read.

<comment><USER6> Ah, thank you for that. I may just start using these tricks in all my scripts :-)

</comment></comment></comment></comment></comment><comment><USER9> Pipes are probably the original instantiation of dataflow processing (dating back to the 1960s). I gave a tech talk on some of the frameworks: [https://www.youtube.com/watch?v=3oaelUXh7sE](https://www.youtube.com/watch?v=3oaelUXh7sE)

And my company creates a cool dataflow platform - [https://composableanalytics.com](https://composableanalytics.com)

<comment><USER10> [http://doc.cat-v.org/unix/pipes/](http://doc.cat-v.org/unix/pipes/) . And there's a bit more about how pipes came to be in unix here: [http://cm.bell- labs.com/who/dmr/hist.html](http://cm.bell-labs.com/who/dmr/hist.html)

</comment></comment><comment><USER11> Vince Buffalo is author of the best book on bioinformatics: Bioinformatics Data Skills (O'Reilly). It's worth a read for learning unix/bash style data science of any flavour.

Or even if you think you know unix/bash and data there are new and unexpected snippets every few pages that surprise you.

</comment><comment><USER12> In zsh, =(cmd) will create a temporary file, <(cmd) will create a named pipe, and $(cmd) creates a subshell. There are also fancy options that use MULTIOS. For example:

        paste <(cut -f1 file1) <(cut -f3 file2) | tee >(process1) >(process2) >/dev/null

can be re-written as:

        paste <(cut -f1 file1) <(cut -f3 file2) > >(process1) > >(process2)

[http://zsh.sourceforge.net/Doc/Release/Expansion.html#Proces...](http://zsh.sourceforge.net/Doc/Release/Expansion.html#Process- Substitution)

[http://zsh.sourceforge.net/Doc/Release/Redirection.html#Redi...](http://zsh.sourceforge.net/Doc/Release/Redirection.html#Redirection)

</comment><comment><USER13> If you like pipes, then you will love lazy evaluation. It is unfortunate, though, that Unix doesn't support that (operations can block when "writing" only, not when "nobody is reading").

<comment><USER14> If nobody is reading, you will eventually fill the pipe buffer (which is about 4k), and the writing will stop. It's a bigger queue than most of us would expect when compared to generator expressions, but it can and does create back pressure while making reads efficient.

<comment><USER10> *about 4k

64k on linux these days.

</comment></comment></comment><comment><USER15> AFAIK process substitution is a bash-ism (not part of POSIX spec for /bin/sh). I recently had to go with the slightly less wieldy named pipes in a dash environment and put the pipe setup, command execution and teardown in a script.

</comment><comment><USER16> I've used *nix for ~15 years and never used a named pipe or process substitution before. Great to know about!

<comment><USER17> Named pipes have been rare for me, but simple process substitution is every day.

Very often I do something like this in quick succession. Command line editing makes this trivial.

      $ find . -name "*blarg*.cpp"
      # Some output that looks like what I'm looking for.

      # Run the same find again in a process, and grep for something.
      $ grep -i "blooey" $(find . -name "*blarg*.cpp")

      # Yep, those are the files I'm looking for, so dig in.
      # Note the additional -l in grep, and the nested processes.
      $ vim $(grep -il "blooey" $(find . -name "*blarg*.cpp"))

<comment><USER18> That's actually command substitution, not process substitution :)

<comment><USER17> Thanks for the correction. The unix is large and I'm so very small.

</comment></comment></comment></comment><comment><USER19> In fish shell the canonical example is this:

       diff (sort a.txt|psub) (sort b.txt|psub)

The psub command performs the process substitution.

<comment><USER20> It seems like fish shell's ">" process substitution equivalence is not working as well as bash's though

[https://github.com/fish-shell/fish- shell/issues/1786](https://github.com/fish-shell/fish-shell/issues/1786)

</comment></comment><comment><USER21> Does anyone have a working link to Gary Bernhardt's The Unix Chainsaw, as mentioned in the article?

<comment><USER22> That's the kind of video I might have downloaded. At least I hope so. Gonna check my backups.

update 1 : found it, time to upload.

<comment><USER21> Thank you kind sir. Waiting for a link

<comment><USER22> [http://goo.gl/X5jo83](http://goo.gl/X5jo83)

</comment></comment></comment></comment><comment><USER20> How does the > process substitution differ from simply piping the output with | ?

For example (from Wikipedia)

tee >(wc -l >&2) < bigfile | gzip > bigfile.gz

vs

tee < bigfile | wc -l | gzip > bigfile.gz

<comment><USER6> Say that you have a program that splits its output into two files, each given by command line arguments. A normal run would be

        <input.txt munge-data-and-split -o1 out1.txt -o2 out2.txt

but since the output is huge and your disk is old and dying, you want to run xz on it before saving it to disk, so use >():

        <input.txt munge-data-and-split -o1 >(xz - > out1.txt) -o2 >(xz - > out2.txt)

If you want to do several things in there, I recommend defining a function for clarity:

        pp () { sort -k2,3 -t$'\t' | xz - ; }
        <input.txt munge-data-and-split -o1 >(pp > out1.txt) -o2 >(pp > out2.txt)

</comment></comment><comment><USER23> Anybody know of a way to increase the buffer size of pipes? I've experienced cases where piping a really fast program to a slow one caused them both to go slower as the OS pauses first program writing when pipe buffer is full. This seemed to ruin the caching for the first program and caused them both to be slower even though normally pipes are faster as you're not touching disk.

<comment><USER24> Both mbuffer and pv by default contain fairly large in-memory buffers for pipe data, and accept parameters for particularly large buffers.

[http://www.maier-komor.de/mbuffer.html](http://www.maier- komor.de/mbuffer.html) [http://www.ivarch.com/programs/pv.shtml](http://www.ivarch.com/programs/pv.shtml)

<comment><USER23> Thanks - hoping that there was a built in solution but a buffer program makes sense

</comment></comment></comment><comment><USER25> Is this guy a bioinformatician? I think he's a bioinformatician.

Can't be sure if he is a bioinformatician because he never really mentions that he is a bioinformatician.

<comment><USER26> Seems entirely appropriate given his blog post, and others like it on his site as well as the book he wrote, are clearly aimed at people interested in learning bioinformatics.

</comment></comment><comment><USER27> moreutils [1] has some really cool programs for pipe handling.

pee: tee standard input to pipes sponge: soak up standard input and write to a file ts: timestamp standard input vipe: insert a text editor into a pipe

[1] [https://joeyh.name/code/moreutils/](https://joeyh.name/code/moreutils/)

</comment><comment><USER28> i heard somewhere that go follows unix pipe link interfaces.

</comment><comment><USER29> Pipes are very cool and useful, but it's hard for me to understand this common _worship_ of something like that. Yes, it's useful and elegant, but is it really the best thing since Jesus Christ?

<comment><USER29> Wow. I guess that's what I get for not being totally enamoured of Unix.

<comment><USER30> No, that's not why you were down voted. You were down voted because you were condescending to the people who enjoy working with *nix.

<comment><USER29> It really is a question that I've been having for a long time. I didn't just say that to piss people off. I guess that's the risk you run of coming across when you try to insert yourself in a conversation where the other participants have already agreed on a set of shared opinions - this is _great_ \- and you try to question that common assumption/opinion.

I have honestly been questioning my own understanding of _pipe_ , since I've failed to see the significance before; first I thought it was just `a | b` as in "first do a, then b". So then it just seemed like a notational way of composing programs. Then I thought, uh, ok say what? Composing things is the oldest trick in the conceptual book. But then I read more about it and saw that it had this underlying wiring of standard input and output and forking processes that made me realize that I had underestimated it. So, given that, I was wondering if there is even more that I've been missing.

I have for that matter read about named pipes before and tried it out a bit. It's definitely a cool concept.

<comment><USER31> Perhaps try questioning shared opinions without using the word worship?

<comment><USER29> I'll have to admit that that sounded unnecessarily judgy. :)</comment></comment></comment></comment></comment></comment>


An Independent Journalist solves a 2400-year-old Mystery - <AUTHOR> http://www.law.umkc.edu/faculty/projects/ftrials/socrates/ifstoneinterview.html I. F. Stone was an amazing guy. <comment><USER2> Ok, I am fully sold on the new format for Hacker News.

This is a truly enlightening article. I've never liked Plato (I am a big Aristotle fan), and this article shows in a convincing way how Plato used his communicative gifts to "corrupt" the historic record to make Plato's very bad political ideas more palatable to the public. Socrates was killed for repeatedly advocating the violent overthrow of the Athenian Democracy in favor of a brutal oligarchy. Was this punishment warranted? I think so. In the same way that the identical punishment is warranted for those who convince their followers to blow up others.

<comment><AUTHOR> Glad you liked it, although I thought the point I. F. Stone missed was that democracy is a terrible idea (and a dangerous intellectual fad). Progress happens when new ideas contradict established ideas -- it is, in other words, intrinsically undemocratic (Copernicus, Newton, Darwin, and Einstein all spent time as constituencies of one).

<comment><USER2> I would definitely take the Athenian Democracy over the brutal dictatorship. I think Aristotle did a great job of pointing out the problems with a pure democracy, and John Adams did a great job of helping invent the best solution to those problems - a constitutional republic.

But as far as talking about scientific progress in political terms, I guess I don't follow your reasoning there. Apparently, one of the virtues of the Athenian Democracy was free speech, one of the key ingredients enabling great thinkers to thrive.</comment></comment></comment>


Nuclear fusion is 'a question of when, not if' - <AUTHOR> https://www.bbc.com/news/science-environment-50267017 <comment><USER2> How's Lockheed's Skunk Works coming along? They're quietly building their fifth test model of a compact fusion reactor.[1] Using Lockheed's own money. They plan for ignition at the eighth test model. Once every year or two, they issue a quiet press release. "The work we have done today verifies our models and shows that the physics we are talking about – the basis of what we are trying to do – is sound," Jeff Babione, Skunk Works Vice President and General Manager.

[1] [https://www.thedrive.com/the-war-zone/29074/skunk-works- exot...](https://www.thedrive.com/the-war-zone/29074/skunk-works-exotic- fusion-reactor-program-moves-forward-with-larger-more-powerful-design)

<comment><USER3> No one gives it serious credence because linear magnetic mirror configurations were found to be a nonstarter for similar reasons that electrostatic confinement devices are not considered. These aren't arbitrary machines, they have a real research goal. Skunkworks will never get there with their design and anyone who looks at their diagrams can tell you that. They also don't release any design parameters or performance metrics. From the outside it looks like a method to funnel money into someone's pocket.

<comment><USER4> I would agree if it was a typical DOD cost-plus contract, but being self- funded, somebody must have some confidence in the design.

Unless the whole thing is just cover for some other dark money project.

<comment><USER5> Would this fit the bill?

[https://en.m.wikipedia.org/wiki/Lockheed_Martin_SR-72](https://en.m.wikipedia.org/wiki/Lockheed_Martin_SR-72)

</comment></comment></comment></comment><comment><USER6> The more times someone feels the need to tell you a particular technology is inevitable, the more sceptical you should be.

Translation: "we need more money, and will continue to do so for the foreseeable future".

People working on technologies which are truly "when not if" don't go around advertising it - they are too busy trying to be the one to profit off it before the next guy does.

<comment><USER7> I agree. If a technology (especially one as significant as fusion) is viable and the production kinks need to be worked out, then VC-backers are going to dump money into it in an effort to be first-to-market. The less viable a technology currently is, the more governments will be paying for the research.

<comment><USER8> It's not just about viability, it's about complexity and timeline. There's very little appetite for projects with a 30+ year timeline among private investment. You can't expect VC backing for stuff like ITER.

<comment><USER9> That's an odd thing to say. Ever hear of a thing called 30 year bonds?

<comment><USER8> Bond's ain't VC.

</comment></comment></comment></comment></comment><comment><USER10> Also interesting is the Wendelstein 7-X experiment, where they build a stellarator with a unique geometry, compared to the tokamak reactors.

[1] [https://en.wikipedia.org/wiki/Wendelstein_7-X](https://en.wikipedia.org/wiki/Wendelstein_7-X)

<comment><USER11> Can scientists quantify how much of energy efficiency gains can be made from current hypothetically suboptimals tokamak geometry?

<comment><USER3> Tokamaks are different beasts than stellarators. They have a toroidal current induced by a central solenoid (literally a transformer). There are pros and cons to this. For one, you get a lot of ohmic heating and some focusing benefits from the current. However, there are plasma instabilities and there needs to be electrical feedback systems operating with microseconds of latency. This isn't trivial when dealing with huge currents and voltages at high inductance. Additionally the transformer can only induce current in one direction for a finite time (you cannot ramp current to infinity). No one has figured out how to make tokamaks steady state. The best hope is for runs of a few days and 80% uptime. It's undetermined if this is "good enough".

Stellarators have traditionally lagged tokamaks in terms of Lawson criterion performance, but they've also been less funded because tokamaks have performance advantages. Stellarators are steady state and don't risk the same number of plasma instabilities. Germany is so confident that it's the right approach that they built the largest magnetic confinement device ever to test optimizing for quasi-omnigineity. Stellarators in general are becoming closer to the mainstream approach and given another 5 or 10 years you'll likely hear about them as much as tokamaks (at least in terms of non ITER research).

<comment><USER12> >operating with microseconds of latency.

What are the numbers if you know, of the speed or rate at which plasma can destabilize?

<comment><USER3> There is a lot of reading out there on the various types of instabilities, but generally the timescale for these effects are in the microsecond to millisecond range. I think particles move toroidally in the transsonic range, which depends on the temperature (which is a gradient from the core). This would be in the range of 300-1000 m/s in a device with a circumference of a meter or less (for most science machines made so far). I think it only takes a handful or orbits for an instability to grow. It depends on how much abnormal magnetic shear there is. I'm not comfortable saying more.

[https://www.energy.gov/science/fes/articles/zero- tolerance-t...](https://www.energy.gov/science/fes/articles/zero-tolerance- tokamaks-eliminating-small-instabilities-they-become-disruptions)

[http://www.ccfe.ac.uk/assets/Documents/POPVOL17p082509.pdf](http://www.ccfe.ac.uk/assets/Documents/POPVOL17p082509.pdf)

<comment><USER3> I can't edit this post for some reason so I'll just put my correction here.

I attended a presentation today that, at one point, showed toroidal flow rate over radius in a 1m major radius device. It ranged from 30 to 100 km/s. There are many effects operating at different timescales. Turbulence is among the shorter timescales, making it difficult to simulate and why it is only now the current focus of many researchers.

</comment></comment></comment></comment></comment></comment><comment><USER13> Honestly, if the cost of renewables continue to drop and thus make fusion economically unattractive, why the hell bother? Outside of edge cases (such as space flight, inaccessible places, propulsion systems, _& cetera_) it seems that relying on renewables, storage, off-grid/smart-grid solutions sounds economically and environmentally preferable.

<comment><USER11> Do you know any city that have a majority of it's energy that come from renewable? Are there any smart grid that really works, that manage the absence of solar energy the night, the load balancing, etc without just pumping nuclear energy at the moments where solar/etc can't keep up with the electrical demand?

<comment><USER14> There many water dams which feed whole cities

<comment><USER15> Dams are literally terrible in terms of ecological impact. The sooner they are all gone the better.

<comment><USER16> The ecological impact of dams is totally local, but the ecological impact of CO2 is global. If we were to power the entire earth with hydro, the local damage to ecosystems would be a very small price to pay indeed.

<comment><USER17> Also, using a fossil plant is harmful, using a dam is not. The damage was done when it was built.

<comment><USER18> I've seen arguments that some dams where the water level varies a lot produce a lot of GHG's due to decaying plant matter.

But yes, in general compared to fossils it certainly wins.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> Just recently Bloomberg ran a great feature article on the International Thermonuclear Reactor (ITER) in Provence [0].

[0] [https://www.bloomberg.com/features/2019-iter-nuclear- fusion/](https://www.bloomberg.com/features/2019-iter-nuclear-fusion/)

<comment><USER19> CNBC published this great microdoc a few days ago too: [https://www.youtube.com/watch?v=vPS- epGPJmg](https://www.youtube.com/watch?v=vPS-epGPJmg)

</comment></comment><comment><USER20> Some years ago, likely around 2010, I had the priviledge to visit Culham Centre for Fusion Energy (it was called UKAEA Culham back then). During my visit, we were shown around various experiments and after a long evening, we had the opportunity to attend a Q&A with the staff. The question everyone wanted to know the answer to was When will it be ready? The scientists and everyone else involved honestly thought 10 years would be more than enough time for the technology to mature and find its way into everyday lives.

We are not quite there yet.

<comment><USER3> I've heard the argument that it's a matter of money rather than time. The physics is such that a big device is a good choice. Even the compact designs based on high field HTS coils will need to overcome their high power density in the divertor, that hasn't come up much yet but it will. So we want a big device to figure out divertors and breeding and managing instabilities. Great. We'll a just make the one, ITER. Well we're still waiting. If someone with a lot of money wanted it to happen Right Now they could. You just need a 40 billion dollar c(r)ash program.

<comment><USER21> That argument simply assumes money will solve the problems with fusion. There's very good reason to think it won't.

<comment><USER3> And that reason is? I have very good reason to think it will, as do the plasma physicists who work on magnetic confinement.

<comment><USER21> The volumetric power density of fusion reactors is inherently lower than fission reactors, because of the square cube law and the need for the fusion reactor to radiate it's output through the wall of the reactor. This means th e nuclear core of the fusion reactor will be both much larger and much more complex than a fission reactor.

<comment><USER3> Certainly a fusion reactor will be a large, expensive, and complicated device. If it's going to be directly compared to fission solely on cost to generate power then yes fission is less expensive. The allures of fusion is its lack of ability to meltdown, global abundance of fuel, and the ability to choose what elements get activated. That seems like things that add value to me, but I don't think the conversations on funding fusion research are at that level. I've read the transcripts of the US House Subcommittee on Science, Space, and Technology's discussions on fusion energy science. It's clear that the politicians that represent fusion scientists when the budget is made don't have a strong grasp of what the devices are, their potential impact, the realistic failure modes for these projects, etc. It's simply a game of politics.

<comment><USER21> You are repeating the hoary old argument for fusion. That argument depended on it competing only against fission, and making grand nebulous claims that environmental and safety credits would let it pull ahead, even though it was otherwise more expendive than fission.

But fission has now lost to renewables, which are now at a levelized cost 3-4x lower than fission. Fusion's putative safety/env benefits mean nothing now.

The program now is existing on institutional inertia. I don't see this coming to anything but an inglorious end.

<comment><USER22> Wind/solar aren't _that_ cheap if you include enough storage to get through a windless night, and enough overcapacity to get through cloudy winter weeks.

If you're backing them up with fossil, then sure, they're pretty darn cheap.

<comment><USER21> You back them up with short term storage and hydrogen. With plausible costs for 2030 a CO2-free grid optimizes to 0% nuclear.

<comment><USER22> How about today's costs? After all, presumably you're using today's cost for nuclear.

It's plausible that, for example, some molten salt reactors currently under development will be a lot cheaper than light water reactors, so it doesn't make sense to compare future renewables with nuclear today.

<comment><USER21> No molten salt reactor could be available by 2030. Simply resolving material issues would take at least that long. Proving materials will last X years takes at least X years.

More importantly, the decision whether to build such a reactor will depend on decline in costs of its competition in the future, not just now, when the business case for the reactor requires it operate for 40 years or more.

<comment><USER22> There are several ways to fix the materials issue, pursued by active projects. One is simply to replace the reactor core every few years; Terrestrial Energy and Thorcon are using that approach.

So I'll ask again: how do the numbers look if you compare today's wind/solar/storage costs without fossil backup to today's nuclear costs? We can argue until our fingers wear out about what the costs will be in eleven years, but there are hard numbers for today.

<comment><USER21> If they replace the entire core every few years the economics will suck. If they replace every, say, 7 years, then this will take long enough to demonstrate that commercial operation will be at 2030 or beyond.

Insisting on looking at today's solar and wind numbers ? Ok, then I also insist we stick with the numbers for currently available nuclear reactors. You wouldn't want to hypocritically allow only projections of future nuclear, right?

<comment><USER22> Yes, I mean today's nuclear. But for solar/wind I mean what I said above: enough storage for a windless night and enough overcapacity for cloudy winter weeks, so it's the cost to actually run a grid on wind/solar/storage alone.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> £200m from the UK government to deliver fusion by 2040 looks like a joke. It's a drop of water.

<comment><USER24> Why? I know people always mention billions of investment "until we have fusion". But those things cannot be reliably predicted, guesses are all pretty wild.

In terms of human working time, £200M roughly pays for 1000 person years of work, so it's certainly more than "a drop of water". Yes, I know there's more than salaries and research tools and material are expensive in this case. But still, imagine 50 people just working on theory and cheap experiments for 20 years; they could achieve a lot.

<comment><USER25> Building a conventional fission plant can easily cost $10B: [https://thebulletin.org/2019/06/why-nuclear-power-plants- cos...](https://thebulletin.org/2019/06/why-nuclear-power-plants-cost-so-much- and-what-can-be-done-about-it/)

$200M is laughable - as is the 20 year plan. I recently reread Summa Technologicae by Stanislaw Lem. Written in 1961, it also guessed that fusion will be there 20 years in the future - meaning 1981 :)

<comment><USER26> Hopefully this means that we'll never achieve nuclear fusion in a practical way. As far as I can understand this will practically create energy at close- to-nothing prices, which while it will certainly solve some of our today's issues (burning fossils is quite bad) at the same time it will also create a lot other bigger issues. For example, if you make it energy-free (i.e. price- free) to cut trees and build highways wherever you want I'm pretty sure the Amazon rain-forest will disappear a lot faster compared to what's happening now.

<comment><USER21> No, fusion will not create energy at "close to nothing" prices. It promises to be extremely costly, actually.

<comment><USER26> Great, then it won't happen (probably I had mistaken it with something else). Everything that makes energy less expensive and/or more easily available creates lots and lots of bad externalities. It's time we stop believing that technology and technologic advancement will take us out of this mess, it is technology that threw us under the bus in the first place.

</comment></comment></comment></comment></comment></comment><comment><USER27> There's of course not only the question if fusion works, but also how expensive it will be.

A not unlikely outcome would be that at some point humanity is able to build fusion plants, but almost nobody will do, because they're just too expensive. Given the extremely declining price of wind and solar which shows no sign of stopping this seems rather plausible.

<comment><USER28> Wind and solar could be _free_ and we would still have currently unsolved problems of either storage or clean peaking capacity.

<comment><USER29> If they were free, then efficiency in the storage would become a non-issue.

<comment><USER28> Storage efficiency is already a non-issue in the sense that we still don't have any real plan to build anywhere near enough of it to enable a pure solar/wind grid.

<comment><USER29> Step 1: turn carbon dioxide into fuel

Step 2: burn said fuel for power, when needed

Step 3: profit

</comment></comment></comment></comment></comment><comment><USER30> But still a question of if it will make financial sense. Assuming this generates heat and drives a steam turbine, solar, wind and battery is likely to be cheaper than just the steam turbine and the transmission costs, never mind the fusion bit.

<comment><USER31> Fusion has the same advantages as fission but the disadvantages are reduced to a minuscule amount.

CO2-neutral, stable energy generation independent of weather, season, time... with amounts large and stable enough to be independent of storage solution.

Wind and solar need to be regulated because intensity varies. They are location dependent (German North produces a lot of wind, but there's no feasible way to bring it to the South...)

<comment><USER21> The biggest disadvantage of fission is its cost and complexity. Fusion makes these primary problems much worse.

<comment><USER32> I disagree. The biggest (technical) disadvantage of fission is the creation and use of radioactive materials.

Fusion solves this problem in large part because it uses and produces significantly less radioactive materials... materials that wouldn't count as a security concern.

<comment><USER33> Fusion reactors turn themselves into radioactive waste. Neutron radiation is inherent to nuclear fusion and when previously stable non-radioactive substances are subjected to neutron radiation, they may absorb some of those neutrons and become radioactive. (This is called neutron activation.) Some materials are less prone to this than others and that would be considered during the construction of a production fusion reactor, but even so components of the reactor would likely become so radioactive that the only way to perform maintenance on the reactor would be robotics. And when the reactor eventually needs to be decommissioned, it needs to be treated accordingly.

<comment><USER34> I wasn't aware of these issues. Did some searching and found this article that covers them (and others) in detail: [https://thebulletin.org/2017/04/fusion- reactors-not-what-the...](https://thebulletin.org/2017/04/fusion-reactors-not- what-theyre-cracked-up-to-be/)

<comment><USER35> This talk from the MIT fusion lab lays out some approaches they have for solving problems in current fusion reactor design, in particular dealing with the radiation problem in a cost-effective manner. [https://youtu.be/KkpqA8yG9T4](https://youtu.be/KkpqA8yG9T4)

<comment><USER21> The ARC reactor is still unacceptably large and expensive. Its volumetric power density is still a factor of 40 worse than a PWR primary reactor vessel.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> If nuclear fusion can be >= lucrative than nuclear fission is an open scientific question.

Indeed all solar panels on earth are just capturing byproducts of a fusion reactor that is the sun. But a fusion reactor at the scale of ITER is not proved to be lucrative even in an ideal world. I would have hoped that modern physics would allow to predict with great accuracy how energy efficient would an ITER-like be in an ideal world where all enginering issues would be solved. Maybe the proof exist and I'm just anaware of it.

</comment><comment><USER36> Once it gets there, it's going to shift to a matter of "how expensive". On paper, it should be possible to get the cost down but that's many billions/trillions worth of investment down the line. Meanwhile the amount of money already planned to be invested in wind and solar is ranging into the trillions for the next few decades; and most of that is with a clear intention to get a decent ROI too.

If fusion becomes commercially viable, it will be well after we've gotten rid of fossil fuels. IMHO this will be somewhere deep into the second half of this century at the earliest. I might live to see that day but it's going to require some medical breakthroughs to increase longevity way beyond the current averages.

Realistically, existing fossil fuel based energy production is already at a cost disadvantage relative to newly built solar/wind + battery. That gap seems to be widening through ongoing innovation and also simply economies of scale. I doubt there will be a lot of fossil fuel based production surviving the next 2-3 decades because of this. At some point it will shift from being uncomfortably expensive to "this is just plain indefensibly/ludicrously more expensive; lets stop doing this yesterday". I mean, why would you pay 10-20x the nominal price of a kwh just to keep some ancient gas plant going.

The only natural brake on decommissioning this stuff is short term supply constraints for batteries, wind turbines, solar panels, and the associated support industry. Yes, it's cheaper but buying enough of it for everyone is just not possible even if you have the cash on hand until production capacity ramps up which may take a decade or two. We're currently deploying many Gwhs but we'll need many Twhs. That's 3 orders of magnitude difference. We'll get there, and when we do, prices will be a fraction of what they are today. But it will take time.

That in a nutshell is also the challenge for fusion. First we'll need to make it work and then we need to make it insanely cheap. Like fractions of a $ct/kwh. That's also the problem for new nuclear/gas plants. It does not make sense to plan based on current energy prices because they are going to drop by orders of magnitudes.

</comment><comment><USER37> I don't begrudge the research, which I think will yield infinitely more benefit than the goal.

But it's necessarily the wrong kind of fusion (D-T, unlike the sun's fusion), and it won't be efficient, or clean, or cheap even when it "works".

The whole endeavor is pie-in-the-sky if you ask me, which reminds me, there is already a fusion reactor quite nearby that runs 24/7/365(.25), for the next few billion years. We should find better ways to harness it.

<comment><USER3> Do you have any support to the claim that nucleosynthesis is preferred to D-T other than nature shows it working in the high gravity regime? Also do you have any support for the claims of inefficiency or cleanliness? Activated neutron wall materials have half lives in the ranges of days to 15 years, making storage less of an issue.

<comment><USER37> high energy neutrons

will the walls be replaced daily?

<comment><USER3> No. That is why tungsten is the first wall material. High melting point, structurally strong in high neutron flux, and low activation.

</comment></comment></comment></comment><comment><USER38> If the practical fusion was possible, it would have been achieved by mid-1960s. (It's not like Internet, iPhone, or even AMD Epyc would make any difference.)

<comment><USER39> Improved computer modeling and materials science (high-temp superconductors, better confinement vessels) are certainly helping us get closer to break-even fusion.

Practical quantum-computing is being achieved, but wasn't even dreamed of until the 80s. Have we not advanced in our understanding and scientific capability since the 60s?

</comment></comment><comment><USER11> As a reader what I really want to learn is the list of technical reasons why nuclear fusion / ITER isn't yet working. I would like to see something like a github.com repository where issues would be technical issues. And I could follow technical discussions on the issues showing progress or absence of it.

It would really help to quantify how far we are from lucrative nuclear fusion.

<comment><USER40> The physics of fusion are well-understood. Nuclear fusion was achieved before nuclear fission. The most common nuclear fusion reaction--the deuterium- tritium reaction--can be readily performed by research groups across the world.

As others have mentioned, funding is the main reason why energy production from nuclear fusion hasn't taken off. The better question is, what isn't being funded?

Ask yourself: how do you hold the sun in a bottle? The answer is that it's very hard, but it's doable. You just need to cool the walls fast enough and make sure the sun doesn't melt the bottle.

Based off this rough problem description, the main issues are the following:

\- Materials: what do you make the bottle out of? Do you know of any materials which can withstand millions of degrees of heat? Probably not, so you should look into using magnets to suspend the sun in the middle of the bottle.

\- Confinement: how do you hold the sun? The sun (that is, plasma) reacts to magnetic fields. Classical designs such as the tokamak drove the plasma around a donut to keep it confined. Problem there is that you need two magnetic fields: one to drive and one to steer. Some decades ago, people got smart and figured out you could design the road in such a way that the car will always drive straight, so great, you don't need to steer anymore. (This is the main difference between ITER and Wendelstein 7-X; personally, I think ITER will turn out poorly, but they'll learn a lot from building the thing...)

\- Reactions: guess what? Your sun emits high-energy neutrons, making the bottle radioactive. You could use a different type of sun, but those are expensive and weird or would require you to go to the Moon, which is also expensive. You figure out you can line the walls of the reactor with lithium and breed fuel for your sun, which works but isn't perfect. You know other suns are out there, but no one knows how to build a bottle to hold that sun.

\- Self-sustainment: you put some ingredients in your bottle, shake it up, and presto, you have a sun. For about ten milliseconds. Problem is, your bottle got too hot and your reaction creates exhaust you have to scrape out. Also, the magnets used to keep the sun in the middle of the bottle draw more energy than your sun makes! That won't do.

Self-sustaining fusion reactors are very hard problems to crack because there's so many moving parts. The fusion research community has suffered from underfunding for decades because people wrongfully associate the principles of Chernobyl with ITER. People don't want their politicians funding more Chernobyls, and Bob's your uncle. Because the funding has been so low, the problems which should be solved by now, well, haven't been.

</comment></comment><comment><USER21> When they give up, not if.

Fusion's economic prospects are horrific, even if it can be made to "work", and this has been known for a long time.

</comment><comment><USER41> Nuclear Fusion has a really interesting history. There's a good book called A Piece of the Sun I highly recommend to anyone interested in the subject. I was surprised on just how much money has been spent by so many countries on research, how different designs have evolved and just how much politics has influenced its development.

<comment><USER3> What was the number they stated? I've heard "60 billion USD" before, which was spent by many countries over 60 years. In reality this seems like a small cost compared to something like the Manhattan Project, which was 23 billion USD spent over 5 years by one country.

A 25 year availability of a GWe plant (the conventional first gen plants that have the fewest engineering hurdles remaining) that sells all electricity it makes generates 22 billion USD in revenue.

<comment><USER42> $60 billion USD is probably less than my home city of Houston has spent on freeways. There was recently talk of a $7 billion plan to widen I-45 north because people who want to live nowhere near Houston want to get here slightly faster for work.

</comment></comment></comment><comment><USER43> I'm in the process of acquiring a facility in which to build my prototype fusion reactor. If all goes well, I'll start working on it at the beginning of 2020, and hopefully start testing it within a year.

</comment><comment><USER44> If we ever get unlimited cheap power we will just use it to dump vastly more waste heat into the atmosphere. Discuss.

<comment><USER45> We have a ways to go before it would be much of a concern.

Solar heating is on the order of 5000 times our current energy utilization (there's a similar amount of cooling).

Which isn't to say it can never be a problem, just that we are a blip right now as far as direct heat added to the Earth's energy budget.

<comment><USER46> > Solar heating is on the order of 5000 times our current energy utilization

From another comment: "Mankind's waste heat (~10^12 W) is utterly miniscule compared to sun's energy delivered to earth (~10^17 W)".

5000 smells bad — imagine that power output concentrated in cites or production areas — that would be severely noticeable.

<comment><USER45> I don't understand what you mean by "smells bad"?

</comment></comment></comment></comment><comment><USER47> So who makes money off of pushing the idea of Fusion Real Soon Now, besides science writers with looming deadlines?

<comment><USER48> Fusion Real Soon Now would mean that we wouldn't need to change our lifestyles to stop global warming. So, the list of those who would, if not make, at least not lose money is nearly infinite.

<comment><USER49> Battery tech needs to improve as well for you to run a car off of fusion at a total effective cost that is cheaper than fossil fuels.

</comment></comment></comment><comment><USER44> It always was.

</comment><comment><USER50> Imagine a world where everyone's house is supplied with free, practically limitless, cheap energy! We could start heating our homes better, finally put to the end worries about whether we left the iron turned on, power more sources of light! Hm, but wait...

<comment><USER51> Fusion will never make energy "free". Currently fuel only takes up about a third of the cost of electricity, the remaining two thirds spread between the cost of maintaining a grid, and running/building a power station.

So best case you will save about 30% on your bill. A fusion power station is probably going to be more expensive however, so you will be more likely to save less than 30% on bills.

</comment></comment><comment><USER52> I thought the matter was settled. Nuclear fusion is 50 years away. Always has been, always will be.

</comment><comment><USER53> 50 years away as usual.

</comment><comment><USER54> [https://youtu.be/L0KuAx1COEk](https://youtu.be/L0KuAx1COEk)

MIT's Pathway to Fusion Energy - Zach Hartwig

tl;dr: it's a matter of funding

<comment><USER21> ARC, the design that would require 40% of the world's annual production of beryllium to make a single 500 MW(th) reactor.

<comment><USER55> > Total world reserves of beryllium ore are greater than 400,000 tonnes.[27]

[https://en.wikipedia.org/wiki/Beryllium](https://en.wikipedia.org/wiki/Beryllium)

Seems like there's just not enough demand yet.

<comment><USER21> Total world estimated Be resource would make ARC reactors capable of supplying just 1% of current world primary energy demand (using the USGS estimate of 100,000 tonnes.)

</comment></comment></comment></comment><comment><USER49> I think the scenario of complete global warming and running out of oil will play out before nuclear fusion. Realistically.

</comment><comment><USER56> The answer is always "30 years away"

<comment><AUTHOR> Looking through the history of technology the same could have been said at one time for the automobile, aviation, genetic engineering, etc. The timescale during which nuclear fusion has been pursued is relatively short and declaring it a dead end at this early stage is premature.

<comment><USER21> It was also said about innumerable technologies that went on to fail. Focusing just on those success stories is survivorship bias.

</comment></comment></comment><comment><USER57> You know it's not too far out because Saudis are selling shares in their oil wealth. When this stuff actually starts to work, the impact on the world economy will be insane. I suspect this is why it's not being adequately funded: nobody in power wants to flip over the massive fossil fuel apple cart.

<comment><USER21> That's not because of fusion, though.

</comment></comment><comment><USER58> Its also not an option. Renewables wont hold up to scaled demand and nuclear fission is demonized, there is no other viable technological path.

<comment><USER59> You know, we could instead revisit the concept we have of growth. Instead of growing for the sake of it, like a tumor, we could define what kind of growth we want and in what direction, and see if it's compatible with our resources. Do we really need growth or do we need happiness? Once we scientifically solved major health issues does it really make sense to keep growing indefinitely? Couldn't we just put a limit to our population and enjoy our fully automated utopia?

<comment><USER60> > we could instead revisit the concept we have of growth

You say 'we' like humanity wasn't 7 billions or so completely autonomous actors.

This would be a more accurate sentence: '7 billions autonomous actors could decide to act as one, and the act could be lowering its growth rate'.

You see, it simply won't happen.

<comment><USER59> First of all, it's not 7 billions sentients but rather a handful of government. Furthermore, humanity at the moment already agrees blindly that the only way forward is reckless growth, if we all managed to agree on something without even knowing why, perhaps we can also agree on something more rational.

<comment><USER60> > rather a handful of government.

Which are mostly democracies, or sort of. China, Russia and North Korea apart, every big population center is governed in a way or another threw a certain form of consensus.

> humanity at the moment already agrees blindly that the only way forward is > reckless growth

Again you talk as if humans were a single body. You're not agreeing blindly on 'reckless growth', as far as I can tell, and you're far from being alone in that case.

Humanity speaking and thinking as one is just a dream (you're free to dream, thought!).

</comment></comment></comment></comment></comment><comment><USER61> If only we would have spent $6 billion on nuclear energy research rather than on the Large Hadron Collider.

</comment><comment><USER62> I'm pessimistic this will ever be able to work. Doesn't fusion require tremendous pressure that's equivalent to the Sun's gravity? How on Earth are we going to be able to generate such a pressure?

<comment><USER63> Not a nuclear physicist, but IIRC sustainable fusion requires three factors: time, pressure, temperature. So far, you can basically choose two of them at a time, and much research goes into having all three at the same time.

Needless to say, but it also requires loooooots of related research, eg materials to handle the magnetic flux, temperature, etc etc etc.

<comment><USER37> I think we can only really do 1 of them, temperature.

Pressures are no-where near the core of the sun (300 _billion_ bar), nor are confinement times ( _years_ ).

Which is why we use D-T fusion, which is not at all the same as the "clean, natural hydrogen fusion" in the sun. That whole "clean energy, like the sun" argument is fake.

</comment></comment></comment><comment><USER64> There is absolutely no reason to think this is true. The sun has the approximate energy density of a dung hill. The idea that nature will cooperate and make break even possible at convenient human scales is ... optimistic. There's basically zero evidence for it.

<comment><USER22> I'm sorry but that's ridiculous. The sun uses a different fusion reaction. There is plenty of evidence that with other fuels, net power from fusion is feasible on Earth.

In particular, the D-T reaction is especially easy, and tokamaks have well- known scaling laws. The JET reactor in the UK is the only reactor using tritium and has produced 67% of its input power. In 1999 the JT-60 in Japan achieved results with D-D fuel that would have hit breakeven with D-T.

With a larger reactor, stronger magnetic fields, and D-T fuel, net power is the expected result.

(Not to mention, we've already achieved net power at human scales with thermonuclear bombs, which have far more energy density than a dung hill.)

<comment><USER37> indeed but D-T is not at all "clean" fusion "like the sun", as is being claimed for terrestrial fusion.

<comment><USER22> It's not all that bad though. The troublesome waste from fission is the end products of the nuclear reactions. With D-T fusion that's just helium.

You do have high-energy neutron radiation, but most of that you're capturing to breed tritium fuel from lithium. Some of it makes reactor parts radioactive, but that's not a major waste problem; according to presentations I've seen from MIT fusion scientists, they'd stop being significantly radioactive after a few decades.

<comment><USER37> in practice it will not be so neat. I suspect it will be as polluting as fission, perhaps worse, as the contamination will be in the superstructure, not the waste. And less efficient, and even more expensive.

<comment><USER22> Whether it will be neat depends on the reactor design. MIT's for example 3D-prints the inner core and replaces it annually; it's surrounded by molten salt with a lot of lithium, and everything around that hinges so it can be opened up easily. Regardless, the waste won't need long-term containment.

The economics of fusion reactors will also depend on the design. Some look economically feasible, others not so much. But it's clear that fusion is _possible_ , contrary to the comment above.

<comment><USER37> possible, absolutely.

but for sure no panacea.</comment></comment></comment></comment></comment></comment></comment>


Swift and Go: Building a Fast Future - <AUTHOR> http://axioms.io/zen/2014-11-06-swift-go/ <comment><USER2> As much as I dislike that most of the "language shootout" benchmarks are mostly numeric wanking, the binary tree benchmark actually makes, uses and disposes of quite a few data structures, and seems more like a real application program to me.

Go isn't yet faster than Java, but it is closing the gap, at least on multi- core: [http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=binarytrees&lang=all&data=u32q)

Single core doesn't fare so well (Go vs Java), though: [http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=all&data=u32)

Perhaps the authors should have used Rust, or Ada, rather than Go? Hell, on a single CPU machine, FreePascal seems to do better than Go :-)

Actually, from a "performance, w/out turning off all the safeties" standpoint, it really looks like Rust is owning that space.

Now I gotta learn Rust... :-)

<comment><USER3> Rust looks great but hasn't shipped yet. Go is production quality and it's being used in some large projects at Google and elsewhere.

[http://blog.golang.org/4years](http://blog.golang.org/4years) \- From Nov 2013

No, the Go optimizing isn't great. This will be addressed after the compiler is completely rewritten from C to Go. The Go community is growing too, which is probably more important than how well you do on a micro benchmark.

<comment><USER4> I don't understand how writing the Go compiler from scratch in Go is going to make it better than super-mature compilers. Wouldn't it better to leverage Clang/LLVM? Redoing all the optimizations by rewriting the whole compiler in Go seems like it will significantly delay performance parity.

<comment><USER5> For what it's worth, the go team's plan is to automatically translate the compiler to go, not to rewrite it from scratch:

[http://talks.golang.org/2014/c2go.slide#18](http://talks.golang.org/2014/c2go.slide#18)

And, the gccgo compiler does leverage gcc, assuming that counts as a mature compiler:

[http://blog.golang.org/gccgo-in-gcc-471](http://blog.golang.org/gccgo-in- gcc-471)

. Neither of these contradict your implicit point of "they chose to invest time in this port instead of trying to maximize performance ASAP", but you still might want to know.

<comment><USER4> Seems weird to fork a compiler like gcc or clang via transpilation, because you split the community. It may be faster to iterate on Go, but will all of the compiler contributors on GCC or Clang/LLVM want to switch to editing the go version?

It seems you'd lose out on picking up improvements from the main compiler branch and have to keep transpiling and gardening in patches. Plus upstreaming improvements would also be irritating.

I'd think a Go frontend to LLVM would be optimal in terms of productivity.

<comment><USER6> The go compiler is based on the plan9 c compiler, not gcc. I'm not quite sure what the story is with gccgo (who initiated it, why) - but i think it was for interfacing with c on non-plan9 architectures, and not really about leveraging gcc optimizations.

<comment><USER7> gccgo was written by a gcc developer for the purpose of trying out new ways to write a frontend, but also to use all the various things gcc has.

[https://blog.golang.org/gccgo-in-gcc-471](https://blog.golang.org/gccgo-in- gcc-471)

The Go developers have claimed LLVM was not useful because it's too slow, which is why they used the plan9 compiler style.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Just trying go for some real project, and frankly i wouldn't use it for anything else but network-related middleware ( or low level services), which is what i'm using it for, and almost every tutorial i've read about this language mentions.

As long as you're building something very technical, everything's fine. But once you go out of this path, you can see the walls getting dangerously closer. For example, i was surprised to see how many runtime errors i got while coding, for a statically typed language. Surprised as well to see that error checking made me wish for a goto statement again ( what's the pattern for handlings all errors in a block with the same code ? Please tell me..) Then i started to code against a sql db, and boy did it bring me old memories back. Manual transaction scope handling ( annotation where are thou ?), manually counting bound variables in a statement, finding mismatched types between nullable ones and regular ones.... What a mess...

Now it _may_ only be a matter of waiting for advanced librairies to mature, but somehow i doubt it.

<comment><USER9> Go does have a goto statement, and one of its good uses is to transfer to an error handling block (from what I've seen).

There are also type annotations (tags), though I don't know how/if they relate to sql

</comment></comment><comment><USER10> > I'm pretty darned sure that Rob Pike (creator of Go) and Chris Lattner > (creator of Swift) know a few things about computer languages that the rest > of us haven't sussed out yet. If these guys think the world needs a new > language, it's worth finding out why. (And if you do know more about > programming languages than these two? Well, it's honor to have you reading > my article, Mr. Wall!)

Larry Wall is the _ne plus ultra_ of programming language design. This is satire, right? Please tell me this is satire.

<comment><USER11> Is that not the point of his remark? As I understand him, he's implying that Larry Wall is the only one who knows more about language design than Rob Pike and Chris Lattner. Therefore, we should listen to Rob and Chris.

Or maybe it's your comment I'm misunderstanding?

Edit: Ah. It's been pointed out that perhaps your own remark about Larry Wall was intended as sarcasm (or, equivalently, was intended as a paraphrasing of the quote above it). So it's probably the latter.

<comment><USER12> He's disagreeing about Larry Wall.

</comment></comment></comment><comment><USER13> > _By now, you may be asking yourself why we would choose to use such nascent > languages in a production environment._

No, we realy are not. If anything, both are quite safe bets.

Swift had been in secret development for years and came out almost fully formed (as far as languages go), with a full API, tooling, documentation, etc. Besides it's the Apple blessed way to do things on iOS going forward.

As for Go, everybody and its dog are using it for production, left and right. Including very big names. It's pretty much a given that the language is already production-proven, and will do well in the future.

<comment><USER14> >>Full API, tooling, documentation, etc. Besides it's the Apple blessed way to do things on iOS going forward.

Full API? I believe apart from xcode, there are no developer tools or no examples of parser API. Am I missing something?

<comment><USER13> By "full API" I mean the Cocoa libraries it ties to, not some API for messing with the language (AST stuff etc).

As for developer tools, they have an IDE, a compiler, a debugger, a UI designer, the "code playground" thing, etc. That most of those are (also) embedded in XCode doesn't change much.

</comment></comment></comment><comment><USER15> Yes! Two modern languages that are 1) statically typed and 2) statically compiled. At least some people still get it that "modern" and "nice to use" does not implies scripting-like dynamically-fancy typed language "à la" PHP/Python/Javascript/... And the author did not mention Playground for Swift which is just incredibly useful to start experimenting with the language! (Edit: of course Rust is another one as well, but I was in the context of the article)

<comment><USER16> you know what they say about Go being modern right?

<comment><USER15> please, enlighten me :)

<comment><USER17> For better or worse, Go's design is anything but modern.

It lacks things such as immutability and generics. It also perpetuates the mistake of including a run-time type error, null (nil).

<comment><USER15> Note that modern does not mean perfect. I'm not sure you answer could not fall into the "this-language-lacks-my-favorite-cool-fancy-feature-so-it-is- necessarily-an-old-fashioned-crappy-piece-of-s*" syndrome?

<comment><USER17> Were they actually fancy or cool, maybe. They're rather basic features among statically typed languages.

Also, I'm not trying to say Go is bad or that I dislike it. It's simply not a modern language as far as design goes.

</comment></comment></comment></comment></comment></comment><comment><USER18> I have been playing a lot with QML lately and I am loving what I see there. Their approach of animations or graphics seems simple and very approachable - [http://qmlbook.org/ch05/index.html](http://qmlbook.org/ch05/index.html) .

The reason I bring this up is, while I like swift (and own more than one macbook pro), I can't bring myself to code for a platform which ties myself further with Apple eco system.

If you are looking to build a cross platform 2D game for Android/iOS/OSX/Linux - QML seems like a very good choice.

</comment><comment><USER19> Hi @rohamg, I was wondering if you could please share the libraries and frameworks you are using? I'm also building a mobile app in Swift with a web backend in Go. I've done a bit of research, and I think I'm going to use the following:

iOS:

* MagicalRecord - CoreData abstraction ([https://github.com/magicalpanda/MagicalRecord](https://github.com/magicalpanda/MagicalRecord)) * mogenerator - better CoreData class management ([https://github.com/rentzsch/mogenerator](https://github.com/rentzsch/mogenerator)) * RestKit - with REST API endpoint ([http://restkit.org/](http://restkit.org/))

Go:

* Gin - Web framework. I really like the focus on performance, and that it seems to include all the features you need for an API (authorization, route grouping, etc.) ([https://gin-gonic.github.io/gin/](https://gin-gonic.github.io/gin/)) * gorm - for most CRUD operations / queries ([https://github.com/jinzhu/gorm](https://github.com/jinzhu/gorm)) * sqlx - for more complex queries ([https://github.com/jmoiron/sqlx](https://github.com/jmoiron/sqlx)) * apns - push notifications ([https://github.com/anachronistic/apns](https://github.com/anachronistic/apns)) * gingorelic - New Relic integration ([https://github.com/q1t/gingorelic](https://github.com/q1t/gingorelic)) * APIBlueprint - API documentation ([http://apiblueprint.org/](http://apiblueprint.org/))

<comment><USER19> Argh, formatting. And now I can't edit or delete it.

</comment></comment><comment><USER20> How does a language without generics claim to "do more with less code"? Don't get me wrong, I like Go, but it's hard to get behind any language with that low of an abstraction ceiling. Then again, I work in a web shop, building CRUD apps for a living, so maybe it doesn't matter for people who only have to build one version of something.

<comment><USER2> We survived getting things into and out of Lists in Java 1.2 to 1.4 somehow. The typecasting on the .get(...) calls is a nuisance, but a minor one.

<comment><USER21> Back in 2002. 12 years ago!

<comment><USER2> It was a dark age, and void stars filled the console. Many a core were dumped. An age where boys became men!

:-)

</comment></comment></comment></comment><comment><USER22> Which database do you Go for? Is the driver production ready?

<comment><USER23> We are using [https://github.com/go-pg/pg](https://github.com/go-pg/pg) for Postgres with some luck, but I think the standard is [https://github.com/lib/pq](https://github.com/lib/pq). We are also developing a driver for Orient DB with the goal of it being production ready.

</comment></comment><comment><USER24> > Go compiles very quickly, but that actually didn't impact us very much since > we have largely been using interpreted languages on the backend. I'll betcha > those poor Java programmers get pretty excited about this, though!

Oh?

<comment><USER10> Someone should probably mention to the author that us poor Java programmers have had incremental compilers for over a decade, so compilation speed hasn't been an issue for a long time.

Best not to mention that we've also had generics for over a decade, though, wouldn't want to upset him.

<comment><USER25> Well, you can consider it mentioned to the author... that would be me!

I shouldn't have tweaked Java so mercilessly since I did love the language for so long (lo, these many years ago). However, I do think you really underestimate the compile speed of Go. Even if 99% of your builds are incremental, you can't entirely discount the occasional clean build. While it has been many years since I hacked Java, even incremental builds could take more than a few seconds. Even a clean build on our 50 kloc Go codebase clocks in under 2 seconds (0.1s when the disk caches are pre-warmed).

As for generics, I do like them, and seeing them on iOS (with Swift) is a pretty big win. I'm not entirely convinced that Go is much poorer without them, however. The type system in Go is really unique; if you tried to program Go using Java-style paradigms, there's no question that you'd find it pretty disappointing. However, Go does allow some new ways of thinking about types that allow a degree of flexibility that simply can't be expressed with formal class hierarchies.

If what you're doing works for you, just keep on truckin'. But if you give some of these new languages a chance, you might find the areas where they really shine. We did!

<comment><USER26> If you want to contrast compile speeds, try Go vs. C++. Java compilation has been very fast for a long time, as others point out.

For my part, my main beef with Go isn't necessarily the lack of generics, but the obstinate lack of expressiveness. It's back to Java or Python where you're forced to break up your code into discrete, imperative chunks instead of chaining stuff together in elegant flows. It's like Go's authors missed out on functional programming. No pattern maching, which seems like a huge miss considering Go has select { }. Go's syntax is, in many ways, even more rigid than both Java and Python.

That rigidity extends to error handling. While I agree with the _philosophy_ behind Go's rejection of exceptions, I don't agree with how it's been implemented. In discussions about Go people always talk about exceptions vs. explicit error returns, but hardly anyone mentions the fact that error handling completely takes over our code: errs are everywhere!

A concrete example: Go has := for type inference, but it turns out you can almost never use it, because almost every function needs an "err" that you end up declaring. Often you start out like this:

        if result, err := getResults(); err != nil {
          return
        }

Quite elegant. But then you need to add some more code, and you actually can't rely on type inference anymore:

        var err error
        var result *Result
        if result, err = getResults(); err != nil {
          return
        }
        stats, err = computeStats(result)

It turns out that just because you needed another "err", you had to rewrite the statement, which is frankly ridiculous.

The next problem here is that we can't simply this:

        result, err := computeStats(getResults())

That's because computeStats() takes a _Result, not two arguments (Result_ , error). In functional languages, this is elegantly solved through monads, but not in Go; you can't "short circuit" function chains that might return errors. There goes your expressiveness.

Another problem that the error phenomenon infects the language with is that you can't have global variables initialized this way:

        var spaces := regexp.Compile(`^foo`)

To get around this, the regexp module defines an alternative function:

        var spaces := regexp.MustCompile(`^foo`)

(Never mind the fact that you're not allowed to declare this as a const. It _is_ a constant, I want it to be a constant, not a global variable!)

The fact that almost _every_ function ends up having an "err" around raises the question: Why is it not an integral part of the language in the first place? Why do _I_ have to declare err?

Other languages (Swift among them) fix this problem through sum types: The function can return a value which is _either_ a real value or an error. Go's idea of returning a value _and_ an error is logically nonsensical in almost every case, because the error is used to signify that the value isn't available due to failure. I'm not a language-theory purist who thinks everyone should really be using Haskell; these are _practical_ concerns.

Overall, Go does feels disturbingly warty in places, which is incredible for a new, clean-slate language. Favourite wart: interface types being magically pointer-based, leading to the whole non-nil value being nil idiocy; it's mindblowing that they got this so wrong.

I liked Go a lot better before I started using it.

<comment><USER27> My personal experience at a startup with a large amount of Go code running its frontend and backend servers. YMMV.

First off, I also find the interface-nil thing to be a frustrating edge-case. I also know that this design was the result of some difficult tradeoffs, as such things often are. We can argue about whether they made the _right_ tradeoff, but I don't think it's fair to refer to it as a "mindblowingly wrong idiocy".

Second, on error handling. Having now written a large amount of server code in Go, I find that I strongly support their approach, even when I find it a bit verbose. Here's how I find it actually plays out in practice:

        // You write something like this:
        result, err := getResults()
        if err != nil {
          return err
        }

        // Then you reuse err for the next call
        result, err := getResults()
        if err != nil {
          return err
        }

        stats, err := computeStats(result)
        if err != nil {
          return err
        }

Eventually, you realize that `return err` just isn't enough most of the time, because it's impossible to make sense out of your logs. So we added a simple "error chaining" function that allows you to pass context when you return the error, which makes the logs much clearer than just a single error message, or raw stack trace. And of course it is often the case that you want to do more logging in your error blocks, even as you ignore the error and move on (e.g., "spurious error reading memcache entry; falling back to the slow thing").

The practical reality of writing good server code is that exceptions which get caught way up the stack are inscrutable in your logs (at least that was our experience), so it makes sense to know up-front exactly where failures can happen, and to be forced to think about them the first time you write your code. Yes, it can be a bit verbose, but we've found the tradeoff to be net positive.

<comment><USER26> For the record, I don't think the interface problem is "mindblowingly wrong idiocy" (you words!).

But I think it's a good indicator of how parts of Go's design are flawed from the outset. Design is hard to change later, so it's important to get it right from the start.

Again, I totally buy explicit error propagation. I just think Go's solution ends up cluttering your code. It's so focused on errors, yet handling isn't a first-class construct, and the mechanisms it gives you for dealing with errors aren't very good. You have the cast check (a, ok := ...) and you can do a type switch (switch a := err.(type) { ... }), but it's rather weak for something that permeates every corner of the language. At least us have pattern matching.

I find the stack frame problem disappointing. It's amazing that there are now several libraries to create artificial stack frames (eg., [https://github.com/facebookgo/stack](https://github.com/facebookgo/stack)) just so you get this.

<comment><USER27> I don't want to pick nits too much here, but "[...] leading to the whole non- nil value being nil idiocy; it's mindblowing that they got this so wrong." So I paraphrased a bit :)

I understand that some may find the error handling a bit too verbose, but humbly submit that there's a legitimate tradeoff to be made in terms of language complexity vs. verbosity, and the Go team generally tends to fall on the side of simplicity over tersity. This works well for us, but not everyone will find it palatable. YMMV and all that.

The stack frame "problem" doesn't seem all that bad to me. It would be nice to have a built-in solution, but our own code for dealing with this is one tiny file someone banged out in a couple of hours, so I'd hardly call it more than a stumbling block. After watching the Java world deal indefinitely with untold design flaws in core libraries, I support keeping things simple at the outset wherever possible.

But hey, there are lots of choices out there, so I'm not telling anyone they must write their servers in Go. Just that it works well for us.</comment></comment></comment></comment></comment></comment></comment>


Huge loss leaves GM almost out of cash - <AUTHOR> http://money.cnn.com/2008/11/07/news/companies/gm/index.htm?postversion=2008110711

<comment><USER2> Yes, we could give a low interest loan (low relative to the risk of the loan) to GM. This might save some jobs and help the US economy.

Or we could let GM fail, and invest that same money in energy and biotech. Many would lose their jobs, but many more would get new jobs. These would be higher paying jobs, but also higher skilled jobs.

Lets not act like these loans are free. We should keep in mind that every dollar we loan to GM is a dollar we don't loan or invest in something else.

<comment><USER3> "We should keep in mind that every dollar we loan to GM is a dollar we don't loan or invest in something else."

Don't pretend this is true, because it isn't, and to say otherwise is to be complicit in covering up a problem that's way bigger than whether or not we throw a couple bucks at GM.

<comment><USER4> They lost more THIS QUARTER than their entire market capitalization. Keep taxpayers out of it!

<comment><USER3> I'm not sure how you got that I was advocating bailing them out, but I'm not.

</comment></comment></comment></comment><comment><USER5> The UAW must be worried. They're going to be like a parasite that kills the host if they're not careful.

<comment><USER6> They're also the reason GM won't be bought. No one will take on the nebulous liabilities they got GM to agree to. Those liabilities wouldn't have been a problem had the auto industry remained an oligopoly, but with (closer to) real competition, GM and the like couldn't extort consumers as much. Before, GM and others could simply pass the gouging on to customers.

The fact is that GM will never be profitable in the future because its labor costs are so much higher. Does anyone think GM can become 3x as efficient as Honda, Toyota, etc.? It's a credit to American ingenuity that they've held on for this long.

Many people like the idea of institutionalizing things. Like, I've done this and I work hard, therefore I should be set. That happens a lot in Europe (although it's lessening as EU laws become more competition-friendly). It sounds great and works for a while, but then this happens and you're left with two options: the poor-house or convincing people actually producing value to support you in a welfare-with-pride sense.

The problem is that life changes. GM agreed to contracts with provisions like offering x% of salary for the rest of an employee's life as well as covering their healthcare. Well, that was fine until Americans started living longer and that became a ton more money. On top of that, we have decided that it is inhumane to deny someone even the most cutting edge health care. That's fine, except that it means health care providers can charge anything they want since it's a violation of rights to deny it. No matter how marginally effective, no matter what the cost, people should get it. I'm not saying this is bad. I'm saying that it's ridiculously expensive and that it used to be more acceptable for people not to have access to the most cutting edge health care. In fact, it's the mark of a successful society that people want to continue living so much!

So, GM has agreed to those and it's way more than they budgeted and put away for. Not only that, it's likely to raise way faster than inflation as people shift spending to things like health (from consumer items which haven't spiked as much in price) and live longer. No one in their right mind would buy into that.

What will most likely happen: GM will file for bankruptcy. A lot of its labor contracts will be nullified. Someone will buy GM sans the labor contracts.

<comment><USER7> The difference in a 20 year annuity and a 30 year one is significant, but not that significant. GM could easily cover the difference with the dividends they have irresponsibly paid out in the last 10 years.

</comment></comment></comment><comment><USER8> Why can't we stomach letting a big company die in this country? A lot of people will lose their jobs but in reality it might be for the best moving forward. Demand for cars won't go away, there just won't be a supply of GM ones.

A lot of "foreign" cars are already built here anyway, let Toyota snap up the GM factories, reemploy their workers, and lets move on.

The downside is that there are a lot of GM pensions out there, but if the government won't let GM fail because of the pensions, maybe the government should just take over the pensions and let this dinosaur die. How much more money would we have to spend to prop up this failing company again and again when all we really want to do is make sure a bunch of retirees don't go bankrupt?

<comment><USER9> Although their product line needs a lot of work, killing them would have huge ripple effects (forget about the stockholders, consider the suppliers and debt holders). So, yeah, we could let GM die, but the effects on the economy would be considerable.

Why would Toyota buy GM's factories? Retooling them for a completely different line of cars probably doesn't make sense, and I doubt Toyota would be interested in selling most of what GM has today.

I don't think there is an obvious solution.

</comment></comment><comment><USER10> Not sure what to think about this. On the one hand, I have nothing but antipathy toward GM for squandering every opportunity to modernize their business and fighting the regulations that would have forced them down that path. If any business deserves to fail, they do.

What gives me pause is how much damage a GM bankruptcy will inflict. The auto industry represents about a third of the US manufacturing industry. If GM (or Chrysler) goes down, it may take everyone else with them. The job losses would be unbelievable. I don't really want to contemplate what the economy will look like after construction, finance, and manufacturing have all been wiped out.

<comment><USER11> A bankruptcy won't necessarily kill the business. Look how many times airlines have gone bankrupt and they're still flying. What it will do is cause the business to be restructured and make it more in line with the foreign companies which have much lower legacy/union costs.

<comment><USER12> Please stop bashing the unions. GM has a _sales_ problem. They can't sell any more SUVs.

<comment><USER13> It's death by 1000 cuts. The unions aren't _the_ problem, but they definitely contribute, along side inflexible plants that can't be reassigned, never laying off white collar workers (until last month? wtf), not building cars people want, complete marque mismanagement (Pontiac and Chevy cars were virtually indistinguishable for 30 years), equating small cars with low quality (geo metro of the 90s, chevette of the 80s), abusive partnerships with other manufacturers (Daewoo), divesting themselves of key component manufacturing resources (Delphi) creating incentives for the independent company to attempt to squeeze for profit, a lack of commitment to quality, failure to tend successful brands (Ford's especially bad about this), fighting ecological and safety regulation instead of embracing it as a feature, coasting on their performance brands instead of cultivating new markets, and lukewarm attempts at innovation when they actually did something new.

Fixing any one of those problems leaves all the rest. GM is facing downward pressure on production costs (among everything else) and the unions stand in the way. You can't blame the unions for trying, but as a disinterested bystander you have to wonder why GM wasn't firmer in their bargaining -- everybody's losing now.

</comment></comment></comment></comment><comment><AUTHOR> "GM said it had burned through $6.9 billion during the quarter and warned that it "will approach the minimum amount necessary to operate its business" during the current quarter."

Wow.

<comment><USER14> What's amazing is that they aren't innovating and rolling out a crapton of electric or solar-powered cars or whatever else they can to save the business.

<comment><USER15> It takes a long time to roll out a new car, particularly if it uses a new technology like electric or solar power. Like years. If they started innovating when they first ran into problems around 2006, then it'd probably be 2011-2012 before new cars started appearing in showrooms.

The Chevrolet Volt, first unveiled in 2007 and probably under development since 05-06, isn't expected to start selling until 2011.

By then, it'll probably be too late.

<comment><USER14> They've had a long time to do this. A very long time. Electric cars are not a new idea. Check out the EV1 ( <http://en.wikipedia.org/wiki/EV1> ) which was in production in _1996_.

<comment><USER16> "Electric cars are not a new idea." - which _supports_ the statement that electric cars are hard. In fact electric cars date back to the very beginning, before there was even an "automotive industry"; nobody's been able to build a practical electric car for over a hundred years now.

It's _hard_. Battery technology has not been cooperating. If electric cars are your last-ditch hope to survive, you're just dead.

<comment><USER17> It would almost seem that the battery, or even more simply, energy storage is really _the problem_ holding back electric cars. If a company came up with a new kickass battery that was way better than what exists, they should just start a car company, or at least every car company on earth would buy their batteries as fast as they could get their hands on them.

</comment></comment></comment></comment></comment></comment><comment><USER13> One thing that the US federal government could do to spur innovation is offer exempt categories (low volume) for vehicles that don't meet all safety or all emissions requirements.

It's obvious that we don't want millions of people driving their children around in dirty, unsafe cars, but there was a lower testing / R&D burden for small companies (consider companies like <http://www.arielmotor.co.uk/> in the UK), there would be a lot more opportunities for the fresh design the US industry needs, along with the manufacturing to support it.

If the manufacturing industry that would support low volumes was built, it would be possible for the larger automakers to leverage those lines for JIT production of vehicles people want -- one of the big things Toyota has over the US domestics.

Unfortunately I think this solution sits in the land of car-fan fairy tale -- the left wouldn't want it because it would relax eco concerns, and the right wouldn't want it because it would possibly restrict how much the larger automakers could take advantage of (low volumes, again).

</comment><comment><USER12> I don't understand how US still doesn't get it. You bail out Wall St. people who ran a pyramid loans scheme and now the company who was the worst in the big car madness. Their worse bit was selling the socially irresponsible Hummer.

<http://en.wikipedia.org/wiki/Hummer#Criticisms>

Why are you going to bail them out and not the good tech startups? Or the sane VC, you know, the guys who risk money on new ideas that benefit the whole world economy.

Judging how it is going with banks, this won't work for workers. The interest rates are not passed down to mortgages and I bet the GM bailout won't save that many jobs. Also remember what happened with the airlines bailout on 2001/2, they fired a lot of employees anyway.

<comment><USER18> > I don't understand how US still doesn't get it. You bail out Wall St. people > who ran a pyramid loans scheme

It's not just the US - the EU's bank bailout was about 3x as large.

The loan problem was a US govt idea - encourage banks to make loans to folks who didn't qualify under normal standards (including punishing banks that didn't do so) and have two huge govt sponsored enterprises (Fannie Mae and Freddie Mac) buy many of them and "create a market".

Which is where the EU got involved - EU banks and govts bought those loans too.

</comment></comment><comment><USER19> Sometimes people wonder how the market value of a company can be less than the value of their cash reserves in an efficient market. GM is a case in point.

<comment><USER20> The market value is related to current assets and expected future earnings minus liabilities. If the liabilities are greater than the expected future earnings, the company could be worth more dead than alive.

Pension obligations are more brutal than most workers realize; the city of San Diego has had massive financial problems because of that too. It's usually dismissed by young employees (rationally), but it shows up on the supporting organization's balance sheet in a big way.

And as far as future earnings go: gas prices shot up for enough consecutive summers that consumers finally adapted; the demand curve shifted. Gas prices have dropped recently, but consumer preferences have already changed, and economic concerns still aren't making SUVs and big trucks any more financially attractive.

In short, investors are saying that GM should be stripped and sold for parts.

</comment></comment><comment><USER21> the messed up part is that GM may be down in the crapper and begging for a hand out, but they are still looking to buy Chrysler. Why? Wouldn't you want to buy a successful car company? There is not one car that Chrysler makes that doesn't have a similar vehicle in the GM line up.

Instead of pissing away billions on a crappy Chrysler brand that has been passed like a hot potato from one brand to the next, invest that money into getting the Volt out to the public sooner. Invest that money into expanding the line up to a whole line of Volt vehicles, Volt Sedan, Volt Convertible, Volt Pickup, Volt small SUV. Then spend some more cash to update the current models the new Camaro/Volt front/rear end.

<comment><USER22> Well that is exactly what they are doing. The talks with Chrysler have been called off until they find a solution to their liquidity issues. And the Volt and other Volt-like designs are getting all the attention while other programs company-wide have been put on hold.

So to summarize, they are doing exactly what you said.

<comment><USER4> The don't have a "liquidity issue", they are utterly insolvent.

<comment><USER22> Ah yeah, sorry.

Part of my problem is that I actually believe the Volt would be great thing for them, so I look at their current problems and think: "if they can just last until the Volt comes out, they will make it".

I realize that makes me a bit of a Pollyanna.

<comment><USER23> I doubt they'll be able to sell the Volt at a big profit initially. They'll probably be forced to sell it at cost to keep the price from being too ridiculous -- and they're talking about the manufacturing cost being something like $40K.</comment></comment></comment></comment></comment>