What do you think a sensible alternative is? I have serious problems with C++, but few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
Sadly UNIX spread into the enterprise and with it brought C to the masses and spread the doom of security we still enjoy.
C++ is way safer than C, if one use modern C++ instead of C underpinning that allowed the language to become mainstream.
Now, we have to hope languages like Rust and D might recover what Ada, Modula-2 did not managed to become.
Compared to what? C++? You're joking right??
> Well, I'm not sure it's better than C++.
I disagree, Ada is complex ok, but its default behaviour is much better for security than C++.
Not at all. Well, maybe not compared to C++, but still, it doesn't seem like really plausible alternative, that can be recommended and seriously used in a complex application. Dijkstra agrees. ;)
> but its default behaviour is much better for security than C++
Oh, sure. But that could be said about pretty much every language out there. Somebody recommends Haskell. Haskell's default behavior is way better than C++. It's not enough.
Actually, I never saw big projects in Ada, so I can be wrong, but it seems to me that for typical more or less sane programmer might be even easier to write hard-to-understand code in Ada than in C++, even though Ada is much better designed. The reason is that C++ complexity is well known, many of it's features considered dangerous and most of people seem to avoid them. That's not true for Ada, and it's also very feature-rich.
If anything: there are many things about Ada I like. Its data type system, for example. It's really a shame that after C many programmers somehow "forgot" that all that stuff exists.
I think they were born after many of us had the pleasure of using alternative languages.
There are other languages that could be used to write very secure browsers, but using them wouldn't necessarily be straightforward.
They do have a few practical advantages over C++. For one, they don't allow dangerous things like pointer manipulation. They both support garbage collection. Go has some nice built-in support for multithreading. Both have some nice iteration features. Useful syntactic sugar. Stuff like that.
Where C++ is basically just C with random features shoddily spot-welded on in different places, Go and Rust were designed from the ground up to be relatively very simple and straightforward. Like I said, they're not amazing; they're just better than C++.
Modula-2 was created in 1978! Just to cite one memory safe systems programming language.
For as fast and as furious a pace as the world of computer programming likes to think it runs at, there is an unbelievably long line to get something from research to common practice. It's literally decades long.
Though there are some reasons for this; there's a difference between doing a research compiler and doing something that can actually be deployed in the harsh environment of the real world. Still, the world of computer programming does not advance anywhere near as quickly as it fancies itself doing.
Rust actually uses new stuff; the borrow checker builds on old ideas from Cyclone and others from the 90s, but it mixes it with some interesting research ideas of its own (using C++ destructors to get region typing at the level of individual values, not of regions) to come up with something that's actually fairly novel.
Modula-2, Turbo Pascal and Ada weren't research languages, rather well known languages, while C was mainly UNIX only one, slowly spreading alongside UNIX into the enterprise.
I think the problem is that many young developers never experienced those days and think C and C++ are the only game in town for systems programming languages.
If you opt into garbage collection for the whole program. That's not the same overhead as C++. (I know you believe that GC is faster than manual memory management, but let's sidestep that debate by defining "the same overhead" as "the same memory management practices that C++ uses, with the same tradeoffs".)
Modula-2 also uses manual memory management just like C.
So by using it, there is a whole class of C errors that are not exploitable:
- Buffer overflows
- Pointers that go astray, injure some critical data structure, only to die minutes later in another totaly unrelated place.
- Strings without null terminator
- No implicit conversions between types
- Proper enumerations
- Arrays are properly bound checked by default (unless explicitly disabled)
Still problems like memory leaks and double free exploits do prevail. However the set of possible exploits is surely smaller than C and C++ offer to hackers.
I have high hopes for Rust in the future, but Go just does not seem like a replacement for C++ in the places where it excels (although many people do use C++ in places where they could probably have used say python, and Go is a reasonable alternative to Python).
Instead, I think, you'd write a bunch of fast browser component libraries in C (which is what already happens now), and then glue them together in Go to produce a nice, static, easily-deployed binary for each platform.
You know how in, say, games, you see people writing (needs-to-be-performant) mechanism in C, and then scripting (can-be-slower) policy in Lua? Go excels in this same niche[1] and the results from Go, unlike from Lua, can be treated (and debugged!) as native linked-in code.
I'd still rather the whole browser was written in Rust, though; those libraries that are right now written in C for performance could do with fewer crashes.
---
[1] ...if-and-when it's the policy-writer who compiles and links the binary. If FooCorp ships a game engine as a complete executable binary, and you're expected to just write policy hooks in Lua against the FooCorp's "framework", then there is an equivalent workflow for Go--you'd produce a dynamic library that the executable dlopen()s--but the result doesn't have the same sort of elegance. (You don't get to code-sign the resulting complete executable yourself, for example.)
Why not? AOS has one written in Active Oberon, which is quite similar to Go feature wise.
The main differences is that Active Oberon's SYSTEM package is more powerful than Go's unsafe and support for untraced pointers. The later can also be achieved in Go via a mix of syscalls and unsafe.
Go is just another language that ignored the last 50 years of programming language advances in order to not scare C programmers who are afraid of learning anything new.
"sensible" is all in the eye of the beholder, once you have your computer hacked your priorities may change..
> but few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
And THAT is the issue, security CANNOT be an afterthought.. Note that significantly slower doesn't mean slow, PC's CPUs are very, very fast.
> few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
I can't tell if this is a joke. You know practically website is constantly running the shittiest JS you can imagine (and sometimes Actionscript), right?
Even if the language somehow can't handle implementing a certain task efficiently, you could still make a separate OS process for say, decoding the video stream, and passing it back to the safe code.
If you think there is a technical reason that browsers/OS today are written in C/C++ you are wrong. The reasons are purely circumstantial. Also note that most C/C++ coders aren't aware that other languages even exist or are practical, so good luck getting them to switch.
So, the essential. If Haskell is "better" than someting else, then, by definition, it's easier to write good software in it. I wrote about my personal experience in the lost reply, but it doesn't really matter. The question is, why people who believe that Haskell is better for writing browsers won't prove it themself? By doing, I mean. I haven't seen a popular (lets take it as quality measure) browser, P2P client, feature-full messaging client/service or image editing app written in Haskell. Only pandoc, Xmonad, Yi and countless links to haskell.org success-story page, which isn't working app. Actually, it's true for any language, but nothing is mentioned as often as Haskell.
Heh, I use tor, and it just took me over 10 tries to login to reply to you (changing exit nodes to find one that isn't blocked, etc).
If you don't like Haskell for some reason, replace it with something else. Heck, a browser in pure JS would be preferable to a browser in C (note: it doesn't count if you have 50 libraries implementing audio/visual/crypto/compression written in C and linked into the same address space as the JS).
But it takes huge capital to implement a browser, and you'll still have the other issues like CSRF, clickjacking, phishing (each of which have been solved ages ago by waterken btw: http://waterken.sourceforge.net/web-key/), X.509 (which has been solved by tor hidden addresses and other systems like it), and other mystical issues that arise because of how incoherently-designed the web is.
Anyways, why do you think C would be any better for implementing a browser than any of these languages?
Yes, I know that writing a browser or anything serious is a lot of work. But it's productive, right? And quite many people do that in their free time… well, maybe not a browser (at least I haven't heard about that), but at least bittorrent clients, p2p network layers, feature-full messaging clients, firewalls, anything. Their authors started them alone in their spare time, for free. And they are written in C, C++, Python, sometimes Java. Why? Obviously, because their authors for some reason chose that language. They decided it's better. And nothing is written in Haskell. It was like that 5 years ago, Haskell evolved, became much more popular (actually I even do know a company that uses it in production, but it's not the point) and that statement is still true. So every time somebody starts bragging about how all-powerfull Haskell is and how stupid are people that actually write something to choose C++ instead, I can help but ask: so why won't you prove on practice that Haskell is better? Because, once again, for PL "to be better" is to make its user more productive and more able to write quality software. So, it seems to me that this "why won't you…" argument (which is pretty ugly in many cases) is fair enough in this case.
Now, I don't want to rewrite what I said about languages you mentioned, because it was pretty long. So, in short. ML — dead. Python — way too slow (if "browser" is everything including engine, not some shell around webkit). Erlang — just isn't built for that purpose (it's dynamic, highly concurrent "built to fail" language — are you even serious?!). Java — well, maybe, but it's not the perfection itself.
I can't even be bothered to look at what who is using what language for, so I'm not going to debate this... I use Haskell every day, as well as a bunch of other languages, some of which nobody heard of, and they all work fine.
> so why won't you prove on practice that Haskell is better?
Because I don't care?
> Because, once again, for PL "to be better" is to make its user more productive and more able to write quality software.
Which you can easily do in Standard ML with no surprises, because it's a straightforward simplistic language and it's been like that since the 70's. But you dismiss it because it's not popular or something (despite being used by hundreds of thousands of people).
> Python — way too slow
Do you have any results to show this? I already pointed out, even if the language is too slow, you can just run C or assembly or whatever in a separate address space for each CPU intensive process. Your claim implies that the latency of passing the output of the worker in C/assembly back to Python (and passing new input from Python to the worker) would be too high.
> Java — well, maybe, but it's not the perfection itself.
So... you agree?
> I wonder if it is worth it to learn
Well, you may try anyway. It's pretty interesting experience. Many people claim that after you are "enlightened" you'll hate other languages. Seems that I'm still not enlightened. It's nice to write parsers and similar stuff in it, but I couldn't find an area where it would be clearly better to use Haskell than some alternative I'd normally choose. If you don't need hight performance and your product is, say website, than some Python/Ruby seems more convenient (mostly because of many good libraries and instruments for them). Writing GUI app? GUI bindings for Haskell are pretty awful and unnatural. Real time? Sorry, optimizing Haskell is so unintuitive that I can't consider it. Plus it has big runtime and is lazy. Something hightly concurrent? Not better than Erlang. So, I came up with that it only suites well for writing Haskell compiler and there already is a couple of them.
Did you venture into web dev a bit? I find the 'once it compiles it usually is correct' bit tempting, as I have a hunch that this might be more efficient that writing tons of unit tests in a language like Ruby.
I've never had a problem with GUI coding in Haskell... Here's a few lines of some WX code I wrote:
p <- panel f []
startButton <- button p [text := "start"]
stopButton <- button p [text := "stop"]
set p [layout := row 5 [widget startButton, widget stopButton]
> Real time?
what.
> Sorry, optimizing Haskell is so unintuitive that I can't consider it.
I agree that space leaks are hard to fix / prevent, but meh, other mainstream languages have other problems that sum up to the same amount of pain.
> Plus it has big runtime and is lazy.
Big runtime? I'm not sure what you mean by this... In contrast, my web browser usually occupies a few hundred megabytes for trivial tasks.
> Something hightly concurrent? Not better than Erlang.
I'm not sure about that. Erlang has some very weird stuff going on (http://stackoverflow.com/search?q=user%3A2213023+[erlang]), and in Haskell you can program actor style pretty easily with channels/pattern matching, and then there's CSP, STM, Data Parallel Haskell, etc.