Will Go 2 learn from Rust in terms of performance?

[ifreelance Asia]

Will Go 2 learn from Rust in terms of performance?
or
Will Go 2 learn any thing from Rust to be like it in terms of stuff where Go 2 is known for, and not get beaten by Rust performance?

Rust framework like - https://github.com/actix/actix-web beats the best performing framework of golang with miles distance.
Yet, people say, Rust was or is not much for web and Go is good for it, and rust still outperformed Go in it's own space.

Even here - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

Rust is more than 4-5 times on top 15 and Go is only one time in top 65 and more funnier to see is python an interpreted language is more times than go in top 65.

Also - check out here - https://github.com/tbrand/which_is_the_fastest (Detail list of all framework and benchmark)

what I learnt from presentation of "Go" replacing "C++" in "dl.google.com" was performance.

More than half of the go developer uses go because of it's simplicity and performance. There is no other beauty hidden in it as far as I know.

And when there is alternative to same simplicity and much better performance in other similar new language, the future as golang developer would look dark to me or to person like me.

[andrey mirtchovski]

I like that Rust is so performant, this is good. Performance, however,
is not everything. I'd like you to turn the question around: "Will
Rust ever embolden as many people to write as much novel software as
Go has?" When that time comes, as it might, Go can be set aside for
good.

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[R Sharma]

A time back, people questioned go while using PHP, .net, java.

A time has come, people are questioning rust while using Go.

I don't know, when such discussion will end and improvements will be talk about.

[azar...@gmail.com]

If we're talking Techempower and friends, I believe they use stdlib libraries like html/template which are surprisingly slow in comparison to faster third party libraries which you can slot into these frameworks. Or any Go program, really.

[as]

Code complexity and maintainability issues do not dissolve by manufacturing more-powerful machines. 

The probability of a defect increases geometrically with number of components in any system. Optimizations to make that system run faster are components (unless the optimization is an effect of a component's removal). Performance issues are more often resolved by correcting the design or application of algorithms, not using languages boasting linear speed boosts. Simplicity can't be back-ported to a language either, so your hypothetical alternative language is not Rust.

If project managers were college students arguing over whether Rust was faster than Go, you might have a basis for feeling a "dark future". But really I think the statement illustrates your personal priorities because you don't mention specific claims or issues. The hidden premise you're communicating here is that a language is not fast if it isn't the fastest on a scoreboard. That premise is unsound, as is your conclusion.

[Ian Lance Taylor]

On Fri, Jul 6, 2018 at 7:40 PM, ifreelance Asia
<ifreela...@gmail.com> wrote:
>
> Will Go 2 learn from Rust in terms of performance?
> or
> Will Go 2 learn any thing from Rust to be like it in terms of stuff where Go
> 2 is known for, and not get beaten by Rust performance?

I don't really see that as a Go 2 issue at all. Go, as a language,
has never been optimized for the highest possible performance.
Performance is one of the goals, but there are others. For people for
whom performance is the highest consideration, there are other
languages, notably C++.

Of course we should continue to improve Go's performance, but not at
the cost of sacrificing other goals like simplicity.

> Rust framework like - https://github.com/actix/actix-web beats the best
> performing framework of golang with miles distance.
> Yet, people say, Rust was or is not much for web and Go is good for it, and
> rust still outperformed Go in it's own space.
>
> Even here -
> https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
>
> Rust is more than 4-5 times on top 15 and Go is only one time in top 65 and
> more funnier to see is python an interpreted language is more times than go
> in top 65.

I'm not sure I understand. When I look at that web page the #2 entry
appears to be written in Go, and it's very close to the #1 entry,
written in Rust. I don't see why the number of entries in a given
language is relevant. If one framework works, why write another?

And, of course, this kind of benchmark can be very misleading. Few
servers look much look what that benchmark is testing.

> what I learnt from presentation of "Go" replacing "C++" in "dl.google.com"
> was performance.

Are you referring to this talk:
https://talks.golang.org/2013/oscon-dl.slide#1 ? I don't think the
point of that talk was that Go performs better. The point of that
talk was that Go permits the program to be written in a much more
natural and simpler style, leading to many fewer bugs. As the talk
says, the Go version was less than half the size of the C++ version.
The performance gain was in effect of side benefit of the simplicity.


Go and Rust are not the same sort of language. I don't see them as
competitors. Both seem likely to thrive.

Ian

[R Sharma]

For simplicity, there are languages like "php, python", there is no point deteriorating performance just for the sake of simplicity. And, What is simplicity, how do you define simplicity.

simplicity for one person could be stupidity for other and still complexity for half of the world population or more than that.

Go should focus on performance, believe it or not, if people look at go, they expect performance by default. Other things are following and will never be concerned.

[Ian Lance Taylor]

On Fri, Jul 6, 2018 at 10:56 PM, R Sharma <ifreela...@gmail.com> wrote:
>
> For simplicity, there are languages like "php, python", there is no point
> deteriorating performance just for the sake of simplicity. And, What is
> simplicity, how do you define simplicity.
>
> simplicity for one person could be stupidity for other and still complexity
> for half of the world population or more than that.

Yes, fair enough, simplicity is different for different people.
Nevertheless I feel safe in claiming that Go is a simple language.
It's simpler than PHP and I think it's at about the same level as
Python. Simplicity may be roughly defined as the number of concepts
you have to understand in order to understand how a piece of code
works, or as the number of times people learning the language are
surprised by some aspect, or as the number of times people experienced
with the language are surprised.

> Go should focus on performance, believe it or not, if people look at go,
> they expect performance by default. Other things are following and will
> never be concerned.

Yes. And Go does have performance by default. I don't see anybody
arguing otherwise. It doesn't have the highest possible performance
on specific benchmarks, but that doesn't mean that it doesn't perform
well in general.

Ian

[Jan Mercl]

On Sat, Jul 7, 2018 at 7:56 AM R Sharma <ifreela...@gmail.com> wrote:

> Go should focus on performance, ...

Performance improving PRs are always welcome. They are coming regularly and applied later on by one. You're more than welcome to participate.

> ... believe it or not, if people look at go, they expect performance by default. Other things are following and will never be concerned. 

So I'm not a human? ;-)  But seriously, that's provably not true. Some people have that point of view, some don't. I'm in the camp that will probably use Go even if it was 50% slower than it is now. It would still make my productivity above that of other languages I've been ever coding in.

--

-j

[Steven Hartland]

Looking at what that benchmark I don’t think is a very good real world benchmark unless your purely testing routing performance as all the responses are blank, which is hardly a realistic test.

--

[Drew Derbyshire]

If performance were the sole goal, we'd all be still bumming instructions in Assembler on IBM mainframes. One might use FORTRAN IV or C to let their optimizers bum the instructions for us, but nothing wanton like even C++. Instead, from the time of the original System/360 through to its 64-bit descendants, developers have iterated through the flavor of the week to get the best apps out the door in the fastest way possible.

Fastest running? Not if it was in PL/I.  :-)

-ahd-

[Doğan Kurt]

You would be right if only it was 25 years ago. At the time, hardware was the main limitation and people had to optimize their code aggressively in order to use less resources.

Those days are gone for good. People run browsers as text editors now. For the average software, speed of the language is almost never the bottleneck.

There is a new world now, projects with hundreds of programmers around the globe and millions of lines of code... Growing complexity of the software is the real problem of our time, and Go addresses these issues the best.

Finally, i think Go is pretty fast. I ported a few CPU intensive programs from C to Go and i was surprised to see that  the speed loss was negligible. If you find Go slow, i think you should suspect your algorithms first.

[Fino]

I think Go is already the fastest within GC language, before Go, Java is NO.1 in this domain.

Rust if turn off GC, C++/C is the compare language; if turn on GC, Rust may not faster than Go.

if Go can keep the NO.1 in GC enabled domain, that should be enough. Software cannot faster than CPU/ASIC's clock , anyway.

BR fino 

在 2018年7月7日星期六 UTC+8上午10:40:55，R Sharma写道：

[樊冰心]

You may ignore the top 2 fasthttp is written in go. 

在 2018年7月7日星期六 UTC+8上午10:40:55，R Sharma写道：

Will Go 2 learn from Rust in terms of performance?

[Jesper Louis Andersen]

On Sat, Jul 7, 2018 at 4:40 AM ifreelance Asia <ifreela...@gmail.com> wrote:

Will Go 2 learn from Rust in terms of performance?

​A programs efficiency is the product of all factors, of which performance is but one.

I have been somewhat cautious with the techempower benchmarks because they are measuring a thing which is usually uninteresting. It is often far more interesting to measure a steady rate of a planned capacity: If your system cannot take 7 million req/s, you add more machines, so you can assume each machine takes, say, 250,000 req/s and handle it with elastically bumping the machine count if you have too many per machine. This makes the question a cost question where one also has to factor in developer time for the solution.

Worse, the techempower benchmarks doesn't focus on latency at all. And the latency tab doesn't report a kernel density plot so it is virtually useless. It assumes a normally distributed data set, but I'll bet there has been no analysis if this is the case. To make a latency benchmark you will need:

* A steady rate. 30,000 connections, each executing 3 req/s say.

* Avoid "coordinated omission" so if one of those requests takes longer than 333ms to run, you count it *against* the next request. Otherwise, the test generator will coordinate with the System-under-test. This allows a server to cheat: serve a subset of the 30,000 connections, and give them a lot of req/s while starving the others. It doesn't look too bad on the final result because of using a mean.

* Plot percentiles: 50, 75, 90, 95, 98, 99, 99.9, 99.99, 99.999, 99.9999, 99,99999, and maximal value. You will catch many non-GC'ed languages in the top end doing cleanup like a GC, just way worse than what a GC provides.

The problem with a plaintext answer, a fortune, or something such is that it provides a far to steady system in practice. What kills your latency is usually an operation, which should have been preempted, that is cooperating instead. This then blocks the system as a whole and you suffer latency as a result. What Go is doing here is to trade off that preemption for some efficiency at the top (according to the benchmark, Go is #2 and this tradeoff is negligible). But I'm going to claim that in any real system, preemption is a necessary condition for correct operation once you factor in changes in steadiness, load, capacity and so on.

[Drew Derbyshire]

On Saturday, July 7, 2018 at 7:23:01 PM UTC-7, Doğan Kurt wrote:

You would be right if only it was 25 years ago. At the time, hardware was the main limitation and people had to optimize their code aggressively in order to use less resources.

25 years ago? That's *recent*. The IBM S/360 and its descendants are now more than twice that age. 

I mention that because you miss my point. Code speed (even in the early S/360 era over half a century ago) hasn't never been the sole point in commercial processing. Prompt delivery of function is, and performance is small one small part of it.

-ahd-

[Eric Johnson]

On Friday, July 6, 2018 at 7:40:55 PM UTC-7, R Sharma wrote:

Will Go 2 learn from Rust in terms of performance?
or
Will Go 2 learn any thing from Rust to be like it in terms of stuff where Go 2 is known for, and not get beaten by Rust performance?

Rust framework like - https://github.com/actix/actix-web beats the best performing framework of golang with miles distance.
Yet, people say, Rust was or is not much for web and Go is good for it, and rust still outperformed Go in it's own space.

Two quick thoughts:

Where performance is a general concern, the optimal spot for a language is something that is both quick to write correctly, and is very fast by default. Why? Developers are usually under intense pressure to get stuff to work quickly. Developers frequently do not have time to carefully tune their code. So if it can be written correctly, and works reasonably fast, then that is typically "good enough" for most projects. To the extent that developers must tune their code, the faster they can get the baseline work done, the more time they have for optimizations, when that need is discovered. Of course, the baseline speed of a language relates to how much of any given program will need additional attention for performance optimizations. Being very fast by default means very few places where the code will need optimizations. In short, for the generalized concern of writing performant programs, Go comes pretty darn close to hitting the bulls-eye. In the specific case you note, if it happens that Go is too slow for the specific case, options exist to use something outside the standard library.

My second thought? Go is still getting faster.

Eric.

[Henry]

Go hasn't reached its full performance potential yet. Go current compiler is pretty much a WYSIWYG compiler. It doesn't perform any sophisticated optimization. On the other hand, you get easy-to-debug and easy-to-reason-about performance. There is also a potential improvement in the GC and goroutine, as people will discover better algorithm over time. So, there is definitely some room for improvement in Go performance.

I also believe that, in the micro level, Rust has a greater performance capacity than Go. The reason is that Rust gives you more options that allow you to fine tune performance to a greater degree for your specific needs than you can with Go. In Go, many of these decisions are already made for you. The trade-offs made by the Go Team are generally good enough for most purposes, but you get a generic-ish performance. However, you gain everything else as I will explain below.

In real projects, people don't write code like they do in micro-benchmark tests. The major culprit isn't micro optimizations (loop unrolling, etc.), but inefficient design and algorithm. They usually occur as you have more people involved in the project, constantly changing requirements, deadlines, the need to work with existing code, miscommunication, complex domains, etc. This is optimization on the higher level, and I believe that Go has an edge over other programming languages in these areas. Go isn't perfect, but it seems to be designed from ground up with these consideration in mind.

I am highly optimistic about Go's future, and I hope Go Team will continue their good work.

[DV]

 I don't know what kind of job you have, but at my job, close-to-the-metal performance has never, ever been an issue. I don't get paid to shave off cycles here and there - I get paid to deliver *quality*, and to deliver that quality *quickly*. Time-to-market "performance" is rarely mentioned in whatever useless micro-benchmark people point to. 

It's ok if my Go program performs at 1/2 the speed of an equivalent Rust program. What's *not* OK is delivering a Rust program in one year instead of the equivalent Go program in 3 months. I'm roughly 4x more productive in Go. Because my time is much more expensive than hardware. 

Naturally, there are problems out there where getting as close to the metal as possible is the most important thing, but if that's the case, you're going to be doing assembly anyway. For the vast majority of problems I deal with, my enemy is IO latency, not raw CPU speed. 

Remember - the problem you're solving is more important to your boss than the code you write. And if you understand what that implies, you'll understand why so many programmers are perfectly happy with Go's performance. 

[pzi...@gmail.com]

> I don't know what kind of job you have, but at my job, close-to-the-metal performance has never, ever been an issue. 

Neither me, however, sometime you need it. For example, I'm working on ethereum smart contract and I see that sometimes requests just fails because of insufficient gas amount. And you have to deal with it, while gas consumption is how many instructions EVM is performing. Do you think that smart contract are useless scum or probably sometimes you should consider performance? Ok, maybe you choose the first option, but let's dive deeper:

> It's ok if my Go program performs at 1/2 the speed of an equivalent Rust program. What's *not* OK is delivering a Rust program in one year instead of the equivalent Go program in 3 months. I'm roughly 4x more productive in Go. Because my time is much more expensive than hardware. 

It's ok to have 0.5x performance, but who said that rust implementation takes 4x more time? It's basically not true for common applications. It may be true for some kind of prototypes or something like that, but that's all. That's because rust forces you to consider all edge cases while go doesn't. And here we go to the next part:

> I get paid to deliver *quality*, and to deliver that quality *quickly*. Time-to-market "performance" is rarely mentioned in whatever useless micro-benchmark people point to. 

You will actually spend more time than typical rust developer if it's your real goal. The reason is that you will debug all weird nulpointers and multithreading bugs while rust developer just makes compiler happy and program just works. I don't know if you really like debugging, but I don't, especially if it's environment-depended. If I can catch all bugs at compile time it actually increases your productivity. Let's continue

> Naturally, there are problems out there where getting as close to the metal as possible is the most important thing, but if that's the case, you're going to be doing assembly anyway.

What a 70th myth "you have to go into assembly for the speed"? That's not true for several decades. GCC/rustc/... generate much more efficient code that everyone but bunch of known assembly specialists. That's a false dichotomy, don't use it. please.

> For the vast majority of problems I deal with, my enemy is IO latency, not raw CPU speed. 

Can't agree on that more! But not every service is just "pass query to the DB", some of them are actually doing something. I was working on different CRM systems, that was intended to calculate customers bonuses, gift card statistics and so on. Is it close to metal? I doubt. But it had really large amount of calculations. Yes, it used DB engine as much as possible, but not everything may be done there, if you don't like to read 5000 lines SQL with business logic.

> Remember - the problem you're solving is more important to your boss than the code you write. And if you understand what that implies, you'll understand why so many programmers are perfectly happy with Go's performance. 

I understand that concept. But I don't really get Go guys. It's probably some sort of stockholm syndrome. They don't want to spend 1-3 months to get Rust concepts (or even something like C#/Kotlin), but they spend x2 time every day they implement something that's done for decades in other languages? No generics? You kidding. Of course, who could ever need such a complicated stuff? Remove element from the array? Absolutely unneeded!

Because of that, I imagine go guys as people who either write very simple web services that basically query a db or guys who like to reinvent the wheels on day-to-day basis.

I personally love myself too much to waste time on such things. Language makes me to copypaste over and over again? No, thanks. Language lacks basic multithreading/iso formatting dates/...? Why whould i take it? Language gives too week compile-time guarantees? Thank you, goodbye.

In a nutshell: I don't want to be a codemonkey which debugs and tries to understand why this value suddenly changed or why nil came here. I want compiler to do all the stuff for me while I'm drinking yet another cup of coffee reading reddit thread about new cool stuff coming into the language.

вторник, 10 июля 2018 г., 19:20:14 UTC+3 пользователь DV написал:

[Ian Lance Taylor]

I don't think this conversation is going anywhere useful. If we want
to talk about areas where Go's performance should improve, with
examples and/or benchmarks, that is fine. Let's avoid getting into a
fight between Go and Rust. Thanks.

Ian

[Doğan Kurt]

@Alex Zhuk

I like Rust and i really hope it to be successful. But i hope the Rust developers disagree with you on this;

I'm drinking yet another cup of coffee reading reddit thread about new cool stuff coming into the language.

I think our differences are philosophical. Neither language is objectively better. But to understand the value of Go, you must understand it's philosophy.

I am not particularly interested in languages and I am definitely not an expert, but i like to read historical stuff and i know unix history reasonably well. This enables me to trace some of the design choices of Go language.

What was the unix philosophy?

• Small and simple (minimalist)
• Write programs to do one thing and do it well
• Combine different programs to do new things instead of writing monolithic complicated stuff

Go follows the same philosophy.

• Small and simple
• Every feature is orthogonal
• Combine those features in new ways to accomplish the task

The value of the Go is that you have a bunch of simple and orthogonal features just like lego pieces, and you combine them in new and sometimes quite original ways to accomplish complicated tasks quite easily.

I don't know other people but this astonishes me, it's an example of emergence. The counter example is C++ where you have tons of features and different ways of doing a single task. I don't know you but i like the Go style better.

Again, i like Rust and i would like to learn it as it has some original aspects, but before advocating that Go sucks, i think you should try to understand the design philosophy and the roots of the language a little better.

[pzi...@gmail.com]

I'm not talking Rust is better or Go is better (whish is truly philosophical question). 

Simple language means that you have to reinvent things (if you need them). If you don't, then you're golden. But in my practice simple web services are not things you get paid for. It's more often something like high load service with complicated logic in it, which queries different databases and integrates with other services. Things get complicated really quick if you can't deal with complexity. And the more tools you have in your toolbox, the easier is your life.

> I am not particularly interested in languages and I am definitely not an expert, but i like to read historical stuff and i know unix history reasonably well. This enables me to trace some of the design choices of Go language.

What if I say that brainfuck is much easier to write programs on than Go? It has only 9 keywords, no arrays/functions/reflection, all this complicated stuff. And it still turing-complete! You probably would say that i'm not right, and you were right. If you have simple language you either have all features in libraries (and they are not first class citizens which affects how profitable they are) or you just don't have them when they are required and you just reinvent the wheels over and over again.

Another point: what's good philosophy for the OS could be not this good for the language, don't you think?

> The value of the Go is that you have a bunch of simple and orthogonal features just like lego pieces, and you combine them in new and sometimes quite original ways to accomplish complicated tasks quite easily.

Right, but only if you have these pieces. Consider you play tetris with L blocks only. It's possible to win the game, but it's much better to have all the diversity of the original game.

> I don't know other people but this astonishes me, it's an example of emergence. The counter example is C++ where you have tons of features and different ways of doing a single task. I don't know you but i like the Go style better.

C++ just was backward compatible for too long. Having different approaches isn't good thing, I agree here, but it doesn't mean that putting less features in the language would actually help. Brainfuck example is above, it cleanly have no "extra features", but is it good thing? Probably not, because it's too simple and you don't have enough expressional power to write the code you want.

> Again, i like Rust and i would like to learn it as it has some original aspects, but before advocating that Go sucks, i think you should try to understand the design philosophy and the roots of the language a little better.

I'm not saying that Go sucks (however, I personally have reasons to think that way), but my strong opinion that writing safe programs in rust is easier, than in Go or any other language I know (I'm a C# developer in the first place among several others, but I'm actively writing rust too), because rust is not fighting with borrow checker to make programs 1% faster, it's about how to learn its philosophy to make programs actually safe. Performance? You get it for free as by-product, e.g. see the article.

I didn't come here to presecute people for their Go preferences, absolutely not. I just wrote an answer on posts like "these rustish guys always do premature optimizations, they just waste their time and don't see the overall situation. You need to provide business value, not save several cpu clocks". It's not how things are happening and this is what I wanted to say.

среда, 11 июля 2018 г., 20:22:15 UTC+3 пользователь Doğan Kurt написал:

[Doğan Kurt]

I like esoteric languages and i happened to write a compiler and an interpreter for brainfuck. But i don't argue the sheer size of the language.

The virtue is that you have a small number of orthogonal features so it's easy to memorize and master the language. But those small features can be combined in different ways to solve hard problems very efficiently.

Right, but only if you have these pieces. Consider you play tetris with L blocks only. It's possible to win the game, but it's much better to have all the diversity of the original game.

I suspect you don't know those pieces very well (interfaces, composition, closures as first-class citizens etc).

I agree with Ian, this doesn't go anywhere useful, so that's the last reply from me.

[pzi...@gmail.com]

> The virtue is that you have a small number of orthogonal features so it's easy to memorize and master the language. But those small features can be combined in different ways to solve hard problems very efficiently.

The key point here is having orthogonal features. It just happens that the more features you, the harder is keeping them orthogonal, so you find yourself in situation where you have multiple ways to perform one task. That's not good thing, I agree.

> I suspect you don't know those pieces very well (interfaces, composition, closures as first-class citizens etc).

You know that learning go in one weekend is one of its killer features. So here we are in the situation where either I've got the language and I understand well those pieces or Go advocates are lying about this feature.

> I agree with Ian, this doesn't go anywhere useful, so that's the last reply from me.

Sorry, if I was offensive in any way. I just wanted to show that in my opinion Go while appearing simple and shiny becomes really hard to write and maintain. People are inventing really scaring things to work around these limitations, e.g. this

Sorry again for any inconveniences, I'm pretty sure that we could discuss all the things while having one or two beers. Who knows, maybe it will happen one day.

Regards.

среда, 11 июля 2018 г., 23:14:07 UTC+3 пользователь Doğan Kurt написал:

[krugl...@gmail.com]

From my point of view, rust is just a useless language

With valgrind and sanitizer，we can easily solve all problems that rust claims to better then C/C++

There is no any features can make me leave C/C++ to rust for anything

Thus, for performance I use C/C++, for productivity I use go

There is no room for rust, so I think rust will keep rusting

在 2018年7月12日星期四 UTC+8上午4:27:18，Alex Zhuk写道：

[krugl...@gmail.com]

If the problems solved by a new language features can also easily done by tools, than we don't need that new language

在 2018年7月13日星期五 UTC+8下午12:10:41，jj wang写道：

[nvcnvn]

> Even here - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

Just check this link, although #66 is Go with std http lib but you can see the #2 is fasthhttp lib which also written in Go.

For what I see, this is the great example for the success of Go as a language. The standard library remain ... standard and easy to use, when you need a higher level of optimized, write your own improvement with your favorite language :)

[pzi...@gmail.com]

> With valgrind and sanitizer，we can easily solve all problems that rust claims to better then C/C++

That's basically not true, beside that it doesn't work on windows/macos/whatever, causes x15 slowdown that makes impossible to use valgrind and sanitizer together and beside they are runtime tools.

Sorry, I'm to lazy to spend x2-x3 time in debugger instead of having all the things at compile time for free.

> There is no any features can make me leave C/C++ to rust for anything

Good for you! I see problems that could make me leave C# in favor of Rust, and I'm probably going to. Do you know why? Because I see pros and cons of both languages, while you probably don't. 

I actually had same conversation with very same arguments with proponents of dynamic languages. If you are writing C++/Go then you probably know them: "I don't need types that only limit me, I can write tests!",

and you know why tests don't work this well. Same situation is here, except now you are on dynamic side.

That's classical Blub paradox. When you are looking down on dynamic languages, you see that they are less powerful and they lack critical features. But when you look up you just see weirdo languages with strange features.

In order to be rightful to judge languages you have to have experience in all of them, in this particular case - C++/Go/Rust. You probably don't like people arguing about C++ without writing a single stroke on it, so don't do youself the thing you actually hate.

If you think that I'm writing "Use rust before arguing about it" it's merely not true. I'd say "try anything but C++/Go". DId you try Haskell/Clojure/Prolog/...? Or maybe something more mainstream, like Scala/F#. If you didn't, you probably should give it a try.

Beat the averages. Don't waste your time because you don't know a tool that does everything for you for free.

пятница, 13 июля 2018 г., 7:10:41 UTC+3 пользователь jj wang написал:

[Nedim Šabić]

On Friday, July 13, 2018 at 6:10:41 AM UTC+2, jj wang wrote:

From my point of view, rust is just a useless language

With valgrind and sanitizer，we can easily solve all problems that rust claims to better then C/C++

I partially agree with this. Humans obviously can't do better then compilers. If solving all problems around memory safety was that easy, we shouldn't ever hit critical security exploits compromising the Linux kernel/user space programs.

For me, both, Go and Rust are great languages.

[pzi...@gmail.com]

Nice reply.

> For me, both, Go and Rust are great languages. 

Yep, I'm absolutely with you. 

I only hope that guys itt would not really averages as they could learn something new. And when I say "new" i mean it, I don't talk about "yet another initialization method" or "new collection added in cpp2x", but some kind of mind shifter like Haskell or Prolog.

Sorry if I was too rude or sarcastic, you all guys are awesome. Just don't be stuck, keep going toward higher abstractions and better software. 

пятница, 13 июля 2018 г., 15:38:38 UTC+3 пользователь Nedim Šabić написал:

[krugl...@gmail.com]

Too young to simple, sometime naive!

rust, haskell, prolog they are all engineering fail language

Software engineering is not some kind thing that just mind shift at all

Programming 15 years in C/C++ for OS kernel like me, then you can talk about what is good what is bad

don't be a "syntax expert", be a real developer please!

在 2018年7月14日星期六 UTC+8上午1:09:30，Alex Zhuk写道：

[krugl...@gmail.com]

My last reply for "syntax experts"

"Languages that try to disallow idiocy become themselves idiotic." -- Rob Pike

在 2018年7月14日星期六 UTC+8上午11:34:09，jj wang写道：

[Dave Cheney]

All,

Please respect Ian’s request and take the Rust vs Go advocacy to another forum.

Thank you.