Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go and Rust Are Not Competitors (2015)

dave.cheney.net

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Why Go and Rust Are Not Competitors (2015)

#91

Post by vvanders »

abiox wrote: post #88
vvanders wrote: post #82

Earlier quoted context omitted.

Garbage collection by its nature implies dynamic allocation. You're using value types and raw pointers in those targets because even the memory overhead of a heap/freelist/etc can be too much. With things like AVR you're looking at 512B to 16kB of total memory(part of which includes the code you write).

> Garbage collection by its nature implies dynamic allocation i'm not sure i follow - you're saying that a gc existing implies that one cannot preallocate and avoid dynamic allocation?

> preallocate

This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.

Re: Why Go and Rust Are Not Competitors (2015)

#92

Post by vram22 »

zeveb wrote: post #44
systems wrote: post #27

They are both being used, where C and C++ were the only alternative Some of the points to be made here is that C and C++ are being used for a very wide range of applications So if you do compare Go and Rust, you will find distinct technical advantages and disadvantage Rust/Go are currently the C/C++ alternative

> They are both being used, where C and C++ were the only alternative > Some of the points to be made here is that C and C++ are being used for a very wide range of applications That's a really good point. C is an odd language: people used it to squeeze every ounce of performance out of machines, even when they didn't need to. E.g. an ls or cat written in C is almost certainly a premature optimisation. Even a program…

>People were using C almost as a scripting language, which in retrospect is insane. Using it as a portable assembler to build the bulk of an OS, or at least the low-level parts of an OS, made sense — trying to use it for high-level programming was a mistake.

Before C++ and some of the less and more recent higher-level languages became available and were stable enough, people were writing both business applications and desktop / server software products in C - a lot.

Biz apps that required database-like functionality were written either using ISAM-type libraries or low-level proprietary database APIs (specific to a particular database server) or using embedded SQL in C (e.g. Pro-C for Oracle, ESQL/C for Informix, DB-Library for Sybase, etc.

And lots of successful Unix and Win32 software products were written in C, for both the logic and GUI parts of the apps. I've worked some earlier on real projects / products of all those types I mentioned (except Sybase).

Some higher level products such as 4GLs also existed (for reporting and other purposes) and those were used too, but C was still used, even for business apps. When there were less of good higher-level-but-still performant choices available, and hardware was not as powerful, it was not an insane option at all.

Plus, as is known to C programmers, "in C you can do anything." Not many higher-level languages can say that - except by linking to C libs via FFIs of some type. Obviously there were cons involved too, such as string handling, memory and pointer management, and less productivity than higher-level tools.

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

https://en.wikipedia.org/wiki/Pro*C

https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0...

Re: Why Go and Rust Are Not Competitors (2015)

#93

Post by 3pt14159 »

k__ wrote: post #34
3pt14159 wrote: post #24

I actually think that in the long run Rust and Go will have a similar relationship between Ember and React. They'll have fundamentally different approaches, but they'll steal the best ideas from each other (for example, Glimmer is heavily influenced from React) and they'll both end up serving their domains better and maybe overlapping a bit more here and there.

lol, good comparison. But what did React steal from Ember and what did Rust steal from Go?

There are lots of areas of speed optimizations that Ember introduced after switching to Glimmer that React stole. Plus their CLI is very, very heavily influenced by Ember's (which was influence by Rails).

Re: Why Go and Rust Are Not Competitors (2015)

#94

Post by greenhouse_gas »

namelost wrote: post #31
nine_k wrote: post #5

Earlier quoted context omitted.

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

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.

For me, coming from Java it was a breath of fresh air simply because of the simple build setup. (Modern) Java requires gradle (which is a magical setup, written in a language totally dead outside of gradle scripts), special magic for a "fat jar", and even then it doesn't create a exe/elf at the end. And the build is fast - even on a raspberry pi.

Oh, and the IDE environment is amazing - you literally don't need much more than VSCode or vim (the language tools have built in refactoring support, formating, quick compile for syntax error, godoc).

And you have closures, something Java didn't have until 8, and even now many libraries don't support it.

Re: Why Go and Rust Are Not Competitors (2015)

#95

Post by abiox »

vvanders wrote: post #91
abiox wrote: post #88

Earlier quoted context omitted.

> Garbage collection by its nature implies dynamic allocation i'm not sure i follow - you're saying that a gc existing implies that one cannot preallocate and avoid dynamic allocation?

> preallocate This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.

i guess i was using 'dynamic allocation' to mean allocation that occurs in the midst of the main control flow, likely in response to some conditional evaluation (vs upfront).

Re: Why Go and Rust Are Not Competitors (2015)

#96

Post by Avernar »

oconnor663 wrote: post #37
kgthegreat wrote: post #2

"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 N…

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 :)

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.

Re: Why Go and Rust Are Not Competitors (2015)

#97

Post by oconnor663 »

aplanas wrote: post #83
oconnor663 wrote: post #39

> Go is focused on concurrency as a first class concept. That is not to say you cannot find aspects of Go’s actor oriented concurrency in Rust, but it is left as an exercise to the programmer. To be fair, concurrency is baked the Rust type system itself. It's certainly a first class concept. I think the better way to describe it is that Rust wants to make concurrency safe regardless of what mechanism it's based on (s…

I do not see that concurrency is a first class concept in Rust at all. The only mechanism that is in the language are the Send and Sync traits, and is even partially out of it. Rust do not have language constructs for any concurrency/parallel model, and this is a good thing. You can use fork-join, parallel iterators, mutex, rwlocks, channels (mpsc, mpmc...) or any other model as a library. The nice thing is that, as…

Yes I think we're mainly using "first class" to mean different things, but we can both agree that Rust and Go have both been designed very carefully around concurrency :)

Re: Why Go and Rust Are Not Competitors (2015)

#98

Post by k__ »

3pt14159 wrote: post #93
k__ wrote: post #34

Earlier quoted context omitted.

lol, good comparison. But what did React steal from Ember and what did Rust steal from Go?

There are lots of areas of speed optimizations that Ember introduced after switching to Glimmer that React stole. Plus their CLI is very, very heavily influenced by Ember's (which was influence by Rails).

They have a CLI?

I only knew about CRA.

Re: Why Go and Rust Are Not Competitors (2015)

#99

Post by vvanders »

abiox wrote: post #95
vvanders wrote: post #91

Earlier quoted context omitted.

> preallocate This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.

i guess i was using 'dynamic allocation' to mean allocation that occurs in the midst of the main control flow, likely in response to some conditional evaluation (vs upfront).

Yeah, if you allocate in the main loop or preallocate you're still going to pay the overhead of a heap to keep track of those allocation :).

Re: Why Go and Rust Are Not Competitors (2015)

#100

Post by themihai »

coldtea wrote: post #85
themihai wrote: post #68

Earlier quoted context omitted.

Is that why Dart got so popular compared to Go? What about C?

> 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…

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.

Post reply on HN