Not sure I quite understand the premise that there is a strict delineation between programmers who are "prepared to accept more complex syntax and semantics for " and otherwise. I can think of a lot of cases where I'd personally use either or (I've been looking into tikv contrasting it with cockroachdb's storage layer for e.g.), a lot of cases where I've used Rust's formalization of ownership/borrowing semantics to alleviate GC pressure in Go code. I'm hard pressed to find projects "for" Go that Rust wouldn't be a reasonable alternative to, and vice-versa.
Why Go and Rust Are Not Competitors (2015)
81–90 of 102 posts
Re: Why Go and Rust Are Not Competitors (2015)
#82Earlier quoted context omitted.
Many controllers have almost zero memory headroom meaning your GC pauses get an order of magnitude slower if not more as you have less than 2x your working set. Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.
is a gc all that relevant if you're not dynamically allocating in either case?
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).
Re: Why Go and Rust Are Not Competitors (2015)
#83> 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 you say, is the type system the component that guarantee a free from data race code in safe Rust.
Re: Why Go and Rust Are Not Competitors (2015)
#84Earlier quoted context omitted.
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"?
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 version…
> 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.
Because they are invented at a time before storage and RAM is dirt cheap and lightning fast. It was painfully wasteful and slow to load a copy of the standard library for every process. Dynamic linking was invented basically because static linking wasn’t feasible.
Re: Why Go and Rust Are Not Competitors (2015)
#85Earlier quoted context omitted.
> 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.
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 Dennis Ritchie, not involved in Golang. And even so, it's not the best basis for a 2007-2017 language.
Re: Why Go and Rust Are Not Competitors (2015)
#86Earlier quoted context omitted.
Some don't mind: https://news.ycombinator.com/item?id=13430612
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.
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.
Re: Why Go and Rust Are Not Competitors (2015)
#87MORE of these headlines instead of "Go is slower than Rust" or "Rust has more bells and whistles than Go". I develop in both Go and Rust. I use Go as main replacement for .NET/Java web tier...no need for install specific Java or .NET run-time library. I use Rust when there's heavy disk reads and writes...and I know it's a nightly job which should never segfault and never finish the execution since it crashed. GO = us…
If you want rapid prototyping I don't think you can beat Clojure, not even close. Its really, really hard to beat the iteration cycle of a Lisp.
Python is not too shabby for this either. Command line + vim (substitute your $EDITOR) and ipython and python and things can fly.
Re: Why Go and Rust Are Not Competitors (2015)
#88Earlier quoted context omitted.
is a gc all that relevant if you're not dynamically allocating in either case?
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?
Re: Why Go and Rust Are Not Competitors (2015)
#89An article about rust from 2015? Not worth reading.
why not?
Re: Why Go and Rust Are Not Competitors (2015)
#90Earlier quoted context omitted.
>> make some things that needed to be done in C++ or Rust viable in Go. like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).
c++ is used in a lot more than just "micro controllers, AAA game engines, and web rendering engines".
C++ Applications:
http://stroustrup.com/applications.html
A big list.