7 ms·

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ig

• fossuser 8y ago
  I think syntax actually matters a lot more then people tend to give credit for in a language's success. I suspect this is why functional languages have struggled to became very popular while languages with C like syntax have added some functional features instead. The learning curve for imperative programming structure just seems easier for people to understand and work with.
  • cube2222 8y ago
    I don't agree. It's just that the familiar is easier. If you first teach someone programming with haskell, they'll have the same hard time switching to C.
  • another-cuppa 8y ago
    Yeah, but is it because people actually like the syntax? Some languages seem to be attractive to people right from the start, like Python. Some take a while to grow on you but then you realise their brilliance and don't want anything else, like Lisp. C isn't either of those.
    • dummyfunnytoo 8y ago
      FWIW, I've disliked the look of Python from the first time I saw it and loved Lisp-like syntax immediately. Can agree on C though.
    • AnimalMuppet 8y ago
      I don't know about that. I grokked C's syntax immediately, just from reading K&R, without actually having a compiler to try anything on. It just made sense to me. I suspect (but cannot prove) that certain languages and/or programming styles make more sense for certain people, and others do so for other people. (There also is almost certainly some bias toward familiarity.)
    • renox 8y ago
      Really? Python's syntax looks clean at first OK then later I realized that it has no variable declaration (and old memories of time lost in BASIC due to spelling errors start coming back), no static typing, is slow and isn't particularly multicore friendly .. uhm how about using Go instead? (No I don't know Go but I'm quite sure I can learn it without too much difficulties)
  • niftich 8y ago
    The impact of syntax is really undervalued. Syntax matters because many people are exposed to new languages through familiarity with other languages, as opposed to cramming a guide in isolation. And since programming languages are for humans, the cognitive load of understanding through reading and expressing through writing depends on one's ability to map the concepts to the code and vice versa. This is easier when similar languages look and -- through the power of abstraction, appear to -- work in similar ways. Go benefits from looking similar to the wider C family, while Erlang suffers from a syntactic heritage that never achieved as much prominence. The prevalence of languages in the syntactic style of C allows people unfamiliar with Go to be able to glean a lot of what's going on, and develop their understanding of Go-specific features gradually.
    • dnautics 8y ago
      Anecdotally, it was really difficult for me to convince myself to learn SQL specifically due to the syntax and the fact that unlike the imperative languages I normally use it was declarative.
    • int_19h 8y ago
      My simple smell test for language syntax readability is whether you can write a conditional statement with a multiline condition in it, without it looking ugly, and with the condition being clearly separate from the body. For example, in Lua or Ruby: if something() or other() then do_whatever() end It's very easy to read; your eye doesn't "stumble" anywhere it doesn't have a reason to. In C (and Java, C# etc), on the other hand: if (something() || other()) { do_whatever() } This makes for some confusing indentation, and now it's hard to distinguish what's condition and what's body! Sometimes people indent the entire condition to make it clearer: if ( something() || other()) { do_whatever() } but now you have holes in the middle which draw attention to that spot for no good reason. Or you can put ){ on a separate line: if ( something() || other() ) { do_whatever() } but so much punctuation hanging by itself is still an eyesore. And Python is hardly better: if ( something() or other() ): do_whatever() Go doesn't need the () in condition, so it's slightly more tolerable if you do that (but go fmt will object): if something() || other() { do_whatever() } But I'll take the Lua/Ruby syntax any day of the week. That's just one example. In retrospect, I think that C-style syntax was a bad idea in general, and adopting it as the "default syntax" across a large part of the industry was a monumental mistake. It favored compactness and speed of writing over readability and clarity. I really wish something like Modula or Ada would become the syntactic basis of modern languages today. I'd rather spend a few more keystrokes typing out things like "var" and "end", but end up with code that reads smoothly in a code review, or when debugging some ancient codebase.
  • ken 8y ago
    Syntax is a crucial component of any programming language. I would disagree, though, that there's anything inherently easier about imperative languages. Could it not be that it's simply more familiar to people today? People don't (IME) learn to program in school. They learn by futzing around with whatever free thing is on their computer. In the 1980's we had BASIC, and today we have JavaScript, and Python/Ruby/Java/C# also seem to be popular. At this point, imperative programming is winning because of path dependence. Nobody ends up using Erlang by accident. Once you get to concurrency, functional languages are clearly punching above their weight. I find it impressive that Go makes imperative programming work well here, but it still looks a bit old-fashioned to me. Is Go leading the pack by having a great concurrency model, yet with an imperative language that runs on bare metal? Or is it trying to hold back the tide, when almost the entire rest of the industry is solving concurrency by moving to functional languages running on a portable VM? I don't know.
    • fossuser 8y ago
      It's hard to disambiguate familiarity, but I'd suggest that imperative languages are more similar to spoken/written human language, particularly english. I'd suspect if you gave someone who didn't know lisp or java a simple program and had them try and explain what it was doing they'd have more luck with understanding the java syntax.
    • erikpukinskis 8y ago
      It seems like you’re saying the primitives don’t matter at all? I see three major programming styles: imperative, declarative, and functional. Declarative seems extremely popular these days (see Rails, CSS, Webpack, etc). My guess is it’s because it’s fairly obvious how to design a declarative API. You just think about what you’d want as an application programmer, write that down in English, and then target that with your implementation. These interfaces are totally unstable, and so they just degrade with time but they’re so easy to stand up they dominate the field. Imperative interfaces are a bit harder because you need to explicitly pass all of your data through every call. This is laborious at first and you have to do lots of refactoring of the interface as you implement it. API developers generally don’t like this feeling, and would rather have a stable interface to target and only futz with the internals. And it takes longer and requires more pondering when you can’t just reach directly into arbitrary parts of your code base and do whatever TF you want. And since APIs are usually released before they stabilize, application developers also don’t like seeing their interfaces move. Functional APIs are like the imperative ones but even moreso. Not only do you have to pass around data explicitly all the time, you have to model every intermediate state in your data explicitly too. This is even more constrictive, which just makes all of the above even worse. Personally, I think this pain pays off in the end, and I code in a purely imperative style deep in a haunted wood. The suffering over moving interfaces eventually leads to a stable interface that’s actually well thought out and composeable. Code can become “finished” whereas declarative code almost always just rots til it’s replaced. But in terms of “Don’t make me think” which is most pro developers dominant mode of working, there is a clear declarative > imperative > functional hierarchy. In theory a purely imperative or purely functional ecosystem could gain a kind of network effect of good code that would eventually outweigh the work slowdown.... your application code would be harder to write, but you’d be writing on top of a richer, more composeable library base. However we don’t seem to observe this in practice. My theory is that imperative and especially functional languages tend to attract masochists, who get yakshorn into radical experiments into purism, trying to bend every aspect of an ecosystem into a perfect Q-dimensional prism. This leads to just less effort in churning out pragmatic tools. And it also leads to a kind of dazzling conversation around the languages that turns away people who are just trying to get something done. With sustained effort these effects could be overcome. Over time I am building a library of pure imperative JavaScript modules. They seem to be reaching “finished” one by one. We’ll see.
  • marcosdumay 8y ago
    Every time I see people saying stuff like that I remember of this: http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m... > His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented. Anyway, it's not because C-like languages are any easier. It's just that nearly all programmers learn to code in a C-like language. Most of them won't ever learn a second language, the number that will do the work of learning something actually different is minuscule.
• weberc2 8y ago
  > full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcson. I don't know very much about Ericcson, but it wouldn't surprise me to find out they spent many times the amount on Erlang that Google spends on Go. There are probably lots of reasons why Go is successful, but I'm positive that it has more to do with simplicity, learning curve, tooling, ecosystem, etc than it does with corporate sponsorship or marketing.
  • fulafel 8y ago
    Ericsson abandoned Erlang, or Erlang abandoned Ericsson, depending on how you look: Ericsson banned it internally, and shortly afterwards when the Erlang team managed to get it open sourced, they resigned from Ericsson and founded their own Erlang company. (source: http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_erlang.pdf http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_e...)
    • geodel 8y ago
      So does Ericsson still use Erlang in their recent network hardware etc?
      • dnautics 8y ago
        I recall hearing no, somewhere. I am under the understanding, (don't know where from) that Cisco DOES use Erlang in their stack, and there is a group of people at VMware that does.
        • geodel 8y ago
          Thanks. This is something where simple internet search yields nothing much. Possibly because these network switches are proprietary platforms and they do not publish how internals are implemented.
• ngrilly 8y ago
  True, but Go and Erlang don't occupy the same niche. Go is imperative, while Erlang is mostly functional. Go is AOT (ahead-of-time) compiled, while Erlang runs on a VM. Go is statically typed, while Erlang is dynamically typed (I know about Dializer). Go concurrency primitives are designed to coordinate goroutines living in the same process, while Erlang concurrency primitives are designed to coordinate Erlang "processes" living in the Erlang VM or even in multiple Erlang VMs forming a cluster.
  • dnautics 8y ago
    Erlang is AOT, the vm reads compiled and optimized bytecode.
    • Sharlin 8y ago
      The point is that Erlang (like Java etc) needs a runtime, Go doesn't.
      • pjmlp 8y ago
        Every programming language has a runtime, even Assembly if the CPU is micro-coded. How do you think that the GC, go-routine scheduler, cgo marshaling get managed?
        • qznc 8y ago
          I assume what people want to say is that Go requires nothing which other languages install via the system package manager. While "runtime" is not the correct term, the desire is real. With Java you first install a JVM. With Python you install the interpreter and batteries. This always leads to version conflicts at some point. In contrast, with Go your CI builds an executable, you transfer that to your server and it runs. You don't have to care about the version of some "runtime" already on your server.
          • brianwawok 8y ago
• presscast 8y ago
  It's also not simple... at all.