mbel

In the second case it's AOT (ahead of time) not JIT (just in time) compiler.

You probably mean strcat() (which should really not be used, since now there is strncat()), there is no concat() in standard C library. strcat() does not intercept syntax of operation that does not mutate its arguments in any other context (+), you also cannot do strcat("hello,", " world") since the first argument must be mutable.

To which the same argument applies.

> but a constant stream of mischief and abuse stories coming for the past few years... that's just how Uber rolls

So if some piece of information is repeated enough times it is definitely true? I don't want to defend Uber here, I just think that your reasoning in this sentence is flawed.

Another thing that does not seem to be very constructive is complaining about all those kernels written in evil C instead of writing one in Rust.

With clang you can use -Rpass family of flags to get information about missed and used optimization opportunities. Although it will not print absolutely everything (trivial optimizations will be omitted). Other compilers have other options, ICC for example is able to generate optimization reports.

> or GHC, you can use ML or C or Python or PHP or whatever instead of Haskell.

Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.

Yeah, the closer analogy would be FedEx selling information about content of your packages unless they are shipped in some kind of locked strong box.

Sorry, I misread it.

Well, it could just use function name and leave it to javac/kotlin/other JVM front end to handle overloads and generate unique names. Although that wouldn't work nice with refection and other run-time features I guess.

The article describes Dalvik which is different from JVM, so it's not really a proof.

But you are actually right. It looks that JVM bytecode includes full function signature in function invocation: https://www.ibm.com/developerworks/library/it-haggar_bytecod... (if I'm reading examples correctly).

According you your link JVM does not support this feature. It's implemented by Kotlin itself. I guess it's probably some kind of name-mangling scheme.

> Either way, the idea that you can write code in a safe language and compile to C to eliminate the type of bugs that C allows isn't true.

Is a bit different statement than:

> I'm saying "rewrite it in Rust (or whatever)" isn't some silver bullet that fixes security problems.

The first one is wrong, the second one is true.

Using a higher level language rules out some classes of programming errors which are possible in lower level languages. The fact that compilers have bugs does little to diminish those gains.

Semantics of Haskell does not allow to express program that generates double free [0]. Perhaps one of the compilers will compile some Haskell code to binary that frees memory twice. However, this bug in compiler is far more less likely that a programmer making this mistake in C. Whats more when this bug in compiler is detected and fixed. The problem can be fixed in all affected code bases without need to change the original source code. Thus chances of bugs are lower.

Nobody really argues that Rust (or OCaml, or Haskell, or whatever) is a silver bullet, i.e. solution to all problems that will miraculously make programmers produce no bugs at all. Obviously we will have software bugs even with most restrictive languages. No amount of formal proofs will save us form misunderstanding specifications or making typos. And then again we will also have bugs in implementation of those high level abstractions.

And for the record I am really annoyed with movement to rewrite everything in Rust.

[0] Yes, you can call free through FFI with whatever arguments you like, as many times as you like. But for sake of brevity let's assume this is not how you write your everyday Haskell.

Compiling X to C and then C to assembly is not more complex that compiling X straight to assembly. In your orignal comment you wrote that the complexity of such setup is bigger, to which I responded: no, not really.

Yes, C was not designed to be intermediate compilation step and this yields losses of some information (e.g. debugging metadata, but also some semantics of source language may get lost). I never argued with that. I never said that this is a perfect setup that doesn't introduce any new problems. I just said that compiling to C is very close to what is actually happening inside the compiler targeting assembly from higher level language.

Of course metadata is lost if not encoded anywhere on the way. The argument was made regarding code generation being more complex when code is saved on the intermediate level.

You are arguing that no language X is safer than writing program manually in Y when program in X is compiled to Y. Because compiler from X to Y may have bugs.

Therefore no code written in Rust (X) executed on x86 CPU (Y) is safer than manually written x86 assemby, because Rust compiler (and LLVM) may have errors.

And well, we can actually go deeper. There is CPU frontend that is generating micro code, which may have bugs. There is also CPU backend which is executing micro code, which also may have bugs. All in all there is no hope in programming. There might be bugs everywhere so you can never be sure what your program does.

This is simply not true. C in this case is just an intermediate representation of the source program. Going through multiple intermediate representation of the source code is fairly standard practice when compiling anything. If anything it is easier to target C than directly generate target CPU assembly, because of the high level nature of C (you finish the compilation earlier, without last couple of lowering steps).

So no code is safe? All code before execution has to be lowered to some evil, unsafe language, most commonly the assembly language of targeted CPU.

The mystical process of "programmatically generating code" in also known as compilation. The case you are describing is a compiler bug. The compiler wasn't able to generate target code (in this case C code) with semantics and/or guarantees of the source language.

The design of Wayland might be (and I believe is) superior to X11. Although as every piece of software on this planet in first years of its existence it will be incomplete, buggy and not compatible with all the other things that already exist. For some people this might be shitty compared to mature software, that is buggy but at least most of it's bugs are already known and worked around.

> I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html

gcc removes recursion in that case: https://godbolt.org/g/R6iBup

Yeah, it's hardly a benchmark. The information what kind of CPU they are using is also missing (why no -march=native?).

Despite how unbelievable it looks, I would love to see contents of the final binary to see what is really happening there. gcc code looks quite alright in this case: https://godbolt.org/g/R6iBup

Gravitational teleport sounds like something out of cheap science-fiction novel. Magical device with pseudo scientific name which inner workings are never explained. It's only purpose is to act as a deus ex machina when author runs out of ideas.

On the other hand, future heralded by sci-fi is indeed now: you can download your gravitational teleport and you are free to use it :)

For everybody who has no idea what a "gravitational teleport" is: it's an SSH server (http://gravitational.com/teleport/). Probably it could be included in title? (yeah, I know HN guidelines prefer verbatim titles)

This is not how iOS works. Only few apps work ("eat away battery life and performance") in the background, and only in some special circumstances (active music playback, background refresh once in a while if user allows for it). The apps seen it app switcher (double home press) are effectively dead, their state is kept around to allow user to switch back, but they cannot do any processing in background.

> I found it fascinating that Smalltalk was #2 as most loved language in spite of its minimal use.

It probably is because of the minimal use (and I believe #1, Rust, is also there because it's still not that common). Their "loved" metric is number of people who are using a language and would not like to switch to a different one. I suppose that the only people who use it are people who love it so much that they can ignore issues caused by lack of popularity (small number of libraries and tools, problems with OS support, etc.).

I guess that: "You fool! It is not a picture. Take a picture using supplied UI widget that resides in place where one would expect software keyboard." sounds less appealing to teenagers :)

How arrow keys are related to tab/space flamewar? Isn't everybody (whose job requires typing) using moving between words as the most basic mean of navigation? (w, M-f, Ctrl+arrow, etc.)

> Desktop or even native mobile development seems to be like going back to the last century.

The funny thing is that looking from the opposite perspective I feel the same. The web development looks like going back to beginnings of programming and reinventing everything again in the browser. You know, like when you read about 'tree shaking' being cutting edge technology in JavaScript land, then look at definition to realize that it's just dead code elimination that has been done by linkers & compilers for ages.

Large part of education is consuming media (text books). Although I agree, I've never seen any appeal in iPads in schools.