8 ms·

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability cost

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines. Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."

nine_k 9y ago
They forgot the mindshare of PHP users. The tradeoffs Go makes are rather similar (simplicity, ease of deployment vs expressivenes and consistency).
- k__ 9y ago
  I saw a tweetstorm by a longtime Go user who listed all the flaws and inconsistencies of the language. In the end it didn't look much better than PHP to me. Which is surprising, since PHP is a "grown" language and go has been "designed" by some longtime languages pros.
  - zaarn 9y ago
    A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast). Though I guess the same applies to PHP. It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP) Also the stricter type system compared to PHP is nice in addition to static linking making it more portable than PHP (minus not being portable to shared hosters)
    - k__ 9y ago
      Yes, I'm not a big fan of PHP either. Guess the global state access and easier parallelization are the main selling points. I wrote a few APIs with long running queues in PHP and Node.js and found it both a bit too clunky for that job.
    - icebraining 9y ago
      I don't think there's anything inherent in the language that prevents PHP from running like Go (daemon that receives requests, rather than being launched by an external server on each request). It's just a matter of convention.
    - themihai 9y ago
      Comparing PHP with Go it's a bit too much, don't you think? Type system, standard library, concurrency, compilation, packing ... I hardly find similarities.
      - nine_k 9y ago
        Some don't mind: https://news.ycombinator.com/item?id=13430612 https://news.ycombinator.com/item?id=13430612
        themihai 9y ago
        I can't agree though. I believe using that rationale same could be said about C and many other languages...If that's the case then, should we expect a "fix" for the master programmers (i.e. Go++)? Let's hope that won't happen. Go is nothing like PHP. It was an attempt to modernise C though I believe it failed because Go can't do realtime.
        nine_k 9y ago
        C is far from perfection, but it's very small, fit well to the hardware of its day, and had a colossal "killer app", Unix. A fix for master programmers is e.g. Rust, and a bunch of GC-based languages, from newcomers like Crystal and Nim to the battle-hardened JVM ecosystem, or Erlang/Elixir. The way C++ did not displace C, or the way Ruby and Python did not displace PHP, these guys will not displace Go.
  - coldtea 9y ago
    >and go has been "designed" by some longtime languages pros. Longtime systems and UNIX pros, not language/compiler pros though. That would be someone like Anders Hejlsberg or Lars Bak respectively.
    - themihai 9y ago
      Is that why Dart got so popular compared to Go? What about C?
      - coldtea 9y ago
        >Is that why Dart got so popular compared to Go? No, that was because the focus of Dart (replacing JS on web browsers) wasn't feasible, and even Google dropped it. Which says nothing about the quality of the language (which was selected for the Flutter SDK anyway). Besides, popularity in tech, as in high school, doesn't say much. Engineering shouldn't be a pop culture. >What about C? What about C? That was made by Dennis Ritchie, not involved in Golang. And even so, it's not the best basis for a 2007-2017 language.
        themihai 9y ago
        I think the bottom line for a language is to be successful not whether or not the founder has whatever acreditation someone worships. I believe C has been pretty successful thus the reason why I was asking you about it...was Dennis Richie a compiler designer or a unix developer? Dart seems to be used pretty much only by Google with few exceptions. I'm not saying it's a bad language but it's just not successful. I believe popularity is important because a death language doesn't solve problems. Engineering is about solving problems anyway not about developing the most complex/expressive language. As far as Go design is concerned I believe that someone who designed few programming languages can be called a "pro" even if he doesn't agree with the mainstream opinion about what makes a good design. Simplicity is underestimated.
  - greenhouse_gas 9y ago
    Though one thing that Go has which PHP doesn't is the rapidly braking changes (PHP3 and 7 have totally different idioms since early PHP decisions proved to be horribly insecure (register_globals))
- mtgx 9y ago
  A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?
  - nine_k 9y ago
    How would you handle plugins? Some kind of cheap local RPC would probably be fine from both the complexity and the performance POVs.
    - icebraining 9y ago
      You can write modules that you select at compile time, like Caddy does: https://github.com/mholt/caddy/wiki/Extending-Caddy https://github.com/mholt/caddy/wiki/Extending-Caddy
  - geodel 9y ago
    Perhaps this: https://gohugo.io/ https://gohugo.io/ There are bunch of comparisons Hugo vs Wordpress on internet.
    - nine_k 9y ago
      Imagine a one-step converter: "put your WP configs here, take your [Go-based] new site there, just 3x faster", or something. Good static site generators are many. The point of a product might be near-zero transition friction.
- namelost 9y ago
  This actually makes a lot of sense. From the outside, it's hard to see why anyone uses Go. Using Go feels like going back in time 20+ years. However if someone is coming from PHP, Go must look positively modern. Considering the millions of PHP programmers out there, Go can keep on growing for a long time.
  - matt_wulfeck 9y ago
    Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib. Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.
    - coldtea 9y ago
      Concurrency primitives maybe (though languages had those for 20 years too). But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?
      - matt_wulfeck 9y ago
        Static linking: no more futzing around with package nightmares on systems. Making sure system packages are present so python virtualenv can install. Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example. Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity. 1. https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
        uranusjr 9y ago
Koshkin 9y ago
I am not sure if many programmers are "prepared to accept more complex syntax" (etc.) than those of C++...
- owninghome 9y ago
  Thankfully that wasn’t implied at all, and it’s not true that rust has more complex semantics (or, I think, syntax, although I could be wrong on that). That said, it certainly is more complicated refactoring arbitrary data flows. There is certainly a cost for all the benefits! :)
- deleted 9y ago
  [deleted]
- dyladan 9y ago
  I think the author is saying "more complex" relative to higher level languages like Go. They mean to put Rust in the same category as C++. It could be rephrased as "prepared to accept languages like C++, D, and Rust with more complex syntax"
Scarbutt 9y ago
Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?
- nine_k 9y ago
  Likely they mean high RAM consumption?
- dyladan 9y ago
  I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.
- geodel 9y ago
  To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.
- hinkley 9y ago
  Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8. They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.
- readittwice 9y ago
  I suppose that "high-deployment costs" also includes JVM/application startup and warmup.
- jeremiep 9y ago
  Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.
deleted 9y ago
[deleted]
oconnor663 9y ago
I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. If that's right, it might be fair to say Rust and Go were "originally" competitors, even if they aren't as much anymore :)
- Avernar 9y ago
  As a C/C++ developer that doesn't surprise me at all. I looked at both Go and Rust and I'd go with Rust if given a choice between the two.
  - oconnor663 9y ago
    It might be that they underestimated how desperately people had already moved away from C/C++ if they had any choice at all :)
- vram22 9y ago
  >I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. Yes, I think that was in an article by Rob Pike, might have been his article titled "Less is exponentially more." Edit: Found that article: https://commandcenter.blogspot.in/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.in/2012/06/less-is-exponentia... Excerpt: [ I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. ]
  - deleted 9y ago
    [deleted]
- vram22 9y ago
  Ha ha, my edit and your reply (which you later deleted) crossed in time, due to my messing up my original post a bit w/copy+paste :) Sorry for the confusion. Anyway, point made clear. I found Rob's statement surprising too. But also, I heard from Josh Fraser, founder of Torbit (acquired in a relatively short while after being founded), that they decided to use Go because it has a good balance between the performance of C and the productivity of dynamic languages like Python and Ruby.
nickpsecurity 9y ago
One of the reasons for the confusion from those of us on system programming side is that Go inherited mostly from Oberon... https://blog.learngoprogramming.com/about-go-language-an-overview-f0bee143597c https://blog.learngoprogramming.com/about-go-language-an-ove... ...that was used to build OS's and other system stuff. Here's a brief history I just submitted and the official pages. https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 http://www.ethoberon.ethz.ch/ http://www.ethoberon.ethz.ch/ http://www.projectoberon.com/ http://www.projectoberon.com/ The Delphi product and the Oberon offshoot Component Pascal were used as C++ replacements. Here's an IDE for Component Pascal: http://blackboxframework.org/index.php?cID=home,en-us http://blackboxframework.org/index.php?cID=home,en-us So, the point is that it's a variant of a Wirth-style language for writing operating systems and low-level apps. With that, many of us figured it can also target the same thing. It might need some modification in its runtime or something if not originally aimed at it. I see no reason why a language stronger than Oberon couldn't be used for at least what Oberon was used for, though. As partial evidence, people are already writing prototypes for OS's in in. https://news.ycombinator.com/item?id=14537691 https://news.ycombinator.com/item?id=14537691 https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item Throw in real-time or selective GC's as a modification to get it closer to taking over a lot of stuff that C would be doing. There's also nothing stopping the low-level code from being straight-up unsafe with checks added by programmer since that's already the baseline with C. One would get a more pleasant language that was at least memory-safe in other components that could take a GC. House OS is an example where the H Layer wraps the unsafe, lowest-level parts of the kernel of an OS mostly written in type-safe Haskell.

nine_k 9y ago

They forgot the mindshare of PHP users. The tradeoffs Go makes are rather similar (simplicity, ease of deployment vs expressivenes and consistency).

k__ 9y ago
I saw a tweetstorm by a longtime Go user who listed all the flaws and inconsistencies of the language. In the end it didn't look much better than PHP to me. Which is surprising, since PHP is a "grown" language and go has been "designed" by some longtime languages pros.
- zaarn 9y ago
  A lot of complaints usually affect niche or rare use cases in the language (or you learn them fast). Though I guess the same applies to PHP. It's a lot nicer to write webapps in Go though since you have control over global state and not the per-request state of PHP, which makes for some easier solutions to problems (work-queues are easy to implement/use on the server-side unlike in PHP) Also the stricter type system compared to PHP is nice in addition to static linking making it more portable than PHP (minus not being portable to shared hosters)
  - k__ 9y ago
    Yes, I'm not a big fan of PHP either. Guess the global state access and easier parallelization are the main selling points. I wrote a few APIs with long running queues in PHP and Node.js and found it both a bit too clunky for that job.
  - icebraining 9y ago
    I don't think there's anything inherent in the language that prevents PHP from running like Go (daemon that receives requests, rather than being launched by an external server on each request). It's just a matter of convention.
  - themihai 9y ago
    Comparing PHP with Go it's a bit too much, don't you think? Type system, standard library, concurrency, compilation, packing ... I hardly find similarities.
    - nine_k 9y ago
      Some don't mind: https://news.ycombinator.com/item?id=13430612 https://news.ycombinator.com/item?id=13430612
      - themihai 9y ago
        I can't agree though. I believe using that rationale same could be said about C and many other languages...If that's the case then, should we expect a "fix" for the master programmers (i.e. Go++)? Let's hope that won't happen. Go is nothing like PHP. It was an attempt to modernise C though I believe it failed because Go can't do realtime.
        nine_k 9y ago
        C is far from perfection, but it's very small, fit well to the hardware of its day, and had a colossal "killer app", Unix. A fix for master programmers is e.g. Rust, and a bunch of GC-based languages, from newcomers like Crystal and Nim to the battle-hardened JVM ecosystem, or Erlang/Elixir. The way C++ did not displace C, or the way Ruby and Python did not displace PHP, these guys will not displace Go.
- coldtea 9y ago
  >and go has been "designed" by some longtime languages pros. Longtime systems and UNIX pros, not language/compiler pros though. That would be someone like Anders Hejlsberg or Lars Bak respectively.
  - themihai 9y ago
    Is that why Dart got so popular compared to Go? What about C?
    - coldtea 9y ago
      >Is that why Dart got so popular compared to Go? No, that was because the focus of Dart (replacing JS on web browsers) wasn't feasible, and even Google dropped it. Which says nothing about the quality of the language (which was selected for the Flutter SDK anyway). Besides, popularity in tech, as in high school, doesn't say much. Engineering shouldn't be a pop culture. >What about C? What about C? That was made by Dennis Ritchie, not involved in Golang. And even so, it's not the best basis for a 2007-2017 language.
      - themihai 9y ago
        I think the bottom line for a language is to be successful not whether or not the founder has whatever acreditation someone worships. I believe C has been pretty successful thus the reason why I was asking you about it...was Dennis Richie a compiler designer or a unix developer? Dart seems to be used pretty much only by Google with few exceptions. I'm not saying it's a bad language but it's just not successful. I believe popularity is important because a death language doesn't solve problems. Engineering is about solving problems anyway not about developing the most complex/expressive language. As far as Go design is concerned I believe that someone who designed few programming languages can be called a "pro" even if he doesn't agree with the mainstream opinion about what makes a good design. Simplicity is underestimated.
- greenhouse_gas 9y ago
  Though one thing that Go has which PHP doesn't is the rapidly braking changes (PHP3 and 7 have totally different idioms since early PHP decisions proved to be horribly insecure (register_globals))
mtgx 9y ago
A Wordpress alternative in Go would be pretty cool. Is anyone working on such a thing?
- nine_k 9y ago
  How would you handle plugins? Some kind of cheap local RPC would probably be fine from both the complexity and the performance POVs.
  - icebraining 9y ago
    You can write modules that you select at compile time, like Caddy does: https://github.com/mholt/caddy/wiki/Extending-Caddy https://github.com/mholt/caddy/wiki/Extending-Caddy
- geodel 9y ago
  Perhaps this: https://gohugo.io/ https://gohugo.io/ There are bunch of comparisons Hugo vs Wordpress on internet.
  - nine_k 9y ago
    Imagine a one-step converter: "put your WP configs here, take your [Go-based] new site there, just 3x faster", or something. Good static site generators are many. The point of a product might be near-zero transition friction.
namelost 9y ago
This actually makes a lot of sense. From the outside, it's hard to see why anyone uses Go. Using Go feels like going back in time 20+ years. However if someone is coming from PHP, Go must look positively modern. Considering the millions of PHP programmers out there, Go can keep on growing for a long time.
- matt_wulfeck 9y ago
  Coming from a scripting language background Go was like moving into the future: concurrency primitives, static linking, channels, fast compile times, awesome standard lib. Not to mention the fact that go fmt makes everyone’s code look exactly the same. No more weird, personal styles being brought into into source code or pointless discussions of naming conventions or indentation.
  - coldtea 9y ago
    Concurrency primitives maybe (though languages had those for 20 years too). But what about static linking, fast compile times and awesome standard lib is like "stepping into the feature"?
    - matt_wulfeck 9y ago
      Static linking: no more futzing around with package nightmares on systems. Making sure system packages are present so python virtualenv can install. Static linking makes portability a breeze. I don’t know why this idea was lost in virtually every scripting language from the past 20 years. Standard lib is just plain awesome. You can build most things right out of the box without searching the web for competing versions of the same thing. Web apps are a great example. Fast compile times was a feature built into Go from the beginning. Presumably from people frustrated by compile times of large C/C++ codebases [1]. It’s about developer productivity. 1. https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
      - uranusjr 9y ago

Koshkin 9y ago

I am not sure if many programmers are "prepared to accept more complex syntax" (etc.) than those of C++...

owninghome 9y ago
Thankfully that wasn’t implied at all, and it’s not true that rust has more complex semantics (or, I think, syntax, although I could be wrong on that). That said, it certainly is more complicated refactoring arbitrary data flows. There is certainly a cost for all the benefits! :)
deleted 9y ago
[deleted]
dyladan 9y ago
I think the author is saying "more complex" relative to higher level languages like Go. They mean to put Rust in the same category as C++. It could be rephrased as "prepared to accept languages like C++, D, and Rust with more complex syntax"

Scarbutt 9y ago

Curious, what are the "high deployment costs of JVM based languages"? Don't must standard workloads simply deploy a jar?

nine_k 9y ago
Likely they mean high RAM consumption?
dyladan 9y ago
I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.
geodel 9y ago
To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.
hinkley 9y ago
Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8. They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.
readittwice 9y ago
I suppose that "high-deployment costs" also includes JVM/application startup and warmup.
jeremiep 9y ago
Most likely some old myth regarding the JVM. Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer. I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

deleted 9y ago

[deleted]

oconnor663 9y ago

I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. If that's right, it might be fair to say Rust and Go were "originally" competitors, even if they aren't as much anymore :)

Avernar 9y ago
As a C/C++ developer that doesn't surprise me at all. I looked at both Go and Rust and I'd go with Rust if given a choice between the two.
- oconnor663 9y ago
  It might be that they underestimated how desperately people had already moved away from C/C++ if they had any choice at all :)
vram22 9y ago
>I remember reading somewhere that Go was originally intended to take over a lot of projects that are currently C++, and that it was kind of a surprise that more Go programmers ended up coming from languages like Python. Yes, I think that was in an article by Rob Pike, might have been his article titled "Less is exponentially more." Edit: Found that article: https://commandcenter.blogspot.in/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.in/2012/06/less-is-exponentia... Excerpt: [ I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. ]
- deleted 9y ago
  [deleted]
vram22 9y ago
Ha ha, my edit and your reply (which you later deleted) crossed in time, due to my messing up my original post a bit w/copy+paste :) Sorry for the confusion. Anyway, point made clear. I found Rob's statement surprising too. But also, I heard from Josh Fraser, founder of Torbit (acquired in a relatively short while after being founded), that they decided to use Go because it has a good balance between the performance of C and the productivity of dynamic languages like Python and Ruby.

nickpsecurity 9y ago

One of the reasons for the confusion from those of us on system programming side is that Go inherited mostly from Oberon... https://blog.learngoprogramming.com/about-go-language-an-overview-f0bee143597c https://blog.learngoprogramming.com/about-go-language-an-ove... ...that was used to build OS's and other system stuff. Here's a brief history I just submitted and the official pages. https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 http://www.ethoberon.ethz.ch/ http://www.ethoberon.ethz.ch/ http://www.projectoberon.com/ http://www.projectoberon.com/ The Delphi product and the Oberon offshoot Component Pascal were used as C++ replacements. Here's an IDE for Component Pascal: http://blackboxframework.org/index.php?cID=home,en-us http://blackboxframework.org/index.php?cID=home,en-us So, the point is that it's a variant of a Wirth-style language for writing operating systems and low-level apps. With that, many of us figured it can also target the same thing. It might need some modification in its runtime or something if not originally aimed at it. I see no reason why a language stronger than Oberon couldn't be used for at least what Oberon was used for, though. As partial evidence, people are already writing prototypes for OS's in in. https://news.ycombinator.com/item?id=14537691 https://news.ycombinator.com/item?id=14537691 https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item https://www.phoronix.com/scan.php?px=MTY5OTQ&page=news_item Throw in real-time or selective GC's as a modification to get it closer to taking over a lot of stuff that C would be doing. There's also nothing stopping the low-level code from being straight-up unsafe with checks added by programmer since that's already the baseline with C. One would get a more pleasant language that was at least memory-safe in other components that could take a GC. House OS is an example where the H Layer wraps the unsafe, lowest-level parts of the kernel of an OS mostly written in type-safe Haskell.