16 ms·

JavaScript Is C

244 points by pcr910303 7y ago

Aeolun 7y ago
I just wish there was a decent way around Javascript, but even With TypeScript, React, Redux and Redux-Saga, basically using everything we can to give some structure to the application, it is still a clusterfuck. I really, really enjoy the paradigm of the basic HTML application because so many problems just magically go away.
0xdead 7y ago
The author should have shown some code, because it certainly feels like they're talking out of their ass. "Javascript is C" wtf does that even mean?
jackmaney 7y ago
...it literally is not.
butterisgood 7y ago
A love letter to Elm in disguise with rationale. I like it!
olingern 7y ago
Everyone loves a good Javascript punching bag but I would argue that the language/ecosystem has the most inertia and positive change within it. It's not perfect and it's exhausting at times, but I'm confident that the language will continue to move towards something more robust and ergonomic. One more thing to note. From the post: > In a C application, try as hard as I may, at the end of the day I am always on my own, making sure the invariants I need for memory safety hold. In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer. I think if you're always leaning on a compiler for correctness, maybe your problem doesn't reside in the static vs dynamic debate.
- gerbilly 7y ago
  In the computer world, the worst thing often ends up winning. The reason? Market forces are more powerful than technical features. This means that if you rush a bad implementation out the door and it gets adopted by the masses, the network effects will ensure your bad solution wins. Meanwhile, competitors that are working on a high quality competing language or product will be later to market and miss the train. See: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
  - t0astbread 7y ago
    It should be noted that because of market adoption, an ecosystem can grow to have more value for the end user than a more complete but new competitor.
hootbootscoot 7y ago
war is peace. freedom is slavery. javascript is c luckily the rust evangelism strike force saved us from errors. once we rewrite everything in rust and webasm, the world will shine with perfection. posts like this kinda obviate n-gates raison-de-etre... but at least we all agree that js stinks/long live js
- hootbootscoot 7y ago
  I guess I just accept es5 for the necessary evil it is. i'm not sold on the orm approaches. typescript, reason, svelte, etc, all bring interesting ideas to the table. end of the day, you can probably eliminate a lot of cruft from your ui before actually being required to resort to these things. I still include tag mithril.min.js and stuff like that plenty, and the world didn't stop nor did I die writing hyperscript. or js. or html. or sql. or whatever...
  - hootbootscoot 7y ago
    of course, the ultimate loop is simply to use some barely-functioning type-inferred js to c++ driver to emscripten to webasm. that should satisfy the minimalist simple-life cravings of node devs.
- xkcd-sucks 7y ago
  Honestly a good clean rewrite might benefit a lot of software though, even if in the original language
known 7y ago
https://en.wikipedia.org/wiki/Apples_and_oranges https://en.wikipedia.org/wiki/Apples_and_oranges
tempodox 7y ago
That's an interesting fact about Elm I wasn't especially aware of. Maybe I should have a closer look at it, even though web front-end stuff is not my cup of tea.
zoomablemind 7y ago
This reminds me of my early C days dilemma: "Check for a disallowed NULL pointer argument on function entry or just trust that it will have a valid value?" And a mixed feeling that would settle after putting an assert there. Eventually, one develops a "pragmatic trust", appropriate to the level of interactions in the code. After all a state change is a kind of input resulting from an interaction. Some interactions are more trusted than others. Asserting reality after every handshake is not going to make one feeling safer. Operating in a trusted environment and understanding and upholding its premises does add one more member to enforce that "safety in [sane] numbers".
seemssilly 7y ago
So the author can't solve a problem, goes ahead to say that javascript is c because of one situation, then promotes rust by the end. All with a clickbait title to boot. I'd be more angry but this type of formula for an article is used so often now that it should be expected. I can't wait until people figure out that the individuals that aren't competent enough to handle C's issues, aren't going to be competent enough to handle Rust's either. Hopefully the Rust hype train dies soon. There is simply too much bandwaggoning involved in this language to keep bias out of the equation when considering using it to solve a problem.
- shpongled 7y ago
  Have you given Rust an honest try yet? I thought it was a hype train too at one point, but I started using it, realized that the hype is well founded and never looked back.
  - seemssilly 7y ago
    I haven't but that wasn't my point at all when saying that. It is on a hype train, whether that hype is justified or not is not what I was trying to get at. What I was saying was that this hype and massive surge in use and publicity causes an inevitable bias which clouds judgement when deciding whether or not to use it. That crowd of programmers that seem to hop on every computer fad, the ones that have been adding hashtag reactjs to their twitter posts for the past year, they're probably going to choose rust regardless of whether or not it should actually be used. The bitter contrarian is probably deciding not to use it because he's sick of seeing it mentioned in every other tech blog post in the past year. As soon as this hype dies off, both of these groups can move on and hopefully decide whether rust is actually worth using for whatever they need done. I would use it if it's the right tool for the job. I just want to stop seeing it mentioned 20+ times a day and snuck into blog posts that started off as critiques/comparisons of two other languages.
    - chriskrycho 7y ago
      I don't think you understood the blog post (which is presumably my failure as an author; it was just an off the cuff post and I didn't edit it especially carefully). The point is not to compare JS and C (interesting though that would be) but to note ways in which both of them may be slowly superseded by languages which target the same environments they do but allow much more developer confidence along certain axes—and, in my experience, therefore also a better developer experience and higher productivity along those axes. The whole point was that Rust, Elm, etc. can and do prevent whole classes of problems that are difficult (at best) to eliminate when writing C or JS respectively—Rust and Elm (and F and OCaml and Haskell and Idris and…) were essential to the point I was getting at. One of the challenges for dealing with hype is that things which are legitimately really good tend to get hype, but things which get hype aren't necessarily good. In my experience, Rust is actually really good (so much so that I ran a podcast about it for a couple years). So are lots of other things. It's not perfect, by a long shot. But while there's some of the people hyping it because it's cool phenomenon—that's real!—people also get excited by finding a tool they really enjoy, that solves real problems they experienced previously.
FpUser 7y ago
1) JavaScript is NOT C. 2) There is nothing wrong with C. It was DESIGNED to service specific needs and does that just fine 3) I think this obsession with "safe languages" is being taken too far. Safety does not come free, we pay for it. Mostly in performance which is a valuable "feature" for many types of software. Not gobbling all computer memory running "Hello world" helps too. Besides automatic memory management and "everything is immutable" does not really make software safe either.
- timw4mail 7y ago
  3) It's not "safe languages", it's "memory safe languages". The whole point is to make very common security vulnerabilities due to unsafe memory usage much less common. Rust and garbage-collected languages have memory safety. C/C++ do not. That's the whole point.
  - FpUser 7y ago
    C/C++ have enough tools to detect and get rid of memory leaks. Quite frankly memory safety ceased being a practical problem to me years ago.
    - timw4mail 7y ago
      That assertion would carry much more weight if not for the constant barrage of security vulnerabilities due to memory issues.
eej2ya1K 7y ago
C feels good, JavaScript doesn't. Rust is extremist propaganda disguised as an admittedly pretty good programming language.
rob74 7y ago
Even though the first paragraphs are about JavaScript and C, I already had a hunch that it would turn out to be about Rust in the end :D
- ethagnawl 7y ago
  > ... it would turn out to be about Rust The post is not _about Rust_. It _mentions_ Rust and it also _mentions_ Elm, as examples of higher-level, safer languages and uses them to demonstrate some of the benefits this category of languages offers.
- enriquto 7y ago
  It's the all-encompassing Rust Evangelist Strike Force!
  - mxcrossb 7y ago
    You could tell as soon as you read the top of the page and saw it was a blog about theology :)
    - xenocratus 7y ago
      Do you have a moment to talk about our Lord and Saviour, Rust?
- chriskrycho 7y ago
  Clearly I should have gone with Idris and F*.
truth_seeker 7y ago
> Earlier this week, I was working on a problem in the Ember app where I spend most of my day job, and realized: JavaScript is the same as C. No sir, you have realized that Ember is promoting JS as C. Throughout the whole article the author is trying to shift responsibilities to compiler or he is seeking a solution which is closer to DSL. If compiler or typechecker disciplines are more important, why not explore eslint plugins and typescript advance types and use them appropriately before jumping directly to new programming language and relatively limited community ?
- jdance 7y ago
  I would guess whatever you do on top of typescript, its still a superset of javascript, which will always have holes in it. Its that 100% guarantee that the author is looking for, and that Elm provides. The difference between 99% and 100% is enormous in my experience. A part of your brain that constantly evaluated the situation can now be totally at rest, spending that energy at other things. Note that I have not used Elm myself, but looking at it I get the point. I have the 99/100% experience in other things
  - tekkk 7y ago
    Yes, precisely so. Type definitions are as good as the programmers who wrote them, and since humans are imperfect they make mistakes. After you have defined your types wrong, there are devious bugs in your code that you have no way of knowing (until you step on that mine and the program hopefully crashes). Although every language by design is mostly bug-free, it's that in JS/TS there is a much greater human factor (similar to C/C++) that just adds a large error margin for the correctness of the application. Especially when there are very loose runtime guarantees for type-safety, there is always a chance for something ugly to happen.
  - Touche 7y ago
    Doesn't Rust have unsafe?
    - Sindisil 7y ago
z3t4 7y ago
I like to use something often called "regression tests", that whenever I find a bug, before fixing it, I write a test that would detect that bug. Confirms that the test catches the bug, then write the fix, and re-run the test to confirm that it's fixed. All tests are then run automatically before deployment. Also if you already know those 2% of the code that can go wrong, also write tests for those! The only disadvantage with tests are that writing the tests can be more difficult that writing the actual code. Another strategy I use is defensive programming; "throw an error if the invariant wasn’t properly maintained" used together with code coverage and testing. So when the tests run the code, (or during manual testing) those defenses would trigger. I leave the defense on even in production, and log all errors (if on server) or generates a bug report, that users can submit with the click of a button, if in a user interface. The problem with defensive programming is that even if you have a call stack and state, it can still be hard to figure out the steps that lead up to the bad state. So you need some levels of logging. I do not consider testing (TDD) or defensive programming a band-aid for bad language design, they catch many sorts of issues, not only type errors. Even if your code is very beautiful, you still want to verify that it works. Although demoing the app, or putting the app in-front of thousands of users, is probably the most effective way of finding issues.
- josephg 7y ago
  I used to make this argument, but I think I was wrong. I sort of hate working in javascript projects I’ve written with a million tests, because if I want to refactor something, it takes 3x as much work because of all the tests I need to rewrite. Lately I’ve been really enjoying typescript and rust. The ability to write code and if it compiles run it and have it be correct is like a cool breeze on a summer day. In typescript I need to write fewer tests (because the compiler catches bugs that I would need a unit test for in JS). But also, when I refactor something the compiler gives me a list of all the places in my code which I need to update. In JS I have learned to worry about lingering bugs that I just forgot to write unit tests for or something. With a typed language, that fear is (mostly) gone. It’s a lovely quality of life improvement, and it noticeably improves my velocity.
  - 7777fps 7y ago
7777fps 7y ago
I think it's fair to say that, "Javascript's packaging is as bad as in C". While ES6 modules make minor improvements in syntax, the entire npm ecosystem relies on commonjs resolutions which aren't that far under the hood to including header files wholesale. Then you have the build system which you have to know your way around babel, webpack, and a whole suite of arcane tools each of which with very fragile equivalents to make files with similar nonsense errors when builds fail. Javascript isn't C, but the ecosystem is a nightmare compared to modern languages with modern language features such as first class package management.
shakna 7y ago
I would happily argue that JavaScript is _worse_ than C. For example, this [0] is quite obviously outputting a string to the console, isn't it? (Hint: some of those seemingly random characters pull a double quote out of JS' leaky guts.) And whilst TypeScript can help by identifying some types... The syntactic difference between one type and another type can easily be hidden from the programmer. One mistake, one service sending one type when you expect another (we promise we will always send a fully-formed object or plain text, oops we sent a list), and you end up only hitting the error ten levels deep and not knowing how things got so badly mangled. Type safety is hard. Type safety in a language that desperately wants to be a string is nearly impossible. If you look at anything the wrong way, it will become something else. At least with C, if I try and treat something as a size_t it will try and behave like a size_t. It might not actually be the right type and cause problems that way - but the behaviour is within the expected bounds. [0] https://gist.github.com/shakna-israel/b0c1a5ef0171b265ce7f6ef479be7497 https://gist.github.com/shakna-israel/b0c1a5ef0171b265ce7f6e...
- tiborsaas 7y ago
  Does this make C++ a horrible language? https://gist.github.com/aras-p/6224951 https://gist.github.com/aras-p/6224951 Just because you can write horrible things in a language it doesn't mean it's bad. Just like you can drive your car to a wall doesn't mean your car sucks.
  - deleted 7y ago
    [deleted]
  - ekianjo 7y ago
    I think the parent was concerned about accidental unsafe behavior, not by design.
  - pjc50 7y ago
    > Does this make C++ a horrible language? As a C++ programmer from before it was standardised, I would happily say "yes". Unfortunately it has some properties which make it too useful not to use in some situations, and the default shared library linkage on most platforms only works for C or C++ style languages. Edit: no, it's worse than that, there's no truly reliable C++ ABI! See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402... Inter-linkage of C++ programs tends to be done over "extern C" ABIs, or "object broker" systems (COM, CORBA etc). Possibly the next closest system is C#'s MSIL, which is almost a first-class platform citizen on Windows, and allows you to interlink assemblies produced in different languages (F#, "managed" C++, VB). Even then it's capable of alarming confusion depending on whether you've used a "framework" or "core" version.
atilaneves 7y ago
> In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer. Also achievable, and far more easily, with a tracing GC. Do you know all those people worrying about memory safety in Lisp decades ago? Me neither.
- marijn 7y ago
  Not all invariants relate to allocation. Rust protects you from a whole class of shared-mutable-state issues that JavaScript and Lisp are zero help with.
  - atilaneves 7y ago
    > Rust protects you from a whole class of shared-mutable-state issues Rust is not alone in this. I think Pony is a good example.
- zaarn 7y ago
  Except in some situations you don't have a GC or can't afford one (hard realtime, embedded devices, osdev).
  - pjmlp 7y ago
    Hard realtime, I do agree, there you can even afford any kind of memory allocation, everything needs to be statically defined usually. Embedded devices, depends on the use case, PTC, Aicas, MicroEJ, Astrobe have plenty of happy customers. Same applies to OSDEV, Midori did not have any big problems powering a couple of Microsoft systems before the powers to be decided it wasn't going to be a Windows replacement.
    - jstimpfle 7y ago
      > Midori did not have any big problems powering a couple of Microsoft systems. I will believe that when I see the performance under load with my own eyes, and when I can convince myself that the code is not more cumbersome than manual memory management would be.
marijn 7y ago
Rust is also C, if the fact that you can't encode all possible invariants into the type system makes a language C. But this is a spectrum, not a dichotomy, and TypeScript falls somewhere way beyond C, but below Rust, in what you can statically encode. And Idris lies beyond Rust.
btschaegg 7y ago
I'm in the camp that sadly does not have easy options to choose a different language at work (I mainly work in C#), but I'm still very interested in learning new programming paradigms and techniques. From this view, and regularly having similar experience with code I have to dig up for whatever reason, I've come to wonder whether the argumentation on languages here doesn't ignore a very important aspect: The blogpost (as many before it) presents the process of understanding your code as a tooling problem. I slowly come to think that the real problem here is educating people to write understandable code that those tools really solve. I've wrestled with some horrible in house Java application multiple coworkers produced for quite some time now. It has mutable state everywhere and is full of hacks, bugs and race conditions, although the actual problem really isn't that complex. (It is so bad that it looks like management even might get past the sunk cost fallacy regarding a rewrite directly after it has been "finished"! I've never experienced that one so far.) After thinking it through for quite some time, I'm convinced that there's a very simple (and rather elegant) solution to this, but if you want to tackle such a project, you should at least know about immutable datastructures, record types, algebraic datatypes and the basic concepts of idempotency and CSP. But everytime I try to nudge someone in the dev team in the "right" direction, I feel considerable friction in this regard. So, more and more, I come to think of the biggest worth of languages like Rust, Elm, Clojure, Erlang and so on being that they force programmers to think in different ways (and grow in the process) -- something that gets handwaved away in other circumstances with "well, it has worked for me so far…".
- z3t4 7y ago
  I think most people learn those things by experience. Let them maintain their code for a while, and they will eventually discover why things like "mutable state everywhere" and "race conditions" are bad. It's only after they have felt the pain they are willing to buy the solution.
  - btschaegg 7y ago
    I would have followed the same reasoning a couple of years ago, but have since had the "pleasure" of working with people that have been producing this kind of code for multiple decades. At this point, I've grown more amazed at how good humans can ignore self-inflicted pain and more cynical when it comes to believing in their adapability. Though that obviously does not apply to everyone.
sn0n 7y ago
Isn't the real point something like: this is a paid advertisement for elm, check it out.
- jamil7 7y ago
  Did you read the article? It isn't an advertisment for anything.
lidHanteyk 7y ago
The analogy doesn't make sense; they analogize C to Rust, as ECMAScript is to Elm. I am forced to conclude that these are the only four Turing-complete languages that they know.
- Lapsa 7y ago
  Yeah. Analogy seems more harmful than useful. "Stuff changes, getting errors - must be C".
m00dy 7y ago
_INSERT_YOUR_FAVOURITE_JAVASCRIPT_TYPE_COERCION_HERE
mhd 7y ago
JavaScript is Fortran. Used to be Fortran66, now Fortran77, Ratfor is a thing again.
- vaxman 7y ago
  Let's not forget Fortran IV (RIP Mariner-1) --and Fortran 5 (ok lets https://youtu.be/cL_Ilhd7Odo https://youtu.be/cL_Ilhd7Odo)
mirekrusin 7y ago
Next week - "Haskell is C" - because you can write program that compiles and doesn't do what you want. Nobody ever claimed that flow/typescript magically makes your code bug free. It will help with stupid mistakes. It will help with invariants at the type level, but it won't guarantee anything because there are ways to supress it. It will not help with value/runtime invariants because it doesn't have any dependat-type constructs (you can use things like flow-runtime to get some extra help if needed during runtime, but it will be likely slow if you use it everywhere, maybe cherry picked places is good compromise, depends on what you're trying to solve). Things like immutable collections and/or better architecture should help.
- ylyn 7y ago
  The author isn't claiming that someone claimed that either. S/he's just saying that s/he likes Rust/Elm because they check more invariants than C/TypeScript. In other words, "no one said it does" isn't really a useful response to "I don't like X as much as Y because X doesn't do A but Y does."
  - yoz-y 7y ago
    They might not claim that but the article’s title and gist still is “JavaScript is C because of this one reason”. This kind of comparison is just not useful.
    - bovermyer 7y ago
      I disagree. It changed how I think about JavaScript a little. As such, it was useful for me. Be mindful that you do not mistake what we think for how we think.
      - yoz-y 7y ago
        I think the point the article makes is good, I just don't like how the comparison was made. I don't think the article would be of less value if the author dropped the "JavaScript is C" peppered all around it.
tybit 7y ago
I thought this was going to compare C and JavaScript as being imperfect languages that are ubiquitous as the Lingua Franca of their respective platforms, Unix and the web. I’d be interested in seeing that explored.
- chriskrycho 7y ago
  Oooh, that does sound like an interesting post. I also have some unpublished notes on the value of taking the “make JS/C better via tools etc.” path even when the other is available and why. It’ll likely generate less interest than this one—less provocative by a lot!—but it’s actually what I’m doing in my day job right now!
wruza 7y ago
tl;dr: No code was presented, but it feels like Ember was pushing unexpected arguments to a typescript function, messing it up. Author then goes all rust, hoping that it would catch broken invariant automagically, because it leaks no memory. Thus JS is C.
dingo_bat 7y ago
That would make javascript the greatest programming language to have existed.
larusso 7y ago
I would love to have an example of what exactly he is writing about. I spend most my time at the moment to rewrite some code from JS to Rust and still fight with invariants. I would like to know how to achieve the 100% safety. I know that I get most of the null pointer exception etc handled with Option and Result structs. But if you need to deal with string values etc the compiler can’t really help out when the value is not the one you’re expecting. And I also moved most of these to enums.
- jacamera 7y ago
  > I would love to have an example of what exactly he is writing about. Thank you. This such a nothing article with a clickbait headline.
  - dbtx 7y ago
    Also flamebait.
- shpongled 7y ago
  That is how I would handle that - you lex or parse your strings into an Option<Token> (or Result, etc), so that then all logic operating on the Token enum doesnt need to worry about whether it's a correct value - it's statically enforced. I personally find the most value out of sum types (enums with data) and the ability to use Option/Result with the try operator '?' for this kind of stuff, where you can float errors up the call chain
  - larusso 7y ago
    Ok I kind of doing that already. The main issue I have is that some data comes from configuration and I can’t create static values for those (URLs for example). Thanks
jonny383 7y ago
Enough with the click-bait titles already!
volument 7y ago
This is nice. I have always wanted to be a C programmer. Now I can just stick to JavaScript and take all the same credit.
keithnz 7y ago
Tl;DR; some pattern in language X seems similar to language Y therefore X ~= Y . Argue why said pattern makes it hard to program in language X or Y, posit language A and B as saviors. I find it hard to be charitable to these kind of articles. Not that I disagree with the problems expressed, or the advantages of certain languages making certain guarantees. Everything is a tradeoff, and I think you have to be very aware, contextually, what exactly are you leveraging in order to get a certain result. That extends beyond the product itself to things like lifetime, and human factors. I'd like to see these kind of articles more of the "Consider A || B given these kinds of conditions, beware, this may not be suitable for reasons H I J...".
- chriskrycho 7y ago
  I actually strongly agree with this. Notably the post doesn’t say anything about what you should choose in a given context. I’m in a context right now where I support a pure JS (not even TS yet!) app, and while a colleague and I occasionally joke about rewriting it in Elm, that’s literally a non-starter in reality (and all I’d never suggest it in reality!). Most of the comments here seem not to have grasped that the basic point of the post is that advances in programming language design—here, specifically around types—can make for real differences in your confidence when shipping. And that’s valuable! It’s also not the only value… but then, I never said it was, either.
flohofwoe 7y ago
Oh, he's just trying to sell Rust ;) IMHO, Javascript is the C++ of dynamic languages. It suffers from similar early bad design decisions, which now a "committee" tries to fix by piling layer upon layer of complexity upon the broken base without ever being able to undo those early bad decisions. Actual C is a clean and simple language both compared to Javascript and C++.
- mac01021 7y ago
  I don't think thw committee's options are really so limited. They could totally have defined a JavaScript 2 not backward compatible with JavaScript 1. Browsers, of course would have then had to support both, but who cares? Especially if there were a good FFI between the two, noone would have been inconvenienced (except browser developers)
  - fermuch 7y ago
    Wasn't that what Dart tried to do?
- throw_m239339 7y ago
  > Javascript is the C++ of dynamic languages LOL, Have you ever heard of something called PHP? > Actual C is a clean and simple language both compared to Javascript and C++. Why do people keep on calling C "simple"? C isn't simple it's basic, it is absolutely not simple to use at all, and given the mess around macro and pre-processing, it wouldn't call it clean either.
n0mad01 7y ago
JavaScript = JavaScript C = C JavaScript Is C = clickbait
- mlvljr 7y ago
  above = underappreciated
roenxi 7y ago
C was famously well designed. The problems it was well designed for have disappeared and its good ideas are so well understood that, like many great early works, they are cliches that can no longer be recognised for their brilliance because everyone is doing that. C's flaws are real, but they exist in the context of that design. For example, C has bad memory management because it was built when programmers had kilo- to mega- bytes to play with and needed perfect control. I'm not sure anyone could ever accuse anything related to the internet of being 'designed'. Even being standardised is a stretch. Javascript isn't C, because C is an extremely focused attempt to solve specific problems. Javascript simply does not attempt to tackle the same problems as C and it doesn't attempt to tackle them in the same way. It may be that they are both fail to solve the big problems in web development, but that is not really a thing worth comparing languages on.
- notacoward 7y ago
  > like many great early works, they are cliches This, a thousand times. It's just so easy for people to fall into the trap of thinking the current list of things to do or avoid has always been obvious. The path is always obvious after a million people have trodden it. But at one time it wasn't. At one time people had to figure out things we now take for granted - like network APIs or concurrent programming models or, most relevantly, memory management. At the time manual management of object lifetimes was the only feasible option for a systems programming language, and it was feasible in part because control flows were simpler. Yes, even in things like OS kernels. They were kept simple by design in part to keep lifetime management tractable. Many of the things that make that approach non-viable today - e.g. massive concurrency, callbacks, exceptions - weren't part of the idiom then. They were irrelevant to C's design. C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. It might or might not be relevant today, but C was better designed in its context than anything most of its modern critics have ever designed (or will design) themselves.
  - laumars 7y ago
    > C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. I don't think that's a fair comment. Pl/I wasn't really the same domain as C and there were other alternatives to PL/I (such as FORTRAN, COBOL, ALGOL, Simula, LISP etc) In fact by the time C was released, there were already literally dozens of programming languages. And C itself an evolutionary progression because it took ideas from B, ALBOL and a few others. Also Pascal pre-dates C as well. I don't mean the following as a criticism against C because I do quite like the language but it does sometimes feel like it's put on a pedestal because it ended up dominating the industry -- either directly or via other languages heavily inspired by C. I do wonder if we've be seeing the same rose-tinted comments had UNIX been based on Pascal and Object Pascal not lost to C++.
GayestShitEver 7y ago
Faggot.
tetron 7y ago
And TypeScript is C++ for the JavaScript ecosystem, with all the good and bad things that implies.
- chriskrycho 7y ago
  I think this is exactly right! I didn't go back and add it to the article when it later occurred to me, because this was just a "thinking out loud" kind of post, but the exact same analogy occurred to me.
brlewis 7y ago
This could really use an example of an invariant that couldn't be elegantly enforced with property descriptors[0] and decorators[1]. Without such an example it's just flamebait. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html
chriskrycho 7y ago
It's pretty obvious that people are reacting to the headline without having actually internalized the content of the post. Fair, I suppose: it was a bit wild of a title, and the post was pretty off the cuff. This is the bit I really wish people would take away from it, though: > Neither of those is a guarantee I won’t have bugs. (A compiler that could guarantee that would have to be sentient and far smarter than any human!) Neither of them means I can’t intentionally do stupid things that violate invariants in ways that get the program into broken states from the user’s point of view. But both of them give me the tools and the confidence that I can absolutely guarantee that certain, very important kinds of invariants hold. We’re not looking for an absence of all bugs or a system which can prevent us from making any kind of mistake. We’re looking to be able to spend our times on the things that matter, not on minutiae the computer can check for us.
- carapace 7y ago
  > We’re not looking for an absence of all bugs or a system which can prevent us from making any kind of mistake. (Some of us are looking for that.)
  - chriskrycho 7y ago
    Indeed! Thus the Assumed Audience header at the top of the post! It's unreasonable to expect anyone to qualify everything they say in every blog post they right, I think. ;) See also: https://v4.chriskrycho.com/2018/assumed-audiences.html https://v4.chriskrycho.com/2018/assumed-audiences.html
- brlewis 7y ago
  An example would have gone a long way toward helping people internalize.
pier25 7y ago
The problem with Elm is that you end up writing a lot of code. Check this comparison of real world complete projects (not to-do MVC examples): https://www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/ https://www.freecodecamp.org/news/a-realworld-comparison-of-... Almost 3 times more loc than Svelte. I know that loc is not the ultimate measure of verbosity, but still.
carapace 7y ago
" If you have only ever programmed in C/C++/Java and Lisp and scripting languages, you have been sitting in a corner your whole life. Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language." ~ Frank Atanassow, "Some words of advice on language design" http://lambda-the-ultimate.org/node/687#comment-18074 http://lambda-the-ultimate.org/node/687#comment-18074 Fuller quote: > Go study Scheme and Prolog and ML and Haskell and Charity and Lucid Synchrone and OBJ and Erlang and Smalltalk. Look at Epigram or Coq or HOL or LEGO or Nuprl. Aside from Java, these are the important ones. If you are familiar with all of these, then you are in a decent position. If you have only ever programmed in C/C++/Java and Lisp and scripting languages, you have been sitting in a corner your whole life. Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language. (Scheme itself is only interesting for hygienic macros and continuations.)
- kazinator 7y ago
  If you think Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language, you've been sitting in another corner all your life, one possibly not as well illuminated as the C/C++/Java corner.
  - carapace 7y ago
    Well, I don't think he's being literal. He's saying (I think) that all of {C, C++, Java, Perl, Python, Ruby, PHP, Tcl, Lisp, Go, etc...} are of an ilk when considered against the wider realms of programming languages. In other words, they are each more similar to each other than any of them are to, say, Prolog.
stjohnswarts 7y ago
Meh it's 80% coder and 20% language
sundarurfriend 7y ago
The author means the title in a specific way that they explain in the article, so it's somewhat disappointing to see the comments taking it as either just C-bashing or saying "JS is good for some things" as if the article said it isn't. Some people here might remember the mental shift from programming in old school BASIC to doing it in C or another procedural language; having functions as a tool gives you certain guarantees and allows you to program on a different mental landscape. The author is talking about a similar mental shift here, and saying that JS and C are similar to him in that they require him to program in the older landscape. This kind of thing is something we as programmers experience often in many levels, and something we should be able to empathise with - whether we agree or vehemently disagree with it, we can at least start by understand the sense in which the author is writing the article.

244 points by pcr910303 7y ago

I just wish there was a decent way around Javascript, but even With TypeScript, React, Redux and Redux-Saga, basically using everything we can to give some structure to the application, it is still a clusterfuck. I really, really enjoy the paradigm of the basic HTML application because so many problems just magically go away.

0xdead 7y ago

The author should have shown some code, because it certainly feels like they're talking out of their ass. "Javascript is C" wtf does that even mean?

jackmaney 7y ago

...it literally is not.

butterisgood 7y ago

A love letter to Elm in disguise with rationale. I like it!

olingern 7y ago

Everyone loves a good Javascript punching bag but I would argue that the language/ecosystem has the most inertia and positive change within it. It's not perfect and it's exhausting at times, but I'm confident that the language will continue to move towards something more robust and ergonomic. One more thing to note. From the post: > In a C application, try as hard as I may, at the end of the day I am always on my own, making sure the invariants I need for memory safety hold. In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer. I think if you're always leaning on a compiler for correctness, maybe your problem doesn't reside in the static vs dynamic debate.

gerbilly 7y ago
In the computer world, the worst thing often ends up winning. The reason? Market forces are more powerful than technical features. This means that if you rush a bad implementation out the door and it gets adopted by the masses, the network effects will ensure your bad solution wins. Meanwhile, competitors that are working on a high quality competing language or product will be later to market and miss the train. See: https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
- t0astbread 7y ago
  It should be noted that because of market adoption, an ecosystem can grow to have more value for the end user than a more complete but new competitor.

hootbootscoot 7y ago

war is peace. freedom is slavery. javascript is c luckily the rust evangelism strike force saved us from errors. once we rewrite everything in rust and webasm, the world will shine with perfection. posts like this kinda obviate n-gates raison-de-etre... but at least we all agree that js stinks/long live js

hootbootscoot 7y ago
I guess I just accept es5 for the necessary evil it is. i'm not sold on the orm approaches. typescript, reason, svelte, etc, all bring interesting ideas to the table. end of the day, you can probably eliminate a lot of cruft from your ui before actually being required to resort to these things. I still include tag mithril.min.js and stuff like that plenty, and the world didn't stop nor did I die writing hyperscript. or js. or html. or sql. or whatever...
- hootbootscoot 7y ago
  of course, the ultimate loop is simply to use some barely-functioning type-inferred js to c++ driver to emscripten to webasm. that should satisfy the minimalist simple-life cravings of node devs.
xkcd-sucks 7y ago
Honestly a good clean rewrite might benefit a lot of software though, even if in the original language

known 7y ago

https://en.wikipedia.org/wiki/Apples_and_oranges https://en.wikipedia.org/wiki/Apples_and_oranges

tempodox 7y ago

That's an interesting fact about Elm I wasn't especially aware of. Maybe I should have a closer look at it, even though web front-end stuff is not my cup of tea.

zoomablemind 7y ago

This reminds me of my early C days dilemma: "Check for a disallowed NULL pointer argument on function entry or just trust that it will have a valid value?" And a mixed feeling that would settle after putting an assert there. Eventually, one develops a "pragmatic trust", appropriate to the level of interactions in the code. After all a state change is a kind of input resulting from an interaction. Some interactions are more trusted than others. Asserting reality after every handshake is not going to make one feeling safer. Operating in a trusted environment and understanding and upholding its premises does add one more member to enforce that "safety in [sane] numbers".

seemssilly 7y ago

So the author can't solve a problem, goes ahead to say that javascript is c because of one situation, then promotes rust by the end. All with a clickbait title to boot. I'd be more angry but this type of formula for an article is used so often now that it should be expected. I can't wait until people figure out that the individuals that aren't competent enough to handle C's issues, aren't going to be competent enough to handle Rust's either. Hopefully the Rust hype train dies soon. There is simply too much bandwaggoning involved in this language to keep bias out of the equation when considering using it to solve a problem.

shpongled 7y ago
Have you given Rust an honest try yet? I thought it was a hype train too at one point, but I started using it, realized that the hype is well founded and never looked back.
- seemssilly 7y ago
  I haven't but that wasn't my point at all when saying that. It is on a hype train, whether that hype is justified or not is not what I was trying to get at. What I was saying was that this hype and massive surge in use and publicity causes an inevitable bias which clouds judgement when deciding whether or not to use it. That crowd of programmers that seem to hop on every computer fad, the ones that have been adding hashtag reactjs to their twitter posts for the past year, they're probably going to choose rust regardless of whether or not it should actually be used. The bitter contrarian is probably deciding not to use it because he's sick of seeing it mentioned in every other tech blog post in the past year. As soon as this hype dies off, both of these groups can move on and hopefully decide whether rust is actually worth using for whatever they need done. I would use it if it's the right tool for the job. I just want to stop seeing it mentioned 20+ times a day and snuck into blog posts that started off as critiques/comparisons of two other languages.
  - chriskrycho 7y ago
    I don't think you understood the blog post (which is presumably my failure as an author; it was just an off the cuff post and I didn't edit it especially carefully). The point is not to compare JS and C (interesting though that would be) but to note ways in which both of them may be slowly superseded by languages which target the same environments they do but allow much more developer confidence along certain axes—and, in my experience, therefore also a better developer experience and higher productivity along those axes. The whole point was that Rust, Elm, etc. can and do prevent whole classes of problems that are difficult (at best) to eliminate when writing C or JS respectively—Rust and Elm (and F and OCaml and Haskell and Idris and…) were essential to the point I was getting at. One of the challenges for dealing with hype is that things which are legitimately really good tend to get hype, but things which get hype aren't necessarily good. In my experience, Rust is actually really good (so much so that I ran a podcast about it for a couple years). So are lots of other things. It's not perfect, by a long shot. But while there's some of the people hyping it because it's cool phenomenon—that's real!—people also get excited by finding a tool they really enjoy, that solves real problems they experienced previously.

FpUser 7y ago

1) JavaScript is NOT C. 2) There is nothing wrong with C. It was DESIGNED to service specific needs and does that just fine 3) I think this obsession with "safe languages" is being taken too far. Safety does not come free, we pay for it. Mostly in performance which is a valuable "feature" for many types of software. Not gobbling all computer memory running "Hello world" helps too. Besides automatic memory management and "everything is immutable" does not really make software safe either.

timw4mail 7y ago
3) It's not "safe languages", it's "memory safe languages". The whole point is to make very common security vulnerabilities due to unsafe memory usage much less common. Rust and garbage-collected languages have memory safety. C/C++ do not. That's the whole point.
- FpUser 7y ago
  C/C++ have enough tools to detect and get rid of memory leaks. Quite frankly memory safety ceased being a practical problem to me years ago.
  - timw4mail 7y ago
    That assertion would carry much more weight if not for the constant barrage of security vulnerabilities due to memory issues.

eej2ya1K 7y ago

C feels good, JavaScript doesn't. Rust is extremist propaganda disguised as an admittedly pretty good programming language.

rob74 7y ago

Even though the first paragraphs are about JavaScript and C, I already had a hunch that it would turn out to be about Rust in the end :D

ethagnawl 7y ago
> ... it would turn out to be about Rust The post is not _about Rust_. It _mentions_ Rust and it also _mentions_ Elm, as examples of higher-level, safer languages and uses them to demonstrate some of the benefits this category of languages offers.
enriquto 7y ago
It's the all-encompassing Rust Evangelist Strike Force!
- mxcrossb 7y ago
  You could tell as soon as you read the top of the page and saw it was a blog about theology :)
  - xenocratus 7y ago
    Do you have a moment to talk about our Lord and Saviour, Rust?
chriskrycho 7y ago
Clearly I should have gone with Idris and F*.

truth_seeker 7y ago

> Earlier this week, I was working on a problem in the Ember app where I spend most of my day job, and realized: JavaScript is the same as C. No sir, you have realized that Ember is promoting JS as C. Throughout the whole article the author is trying to shift responsibilities to compiler or he is seeking a solution which is closer to DSL. If compiler or typechecker disciplines are more important, why not explore eslint plugins and typescript advance types and use them appropriately before jumping directly to new programming language and relatively limited community ?

jdance 7y ago
I would guess whatever you do on top of typescript, its still a superset of javascript, which will always have holes in it. Its that 100% guarantee that the author is looking for, and that Elm provides. The difference between 99% and 100% is enormous in my experience. A part of your brain that constantly evaluated the situation can now be totally at rest, spending that energy at other things. Note that I have not used Elm myself, but looking at it I get the point. I have the 99/100% experience in other things
- tekkk 7y ago
  Yes, precisely so. Type definitions are as good as the programmers who wrote them, and since humans are imperfect they make mistakes. After you have defined your types wrong, there are devious bugs in your code that you have no way of knowing (until you step on that mine and the program hopefully crashes). Although every language by design is mostly bug-free, it's that in JS/TS there is a much greater human factor (similar to C/C++) that just adds a large error margin for the correctness of the application. Especially when there are very loose runtime guarantees for type-safety, there is always a chance for something ugly to happen.
- Touche 7y ago
  Doesn't Rust have unsafe?
  - Sindisil 7y ago

z3t4 7y ago

I like to use something often called "regression tests", that whenever I find a bug, before fixing it, I write a test that would detect that bug. Confirms that the test catches the bug, then write the fix, and re-run the test to confirm that it's fixed. All tests are then run automatically before deployment. Also if you already know those 2% of the code that can go wrong, also write tests for those! The only disadvantage with tests are that writing the tests can be more difficult that writing the actual code. Another strategy I use is defensive programming; "throw an error if the invariant wasn’t properly maintained" used together with code coverage and testing. So when the tests run the code, (or during manual testing) those defenses would trigger. I leave the defense on even in production, and log all errors (if on server) or generates a bug report, that users can submit with the click of a button, if in a user interface. The problem with defensive programming is that even if you have a call stack and state, it can still be hard to figure out the steps that lead up to the bad state. So you need some levels of logging. I do not consider testing (TDD) or defensive programming a band-aid for bad language design, they catch many sorts of issues, not only type errors. Even if your code is very beautiful, you still want to verify that it works. Although demoing the app, or putting the app in-front of thousands of users, is probably the most effective way of finding issues.

josephg 7y ago
I used to make this argument, but I think I was wrong. I sort of hate working in javascript projects I’ve written with a million tests, because if I want to refactor something, it takes 3x as much work because of all the tests I need to rewrite. Lately I’ve been really enjoying typescript and rust. The ability to write code and if it compiles run it and have it be correct is like a cool breeze on a summer day. In typescript I need to write fewer tests (because the compiler catches bugs that I would need a unit test for in JS). But also, when I refactor something the compiler gives me a list of all the places in my code which I need to update. In JS I have learned to worry about lingering bugs that I just forgot to write unit tests for or something. With a typed language, that fear is (mostly) gone. It’s a lovely quality of life improvement, and it noticeably improves my velocity.
- 7777fps 7y ago

7777fps 7y ago

I think it's fair to say that, "Javascript's packaging is as bad as in C". While ES6 modules make minor improvements in syntax, the entire npm ecosystem relies on commonjs resolutions which aren't that far under the hood to including header files wholesale. Then you have the build system which you have to know your way around babel, webpack, and a whole suite of arcane tools each of which with very fragile equivalents to make files with similar nonsense errors when builds fail. Javascript isn't C, but the ecosystem is a nightmare compared to modern languages with modern language features such as first class package management.

shakna 7y ago

I would happily argue that JavaScript is _worse_ than C. For example, this [0] is quite obviously outputting a string to the console, isn't it? (Hint: some of those seemingly random characters pull a double quote out of JS' leaky guts.) And whilst TypeScript can help by identifying some types... The syntactic difference between one type and another type can easily be hidden from the programmer. One mistake, one service sending one type when you expect another (we promise we will always send a fully-formed object or plain text, oops we sent a list), and you end up only hitting the error ten levels deep and not knowing how things got so badly mangled. Type safety is hard. Type safety in a language that desperately wants to be a string is nearly impossible. If you look at anything the wrong way, it will become something else. At least with C, if I try and treat something as a size_t it will try and behave like a size_t. It might not actually be the right type and cause problems that way - but the behaviour is within the expected bounds. [0] https://gist.github.com/shakna-israel/b0c1a5ef0171b265ce7f6ef479be7497 https://gist.github.com/shakna-israel/b0c1a5ef0171b265ce7f6e...

tiborsaas 7y ago
Does this make C++ a horrible language? https://gist.github.com/aras-p/6224951 https://gist.github.com/aras-p/6224951 Just because you can write horrible things in a language it doesn't mean it's bad. Just like you can drive your car to a wall doesn't mean your car sucks.
- deleted 7y ago
  [deleted]
- ekianjo 7y ago
  I think the parent was concerned about accidental unsafe behavior, not by design.
- pjc50 7y ago
  > Does this make C++ a horrible language? As a C++ programmer from before it was standardised, I would happily say "yes". Unfortunately it has some properties which make it too useful not to use in some situations, and the default shared library linkage on most platforms only works for C or C++ style languages. Edit: no, it's worse than that, there's no truly reliable C++ ABI! See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402... Inter-linkage of C++ programs tends to be done over "extern C" ABIs, or "object broker" systems (COM, CORBA etc). Possibly the next closest system is C#'s MSIL, which is almost a first-class platform citizen on Windows, and allows you to interlink assemblies produced in different languages (F#, "managed" C++, VB). Even then it's capable of alarming confusion depending on whether you've used a "framework" or "core" version.

atilaneves 7y ago

> In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer. Also achievable, and far more easily, with a tracing GC. Do you know all those people worrying about memory safety in Lisp decades ago? Me neither.

marijn 7y ago
Not all invariants relate to allocation. Rust protects you from a whole class of shared-mutable-state issues that JavaScript and Lisp are zero help with.
- atilaneves 7y ago
  > Rust protects you from a whole class of shared-mutable-state issues Rust is not alone in this. I think Pony is a good example.
zaarn 7y ago
Except in some situations you don't have a GC or can't afford one (hard realtime, embedded devices, osdev).
- pjmlp 7y ago
  Hard realtime, I do agree, there you can even afford any kind of memory allocation, everything needs to be statically defined usually. Embedded devices, depends on the use case, PTC, Aicas, MicroEJ, Astrobe have plenty of happy customers. Same applies to OSDEV, Midori did not have any big problems powering a couple of Microsoft systems before the powers to be decided it wasn't going to be a Windows replacement.
  - jstimpfle 7y ago
    > Midori did not have any big problems powering a couple of Microsoft systems. I will believe that when I see the performance under load with my own eyes, and when I can convince myself that the code is not more cumbersome than manual memory management would be.

marijn 7y ago

Rust is also C, if the fact that you can't encode all possible invariants into the type system makes a language C. But this is a spectrum, not a dichotomy, and TypeScript falls somewhere way beyond C, but below Rust, in what you can statically encode. And Idris lies beyond Rust.

btschaegg 7y ago

I'm in the camp that sadly does not have easy options to choose a different language at work (I mainly work in C#), but I'm still very interested in learning new programming paradigms and techniques. From this view, and regularly having similar experience with code I have to dig up for whatever reason, I've come to wonder whether the argumentation on languages here doesn't ignore a very important aspect: The blogpost (as many before it) presents the process of understanding your code as a tooling problem. I slowly come to think that the real problem here is educating people to write understandable code that those tools really solve. I've wrestled with some horrible in house Java application multiple coworkers produced for quite some time now. It has mutable state everywhere and is full of hacks, bugs and race conditions, although the actual problem really isn't that complex. (It is so bad that it looks like management even might get past the sunk cost fallacy regarding a rewrite directly after it has been "finished"! I've never experienced that one so far.) After thinking it through for quite some time, I'm convinced that there's a very simple (and rather elegant) solution to this, but if you want to tackle such a project, you should at least know about immutable datastructures, record types, algebraic datatypes and the basic concepts of idempotency and CSP. But everytime I try to nudge someone in the dev team in the "right" direction, I feel considerable friction in this regard. So, more and more, I come to think of the biggest worth of languages like Rust, Elm, Clojure, Erlang and so on being that they force programmers to think in different ways (and grow in the process) -- something that gets handwaved away in other circumstances with "well, it has worked for me so far…".

z3t4 7y ago
I think most people learn those things by experience. Let them maintain their code for a while, and they will eventually discover why things like "mutable state everywhere" and "race conditions" are bad. It's only after they have felt the pain they are willing to buy the solution.
- btschaegg 7y ago
  I would have followed the same reasoning a couple of years ago, but have since had the "pleasure" of working with people that have been producing this kind of code for multiple decades. At this point, I've grown more amazed at how good humans can ignore self-inflicted pain and more cynical when it comes to believing in their adapability. Though that obviously does not apply to everyone.

sn0n 7y ago

Isn't the real point something like: this is a paid advertisement for elm, check it out.

jamil7 7y ago
Did you read the article? It isn't an advertisment for anything.

lidHanteyk 7y ago

The analogy doesn't make sense; they analogize C to Rust, as ECMAScript is to Elm. I am forced to conclude that these are the only four Turing-complete languages that they know.

Lapsa 7y ago
Yeah. Analogy seems more harmful than useful. "Stuff changes, getting errors - must be C".

m00dy 7y ago

_INSERT_YOUR_FAVOURITE_JAVASCRIPT_TYPE_COERCION_HERE

mhd 7y ago

JavaScript is Fortran. Used to be Fortran66, now Fortran77, Ratfor is a thing again.

vaxman 7y ago
Let's not forget Fortran IV (RIP Mariner-1) --and Fortran 5 (ok lets https://youtu.be/cL_Ilhd7Odo https://youtu.be/cL_Ilhd7Odo)

mirekrusin 7y ago

Next week - "Haskell is C" - because you can write program that compiles and doesn't do what you want. Nobody ever claimed that flow/typescript magically makes your code bug free. It will help with stupid mistakes. It will help with invariants at the type level, but it won't guarantee anything because there are ways to supress it. It will not help with value/runtime invariants because it doesn't have any dependat-type constructs (you can use things like flow-runtime to get some extra help if needed during runtime, but it will be likely slow if you use it everywhere, maybe cherry picked places is good compromise, depends on what you're trying to solve). Things like immutable collections and/or better architecture should help.

ylyn 7y ago
The author isn't claiming that someone claimed that either. S/he's just saying that s/he likes Rust/Elm because they check more invariants than C/TypeScript. In other words, "no one said it does" isn't really a useful response to "I don't like X as much as Y because X doesn't do A but Y does."
- yoz-y 7y ago
  They might not claim that but the article’s title and gist still is “JavaScript is C because of this one reason”. This kind of comparison is just not useful.
  - bovermyer 7y ago
    I disagree. It changed how I think about JavaScript a little. As such, it was useful for me. Be mindful that you do not mistake what we think for how we think.
    - yoz-y 7y ago
      I think the point the article makes is good, I just don't like how the comparison was made. I don't think the article would be of less value if the author dropped the "JavaScript is C" peppered all around it.

tybit 7y ago

I thought this was going to compare C and JavaScript as being imperfect languages that are ubiquitous as the Lingua Franca of their respective platforms, Unix and the web. I’d be interested in seeing that explored.

chriskrycho 7y ago
Oooh, that does sound like an interesting post. I also have some unpublished notes on the value of taking the “make JS/C better via tools etc.” path even when the other is available and why. It’ll likely generate less interest than this one—less provocative by a lot!—but it’s actually what I’m doing in my day job right now!

wruza 7y ago

tl;dr: No code was presented, but it feels like Ember was pushing unexpected arguments to a typescript function, messing it up. Author then goes all rust, hoping that it would catch broken invariant automagically, because it leaks no memory. Thus JS is C.

dingo_bat 7y ago

That would make javascript the greatest programming language to have existed.

larusso 7y ago

I would love to have an example of what exactly he is writing about. I spend most my time at the moment to rewrite some code from JS to Rust and still fight with invariants. I would like to know how to achieve the 100% safety. I know that I get most of the null pointer exception etc handled with Option and Result structs. But if you need to deal with string values etc the compiler can’t really help out when the value is not the one you’re expecting. And I also moved most of these to enums.

jacamera 7y ago
> I would love to have an example of what exactly he is writing about. Thank you. This such a nothing article with a clickbait headline.
- dbtx 7y ago
  Also flamebait.
shpongled 7y ago
That is how I would handle that - you lex or parse your strings into an Option<Token> (or Result, etc), so that then all logic operating on the Token enum doesnt need to worry about whether it's a correct value - it's statically enforced. I personally find the most value out of sum types (enums with data) and the ability to use Option/Result with the try operator '?' for this kind of stuff, where you can float errors up the call chain
- larusso 7y ago
  Ok I kind of doing that already. The main issue I have is that some data comes from configuration and I can’t create static values for those (URLs for example). Thanks

jonny383 7y ago

Enough with the click-bait titles already!

volument 7y ago

This is nice. I have always wanted to be a C programmer. Now I can just stick to JavaScript and take all the same credit.

keithnz 7y ago

Tl;DR; some pattern in language X seems similar to language Y therefore X ~= Y . Argue why said pattern makes it hard to program in language X or Y, posit language A and B as saviors. I find it hard to be charitable to these kind of articles. Not that I disagree with the problems expressed, or the advantages of certain languages making certain guarantees. Everything is a tradeoff, and I think you have to be very aware, contextually, what exactly are you leveraging in order to get a certain result. That extends beyond the product itself to things like lifetime, and human factors. I'd like to see these kind of articles more of the "Consider A || B given these kinds of conditions, beware, this may not be suitable for reasons H I J...".

chriskrycho 7y ago
I actually strongly agree with this. Notably the post doesn’t say anything about what you should choose in a given context. I’m in a context right now where I support a pure JS (not even TS yet!) app, and while a colleague and I occasionally joke about rewriting it in Elm, that’s literally a non-starter in reality (and all I’d never suggest it in reality!). Most of the comments here seem not to have grasped that the basic point of the post is that advances in programming language design—here, specifically around types—can make for real differences in your confidence when shipping. And that’s valuable! It’s also not the only value… but then, I never said it was, either.

flohofwoe 7y ago

Oh, he's just trying to sell Rust ;) IMHO, Javascript is the C++ of dynamic languages. It suffers from similar early bad design decisions, which now a "committee" tries to fix by piling layer upon layer of complexity upon the broken base without ever being able to undo those early bad decisions. Actual C is a clean and simple language both compared to Javascript and C++.

mac01021 7y ago
I don't think thw committee's options are really so limited. They could totally have defined a JavaScript 2 not backward compatible with JavaScript 1. Browsers, of course would have then had to support both, but who cares? Especially if there were a good FFI between the two, noone would have been inconvenienced (except browser developers)
- fermuch 7y ago
  Wasn't that what Dart tried to do?
throw_m239339 7y ago
> Javascript is the C++ of dynamic languages LOL, Have you ever heard of something called PHP? > Actual C is a clean and simple language both compared to Javascript and C++. Why do people keep on calling C "simple"? C isn't simple it's basic, it is absolutely not simple to use at all, and given the mess around macro and pre-processing, it wouldn't call it clean either.

n0mad01 7y ago

JavaScript = JavaScript C = C JavaScript Is C = clickbait

mlvljr 7y ago
above = underappreciated

roenxi 7y ago

C was famously well designed. The problems it was well designed for have disappeared and its good ideas are so well understood that, like many great early works, they are cliches that can no longer be recognised for their brilliance because everyone is doing that. C's flaws are real, but they exist in the context of that design. For example, C has bad memory management because it was built when programmers had kilo- to mega- bytes to play with and needed perfect control. I'm not sure anyone could ever accuse anything related to the internet of being 'designed'. Even being standardised is a stretch. Javascript isn't C, because C is an extremely focused attempt to solve specific problems. Javascript simply does not attempt to tackle the same problems as C and it doesn't attempt to tackle them in the same way. It may be that they are both fail to solve the big problems in web development, but that is not really a thing worth comparing languages on.

notacoward 7y ago
> like many great early works, they are cliches This, a thousand times. It's just so easy for people to fall into the trap of thinking the current list of things to do or avoid has always been obvious. The path is always obvious after a million people have trodden it. But at one time it wasn't. At one time people had to figure out things we now take for granted - like network APIs or concurrent programming models or, most relevantly, memory management. At the time manual management of object lifetimes was the only feasible option for a systems programming language, and it was feasible in part because control flows were simpler. Yes, even in things like OS kernels. They were kept simple by design in part to keep lifetime management tractable. Many of the things that make that approach non-viable today - e.g. massive concurrency, callbacks, exceptions - weren't part of the idiom then. They were irrelevant to C's design. C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. It might or might not be relevant today, but C was better designed in its context than anything most of its modern critics have ever designed (or will design) themselves.
- laumars 7y ago
  > C was good for its time. Go ahead, take a look at PL/I and BLISS. See whether you'd rather program in those. I don't think that's a fair comment. Pl/I wasn't really the same domain as C and there were other alternatives to PL/I (such as FORTRAN, COBOL, ALGOL, Simula, LISP etc) In fact by the time C was released, there were already literally dozens of programming languages. And C itself an evolutionary progression because it took ideas from B, ALBOL and a few others. Also Pascal pre-dates C as well. I don't mean the following as a criticism against C because I do quite like the language but it does sometimes feel like it's put on a pedestal because it ended up dominating the industry -- either directly or via other languages heavily inspired by C. I do wonder if we've be seeing the same rose-tinted comments had UNIX been based on Pascal and Object Pascal not lost to C++.

GayestShitEver 7y ago

Faggot.

tetron 7y ago

And TypeScript is C++ for the JavaScript ecosystem, with all the good and bad things that implies.

chriskrycho 7y ago
I think this is exactly right! I didn't go back and add it to the article when it later occurred to me, because this was just a "thinking out loud" kind of post, but the exact same analogy occurred to me.

brlewis 7y ago

This could really use an example of an invariant that couldn't be elegantly enforced with property descriptors[0] and decorators[1]. Without such an example it's just flamebait. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://www.typescriptlang.org/docs/handbook/decorators.html https://www.typescriptlang.org/docs/handbook/decorators.html

chriskrycho 7y ago

It's pretty obvious that people are reacting to the headline without having actually internalized the content of the post. Fair, I suppose: it was a bit wild of a title, and the post was pretty off the cuff. This is the bit I really wish people would take away from it, though: > Neither of those is a guarantee I won’t have bugs. (A compiler that could guarantee that would have to be sentient and far smarter than any human!) Neither of them means I can’t intentionally do stupid things that violate invariants in ways that get the program into broken states from the user’s point of view. But both of them give me the tools and the confidence that I can absolutely guarantee that certain, very important kinds of invariants hold. We’re not looking for an absence of all bugs or a system which can prevent us from making any kind of mistake. We’re looking to be able to spend our times on the things that matter, not on minutiae the computer can check for us.

carapace 7y ago
> We’re not looking for an absence of all bugs or a system which can prevent us from making any kind of mistake. (Some of us are looking for that.)
- chriskrycho 7y ago
  Indeed! Thus the Assumed Audience header at the top of the post! It's unreasonable to expect anyone to qualify everything they say in every blog post they right, I think. ;) See also: https://v4.chriskrycho.com/2018/assumed-audiences.html https://v4.chriskrycho.com/2018/assumed-audiences.html
brlewis 7y ago
An example would have gone a long way toward helping people internalize.

pier25 7y ago

The problem with Elm is that you end up writing a lot of code. Check this comparison of real world complete projects (not to-do MVC examples): https://www.freecodecamp.org/news/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075/ https://www.freecodecamp.org/news/a-realworld-comparison-of-... Almost 3 times more loc than Svelte. I know that loc is not the ultimate measure of verbosity, but still.

carapace 7y ago

" If you have only ever programmed in C/C++/Java and Lisp and scripting languages, you have been sitting in a corner your whole life. Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language." ~ Frank Atanassow, "Some words of advice on language design" http://lambda-the-ultimate.org/node/687#comment-18074 http://lambda-the-ultimate.org/node/687#comment-18074 Fuller quote: > Go study Scheme and Prolog and ML and Haskell and Charity and Lucid Synchrone and OBJ and Erlang and Smalltalk. Look at Epigram or Coq or HOL or LEGO or Nuprl. Aside from Java, these are the important ones. If you are familiar with all of these, then you are in a decent position. If you have only ever programmed in C/C++/Java and Lisp and scripting languages, you have been sitting in a corner your whole life. Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language. (Scheme itself is only interesting for hygienic macros and continuations.)

kazinator 7y ago
If you think Perl, Python, Ruby, PHP, Tcl and Lisp are all the same language, you've been sitting in another corner all your life, one possibly not as well illuminated as the C/C++/Java corner.
- carapace 7y ago
  Well, I don't think he's being literal. He's saying (I think) that all of {C, C++, Java, Perl, Python, Ruby, PHP, Tcl, Lisp, Go, etc...} are of an ilk when considered against the wider realms of programming languages. In other words, they are each more similar to each other than any of them are to, say, Prolog.

stjohnswarts 7y ago

Meh it's 80% coder and 20% language

sundarurfriend 7y ago

The author means the title in a specific way that they explain in the article, so it's somewhat disappointing to see the comments taking it as either just C-bashing or saying "JS is good for some things" as if the article said it isn't. Some people here might remember the mental shift from programming in old school BASIC to doing it in C or another procedural language; having functions as a tool gives you certain guarantees and allows you to program on a different mental landscape. The author is talking about a similar mental shift here, and saying that JS and C are similar to him in that they require him to program in the older landscape. This kind of thing is something we as programmers experience often in many levels, and something we should be able to empathise with - whether we agree or vehemently disagree with it, we can at least start by understand the sense in which the author is writing the article.