Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ at Google: Here Be Dragons

blog.llvm.org

Post reply on HN
Print view View original

31–40 of 91 posts

Re: C++ at Google: Here Be Dragons

#31

Post by swannodette »

nradov wrote: post #27
michaelcampbell wrote: post #25

Earlier quoted context omitted.

I hear you, but I think the rest of the world is actually polarizing to some degree. Perhaps I'm just fickle or a language whore, but I love both the dynamism and freedom of Ruby (et. al.) and the "protect me from doing stupid $#@!" of Scala (et. al.) Although honestly, I don't know that I'd want a language that supported both, if even such a thing were possible. I do see a lot of people getting all hung up on one si…

Why can't we have a language that supports both? I would love to have a language with a scalable type system where I could hack out a quick small prototype with dynamic typing first, and then perhaps layer on static types later where necessary to improve reliability and performance as the program evolves. For example, I would like to be able to declare a variable in all of the following different ways. a value a numb…

You can support both. You should take look at Typed Racket, Racket w/ Contracts, Erlang Dialyzer, and Qi/Shen. Frankly the Lisp contingent is way ahead on this kind of thinking (would of course love to hear about others).

I'm interested in developing such systems for Clojure and have actively researching something considerably more powerful than Chambers/Chen predicate dispatch.

Re: C++ at Google: Here Be Dragons

#32

Post by jorgeortiz85 »

swannodette wrote: post #28
profquail wrote: post #21

Earlier quoted context omitted.

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

Those in favor of only static typing and those in favor of only dynamic typing are living in the past. Any interesting evolution in programming languages will allow developers to program with and without types / contracts from the same language.

C#'s new "dynamic" type and Scala's new Dynamic trait are a step in that direction.

Re: C++ at Google: Here Be Dragons

#33

Post by obiterdictum »

timr wrote: post #16

To me, the most remarkable thing about this post is that when the rest of the world is falling in love with the "power" of weak typing systems, Google is going the other way .

I think this is a very web-development-centric view on things. In fact, I dare suggest that the world does not revolve around JS, and the bulk of development, especially in-house, is done in fairly pedestrian languages (C++, Java, C#). Web developers tend to have more web presence, naturally, so the majority of public discussions and news may make it seem to be representative of the world.

Re: C++ at Google: Here Be Dragons

#34

Post by cageface »

profquail wrote: post #21
timr wrote: post #16

To me, the most remarkable thing about this post is that when the rest of the world is falling in love with the "power" of weak typing systems, Google is going the other way .

the rest of the world is falling in love with the "power" of weak typing systems Really? I'd argue the exact opposite -- with F# and Scala (and some others) on the rise, I think there are plenty of people who are fed up with weak/dynamic typing and want to take advantage of building programs with strong type systems. At the very least, it seems that the programming world is becoming much more polarized. Anecdotally,…

I'm certainly going the other way. After working almost exclusively in dynamic languages for almost 10 years I'm finding it enormously refreshing to have the help of the compiler again when I'm writing Scala code. Even the primitive type system of Objective-C is a welcome change. Of course, occasionally you need an escape hatch. But, in my experiences, the good static languages give you enough wiggle room to do this when you really need to.

Re: C++ at Google: Here Be Dragons

#35

Post by cageface »

spitfire wrote: post #24
chandlerc wrote: post #13

Earlier quoted context omitted.

I would expect many of these tools to catch these types of bugs. The challenging thing for us has been to catch only bugs, and to catch them very fast during normal compilation. A lot of the static analyses we've looked into (and I'm hoping for more detailed blog posts about that in the future) find plenty of bugs, but also find lots of non-bugs. Combine that with being too slow to run during the normal build, and yo…

These sort of articles (and the attendant comments about false positives) always scream out for Ada to me. It's a language designed by a calm, careful thinker back in the 80's for life critical programs. It has everything Java and C++ have except the vast number of undefined states and it's designed for static analysis. By designed I mean, there are formal verifiers and the NSA has used it in a test security system.…

What kinds of libraries are available for Ada? Half the reason I use C++ is that half the code I need to write is already available in mature libraries.

Re: C++ at Google: Here Be Dragons

#36

Post by chandlerc »

archangel_one wrote: post #30

The article implies to me that the third bug (passing 0.5 to sleep() ) is not caught by gcc. Does anyone know if this is the case? It doesn't seem excessively hard to produce a warning about shortening like that - the first two seem more subtle, but that one less so. I don't have gcc on this machine to check it, but VC++ certainly does emit a warning for that kind of thing.

GCC definitely has a warning for 0.5 -> int (likely -Wconversion, but I've not checked). It also has a warning for setting a pointer to "false" (-Wconversion-null). However, turning that warning on in a codebase where every warning breaks the build was challenging because of false positives. We're able to remove false positives and narrow the scope of the warning to just the buggy code in many cases with Clang, and that allows us to turn these warnings on much more aggressively.

Re: C++ at Google: Here Be Dragons

#37

Post by ANH »

wmobit wrote: post #6
matthavener wrote: post #3

I wonder if this is an indication that google is moving to clang for compiling (and not just diagnostic tools). If that's true, maybe this is another nail in the coffin for gcc? I see apple and google behind llvm/clang, who's behind gcc? Nobody?

Google has said before they didn't use Clang and LLVM because of performance issues. GCC is far from dead, and probably never will. Clang generated code is still typically 10-20% slower than GCC. Lots of companies work on GCC, including Google, Intel, AMD, IBM, Red Hat and others.

I've seen this "10-20% slower" meme several times, but I've also read several accounts of 10-20% faster runtime performance.

All I know for sure is I compiled my codebase with Clang for the first time yesterday and the compilation time was absurdly short. I thought the compiler was broken. And it enables excellent tools like clang_complete for Vim code completion.

Re: C++ at Google: Here Be Dragons

#38

Post by DerekL »

nikki9696 wrote: post #17
chandlerc wrote: post #14

Earlier quoted context omitted.

Doh! Good catch, comment updated. =[ Maybe we do need Clang-for-comments as well as Clang-for-C++ code.... ;]

And the error says it's an int, but it's declared long. Am I missing something about long in C++ not being 64 bits?

The left operand is an int, so the result of the shift expression is an int. The fact that the shift expression is used to initialize a long is not relevant.

Re: C++ at Google: Here Be Dragons

#39

Post by MBlume »

ANH wrote: post #37
wmobit wrote: post #6

Earlier quoted context omitted.

Google has said before they didn't use Clang and LLVM because of performance issues. GCC is far from dead, and probably never will. Clang generated code is still typically 10-20% slower than GCC. Lots of companies work on GCC, including Google, Intel, AMD, IBM, Red Hat and others.

I've seen this "10-20% slower" meme several times, but I've also read several accounts of 10-20% faster runtime performance. All I know for sure is I compiled my codebase with Clang for the first time yesterday and the compilation time was absurdly short. I thought the compiler was broken. And it enables excellent tools like clang_complete for Vim code completion.

Woah, let's not conflate compilation-speed with runtime-speed...

Re: C++ at Google: Here Be Dragons

#40

Post by michaelcampbell »

nradov wrote: post #27
michaelcampbell wrote: post #25

Earlier quoted context omitted.

I hear you, but I think the rest of the world is actually polarizing to some degree. Perhaps I'm just fickle or a language whore, but I love both the dynamism and freedom of Ruby (et. al.) and the "protect me from doing stupid $#@!" of Scala (et. al.) Although honestly, I don't know that I'd want a language that supported both, if even such a thing were possible. I do see a lot of people getting all hung up on one si…

Why can't we have a language that supports both? I would love to have a language with a scalable type system where I could hack out a quick small prototype with dynamic typing first, and then perhaps layer on static types later where necessary to improve reliability and performance as the program evolves. For example, I would like to be able to declare a variable in all of the following different ways. a value a numb…

I'm not experienced enough to say that you absolutely can, or cannot. I only have some experience to guide me, and I haven't seen it done yet.

That said..., I have an uneasy feeling that trying to do it would end up with a PL/1 type of situation where, depending on your background, you write it with whatever baggage you bring with you, and the language would get large to the point of different types of programmers writing in their own familiar subset of the language.

Or, I'm completely wrong. =)

Post reply on HN