What parts of web development do you want to get involved in? And should your choice of language lead to more job opportunities?
Go is still pretty hyped and popular because it is very easy to learn and easy to get results with. Its concurrency model is far easier to understand than traditional thread-based ones and the ecosystem exploded some time ago, with so many great libs and frameworks nowadays.
I/O in Go is async by default without you mostly noting it, because the runtime takes care of it for you.
I've been programming for nearly 20 years now (with only a fraction of it being professionally) so the following may not apply to you, but it took me only one day to learn Go and write my first piece of software in it, without it failing horribly at runtime.
The only issue I ran into was its exotic handling of dependencies ($GOPATH, etc.), which got better with the introduction of gomodules and still improves, that gave me a hard time.
The number of jobs listed for Go is pretty decent currently (please note: highly depending on where you live).
Rust on the other hand is difficult to learn but very easy to use once you actually understand it and successfully fought the compiler and borrow checker until you became very close friends (but this will take you way more time than learning Go).
I believe that it took me two weeks before I was able to write simple programs without the compiler complaining too much. But boy, once something in Rust compiles, you can be pretty sure that it'll just work!
What differentiates Rust from Go is that there's no runtime (which takes care of certain things for you). Thus you have way more control over the actual outcome of what you do.
Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn, which comes in very handy, given, that you have to learn a lot of other concepts like borrowing, etc., you did not have to bother with while using memory managed languages.
Rust comes with Cargo, which, in contrast to Go's $GOPATH / gomodule system, is like heaven on earth. It makes handling of dependencies, building, etc. so easy and so much fun and doesn't get in your way.
Depending on where you live, the number of job postings that do not directly relate to blockchain may be far less than those for Go and this may limit your opportunities.
There's nothing one of these languages can achieve that the other doesn't, so no drawbacks there with either of them. Both can be used for pretty much anything. You can write REST-APIs with both, you could implement a new database, both compile to WASM, pretty much anything you could imagine.
That's only the tip of the iceberg but perhaps it helps you a little to decide.
I'd suggest:
Try out both, write a simple program, and then see what you have more fun with.
"Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn"
... then I really need to disagree! I have minimal experience with Rust (and Go), but having worked through most of the docs/tutorial, and subsequently having like a week (yes just a week) hands-on experience with a real-world codebase, what jumped out for me was this:
Rust has quite a strong Functional Programming (FP) feel to it - it often reminded me of Haskell which I dabbled in for a while; lots of emphasis on map/filter/reduce type of things, and declaring (abstract) data types.
This leads to Rust code tending to be much more "declarative" than Go code (which tends to be very much imperative, generic map/filter/reduce kind of code isn't even possible really for lack of a generic type system).
So, while I only have 'experience' with both Go and Rust on a "tutorial" and glorified "hello world" level, conceptually I was much more impressed with Rust as a programming language.
My feeling was that Go is very much "dumbed down" - especially the lack of generics sticks out like a sore thumb, because this forces you to write for loops ad infinitum ... the code you write tends to be very imperative. In that regard it sort of feels like a step back. Rust (at least that's my opinion) is a lot more elegant as a programming language.
On the other hand:
the Go compiler is insanely fast! Rust's compiler is s-l-o-w ...
Rust misses the biggest asset of Go which is the easy async/concurrency model
Employability: the number of Go jobs is probably an order of magnitude larger than the number of Rust jobs
On the other hand, the way Go manages its dependencies (with GOPATH and so on, and with its prescription of how you need to physically organize your files/directories) is indeed a bit "weird", but it didn't bother me really - if you stick to the conventions then it just works (again however, Rust's module system, while more complex, is a lot more elegant).
So, conceptually I'm much more impressed with Rust, but I acknowledge that Go might be more practical for "real world" purposes.
Now if Rust would acquire Go's concurrency features (Goroutines) and Go would get generic types, then the competition between the two would become really interesting!
These are only two examples, specifically tailored to your point of Rust's FP-style.
What I just want to showcase is: It's not that much new. If you got the concept somewhere else, you'll get it within Rust.
The same could be made up for variable declaration, and nearly everything else.
It's just a similar style. :-)
On Go being dumbed down:
Yes, absolutely.
IIRC, one reason for Rob Pike, Ken Thompson and Robert Griesemer to design Go the way it is, is, that Google faces some unique challenges.
They had to invest an enormous amount of money to get their C++ infrastructure right and they have to onboard a lot of new engineers very often. Concurrency, of course, is very difficult and so they wanted to create something very easy to understand and write working Software with. They also wanted to fight the enormous build times Google's C++ projects sometimes have.
Their intention was to create a language with the minimal feature set needed to accomplish a task at Google scale by negating the drawbacks they previously faced.
Rust's compiler gets faster and faster with every release, but for all the checks and safety features it comes with, there need to be some drawbacks.
It may not be that fancy as a go func... and then using channels and so on, but we're getting closer. :-)
Edit regarding the job situation:
I think we will have to give it a little more time. Let the ecosystem mature more and I'm, pretty sure that, as the community grows, job opportunities will also arise.
Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
Forgot to mention one big thing and that is rust has no garbage collector like Go does. Not that it's bad just worth noting. Also I think wasmer is awesome either way you go; and checkout neon/yew/actix for rust or Gin for go and decide what you like. Rust gives you a lot more control but requires you to make more decisions and code. Try both go with what you like. Rust jobs will be there in the future. There are plenty of Go jobs now.
Omitted that on purpose. You are very right but the compiler takes care of allocating memory for you. And in 90% of use cases you will never need more than that, although Rust allows for manual memory management for those 10% of use cases you pretend to really know what you are doing. :-)
I'd say it depends on the goal of your project. Rust is a good fit for computationally intense, high throughput situations, but will require higher cognitive overhead to put together. Golang is a language designed from the ground up to target this space, but also with an emphasis on large scale collaboration. As a result the language doesn't provide the same amount of high level tools like parametric polymorphism which can aid an individual developer, and you may need to produce more boilerplate. The standard library has a great story for webdev baked in, though, and will likely be a more frictionless experience end to end.
Thank you for explanation, actually I don't have any project. My proffesion on frontend development but I want to learn Rust or Go for hobby and combine with frontend.
Who knows, maybe I will switch my role in future :)
I'd say you can't go wrong either way, then, but Go is going to be easier to start with. It's always a matter of taste, but I personally have a lot more fun writing Rust than Go. Ideally, time permitting, you'd try both! Pick a simple application, try building it in both languages, and see which you prefer. Both are excellent choices.
Yeah exaclty what I’m thnking about choosing sample project and do it with both. Needed to ensure both languages are capable of web development first. Thank you :)
This is how you can do it without a framework, but you can also try Rocket, Actix-Web, or Warp for a more full-featured starting point. For Go, I'd recommend not starting with a framework at all. Just use the standard library, and only add in a third-party solution if your app grows to the point where you need it.
Thank you Yaser ☺️
I’m not considering job apply or want to be fullstack. My interest and want to learn for fun but hey, if I achieved well maybe I will go further and extend my profession.
After switching from Python to Go several years ago - I can't look back :) In Go you just don't have problems like pip install requirements.txt or thinking how to run multi-core or deploy some RabbitMQ just for messaging on a single node. Docker images are slim, great ecosystem, easier testing and due to static types - code quality is better.
Go is a very refreshing language after Python :) Not saying Python is bad, but there are better tools for the job. Python is great for data wrangling, machine learning.
Problems with installation/deployment were mostly pre-docker behind corporate proxy which didn't allow pip :) So it was an interesting ceremony of bundling dependencies and then installing them from that cache.
I heavily used Tornado and Twisted frameworks, but it's single single core, you always feel like there's so much more you could do but you can't without additional plumbing.
That Golang image is a compiler toolchain, Golang binaries do not actually need anything else, you can use Scratch or alpine image, resulting image is usually ~10MB.
Some people think that Go is still lacking in ecosystem, in my ~4 years of professional work, I have never missed a single library :)
Regarding code quality - static types really increase code quality and Go applications are easier to read/understand than many other languages. What's important is that if you want to see how some std lib is implemented, you just click on that function on dive into it. With Python it's often not the case.
Just high performance is one thing but another thing that's quite important and often overlooked - how cheap will it be to run your side project? With Go you can use just ~10MB of RAM and 0-1% CPU, this makes it a good language to write services that can be cheaply deployed :)
I still like Python but with my current projects that I work on, it wouldn't be a good fit.
Try ruby (ruby-lang.org) 😊, its gets you up and running in a few lines of code with sinatrarb.com. It is a very good place to start fullstack development. Its fully oop, and has json support out of the box. (I assume you are havin a kind of spa as frontend)
Also rubymonk.com is a incredible good source for learning ruby. Learning ruby is all about having fun, and a good way to learn server side computations ✌️😊
I was in the same scenario some time ago. Rust was much younger - a blip on the radar, actually - and I dug into Go. I can't advise one way or the other, but I can chime in from the "person who chose Go" side.
If I was going to sum it up: Go really doesn't leave much to be desired. It ha some rough edges (looking at you package management), but at the end of the day... I'm a little sad if I was using something else.
Whenever rust vs go comes up, invariably someone says go's strength is in its high velocity. I can attest to that. I have a number of commit messages that read make the compiler happy, but not too bad. And, eventually it clicks - that was my fault lol.
DX is solid. IDEs like strict typing of course, but the compiler speed is a monster. In dev, it feels more like an interpreter than a compiler. It's a little confounding that delve JUST NOW got the ability to run a method call during step-debug, hut cest la vie.
If you're coming from front-end, I assume you're comfortable with Node.
You will miss package.json like crazy (go mod is standard now, but it's still not quite... There)
You will love how smooth async is (huge plus if you work with rest)
You will be angry at unmarshaling an (uncertain) api response
You will be completely freaked out when the call stack takes you down into the RAM chip.
That's what I have. Now I spy on this thread. ... because I still search "go vs rust" at least once a week 🤷♀️
After learning C#, PHP, Java, JavaScript, C, Pascal, TypeScript, it's time to learning Rust because of positive comments by professionals.
I am also Firefox lover and Mozilla, and I think Mozilla made a sophisticated decision to build Firefox by Rust.
Since you haven't started either, you're much closer to web development going with go.
I say that with complete honesty as someone who uses and writes about rust semi-regularly. If you have some other use cases that warrant rust, then I would pick it. Barring that, I would pick the simplest option.
Front end developer who currently works at Tourism Industry. Skilled in Sass, Javascript and Html.
Welcome to the Privacy Hub Welcome to the Privacy Hub This is a centralized portal to learn about privacy at Citi and for California residents to submit requests in connection with the California Consumer Privacy Act. This is a centralized portal to learn about privacy at Citi and for California residents to submit requests in connection with the California Consumer Privacy Act. For Returning Visitors For Returning Visitors Check the status of your California Consumer Privacy Act request. Enter Privacy Hub Inbox
Hey there, also consider AssemblyScript (TypeScript to WebAssembly compiler). It is super easy to get started and use, and flexible. It works well with VS Code's TypeScript support. assemblyscript.org
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Nice to here! It was some months ago: I was searching for an ORM (sort of) and failed. Is there anything like 'react awesome' or similar curated lists for rust?
What parts of web development do you want to get involved in? And should your choice of language lead to more job opportunities?
Go is still pretty hyped and popular because it is very easy to learn and easy to get results with. Its concurrency model is far easier to understand than traditional thread-based ones and the ecosystem exploded some time ago, with so many great libs and frameworks nowadays.
I/O in Go is async by default without you mostly noting it, because the runtime takes care of it for you.
I've been programming for nearly 20 years now (with only a fraction of it being professionally) so the following may not apply to you, but it took me only one day to learn Go and write my first piece of software in it, without it failing horribly at runtime.
The only issue I ran into was its exotic handling of dependencies ($GOPATH, etc.), which got better with the introduction of gomodules and still improves, that gave me a hard time.
The number of jobs listed for Go is pretty decent currently (please note: highly depending on where you live).
Rust on the other hand is difficult to learn but very easy to use once you actually understand it and successfully fought the compiler and borrow checker until you became very close friends (but this will take you way more time than learning Go).
I believe that it took me two weeks before I was able to write simple programs without the compiler complaining too much. But boy, once something in Rust compiles, you can be pretty sure that it'll just work!
What differentiates Rust from Go is that there's no runtime (which takes care of certain things for you). Thus you have way more control over the actual outcome of what you do.
Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn, which comes in very handy, given, that you have to learn a lot of other concepts like borrowing, etc., you did not have to bother with while using memory managed languages.
Rust comes with Cargo, which, in contrast to Go's $GOPATH / gomodule system, is like heaven on earth. It makes handling of dependencies, building, etc. so easy and so much fun and doesn't get in your way.
Depending on where you live, the number of job postings that do not directly relate to blockchain may be far less than those for Go and this may limit your opportunities.
There's nothing one of these languages can achieve that the other doesn't, so no drawbacks there with either of them. Both can be used for pretty much anything. You can write REST-APIs with both, you could implement a new database, both compile to WASM, pretty much anything you could imagine.
That's only the tip of the iceberg but perhaps it helps you a little to decide.
I'd suggest:
Try out both, write a simple program, and then see what you have more fun with.
Good points, however when you say:
"Writing Rust code comes pretty close to how you write code in other popular languages. That's not that much new to learn"
... then I really need to disagree! I have minimal experience with Rust (and Go), but having worked through most of the docs/tutorial, and subsequently having like a week (yes just a week) hands-on experience with a real-world codebase, what jumped out for me was this:
Rust has quite a strong Functional Programming (FP) feel to it - it often reminded me of Haskell which I dabbled in for a while; lots of emphasis on map/filter/reduce type of things, and declaring (abstract) data types.
This leads to Rust code tending to be much more "declarative" than Go code (which tends to be very much imperative, generic map/filter/reduce kind of code isn't even possible really for lack of a generic type system).
So, while I only have 'experience' with both Go and Rust on a "tutorial" and glorified "hello world" level, conceptually I was much more impressed with Rust as a programming language.
My feeling was that Go is very much "dumbed down" - especially the lack of generics sticks out like a sore thumb, because this forces you to write for loops ad infinitum ... the code you write tends to be very imperative. In that regard it sort of feels like a step back. Rust (at least that's my opinion) is a lot more elegant as a programming language.
On the other hand:
the Go compiler is insanely fast! Rust's compiler is s-l-o-w ...
Rust misses the biggest asset of Go which is the easy async/concurrency model
Employability: the number of Go jobs is probably an order of magnitude larger than the number of Rust jobs
On the other hand, the way Go manages its dependencies (with GOPATH and so on, and with its prescription of how you need to physically organize your files/directories) is indeed a bit "weird", but it didn't bother me really - if you stick to the conventions then it just works (again however, Rust's module system, while more complex, is a lot more elegant).
So, conceptually I'm much more impressed with Rust, but I acknowledge that Go might be more practical for "real world" purposes.
Now if Rust would acquire Go's concurrency features (Goroutines) and Go would get generic types, then the competition between the two would become really interesting!
Thank you really much for your reply!
Yes you are right, Rust has a heavy emphasis on FP-style.
But consider this two examples:
JS:
Java:
These are only two examples, specifically tailored to your point of Rust's FP-style.
What I just want to showcase is: It's not that much new. If you got the concept somewhere else, you'll get it within Rust.
The same could be made up for variable declaration, and nearly everything else.
It's just a similar style. :-)
On Go being dumbed down:
Yes, absolutely.
IIRC, one reason for Rob Pike, Ken Thompson and Robert Griesemer to design Go the way it is, is, that Google faces some unique challenges.
They had to invest an enormous amount of money to get their C++ infrastructure right and they have to onboard a lot of new engineers very often. Concurrency, of course, is very difficult and so they wanted to create something very easy to understand and write working Software with. They also wanted to fight the enormous build times Google's C++ projects sometimes have.
Their intention was to create a language with the minimal feature set needed to accomplish a task at Google scale by negating the drawbacks they previously faced.
Rust's compiler gets faster and faster with every release, but for all the checks and safety features it comes with, there need to be some drawbacks.
What do you think about the following?
It may not be that fancy as a
go func...
and then using channels and so on, but we're getting closer. :-)Edit regarding the job situation:
I think we will have to give it a little more time. Let the ecosystem mature more and I'm, pretty sure that, as the community grows, job opportunities will also arise.
Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
How would you implement Go's "channels" in Rust?
Yea, our opinions seem to match there. :-)
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
Right, I see, yes that's what Rust doesn't have, Go's runtime ... so that means it would be hard to implement it in exactly the same way.
Some "history" on Reddit (reddit.com/r/rust/comments/a6f85e/...
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Yes, exactly. :-)
One more thing I actually forgot about and which may actually help and is more native than using something like Rx: Rust channels
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
Yep, no green threads for Rust. Those channels are indeed thread backed. :-)
I only tried Rust a bit, but I love how (as you said) the compiler complains about anything.
It is harder to write bad code this way. I like this, especially because I use weak-typed languages (Python and Javascript) daily... :)
I agree. Most of my errors are through variable typing mistakes.
Forgot to mention one big thing and that is rust has no garbage collector like Go does. Not that it's bad just worth noting. Also I think wasmer is awesome either way you go; and checkout neon/yew/actix for rust or Gin for go and decide what you like. Rust gives you a lot more control but requires you to make more decisions and code. Try both go with what you like. Rust jobs will be there in the future. There are plenty of Go jobs now.
Omitted that on purpose. You are very right but the compiler takes care of allocating memory for you. And in 90% of use cases you will never need more than that, although Rust allows for manual memory management for those 10% of use cases you pretend to really know what you are doing. :-)
Thank you so much, it was very clarifying post for me😊
I am not focused on finding a job. I want to learn for hobby and combine with my knowledge of front end.
It's really good to know that! I noted all of your highlights :)
I'm aware that learning curves with both Rust and Go. I will try both with sample project. Guess best way to decide it!
Great! Glad I could be of help. If there's anything you need more help with, drop me a message!
Yay! Thank you🤓
I'd say it depends on the goal of your project. Rust is a good fit for computationally intense, high throughput situations, but will require higher cognitive overhead to put together. Golang is a language designed from the ground up to target this space, but also with an emphasis on large scale collaboration. As a result the language doesn't provide the same amount of high level tools like parametric polymorphism which can aid an individual developer, and you may need to produce more boilerplate. The standard library has a great story for webdev baked in, though, and will likely be a more frictionless experience end to end.
Thank you for explanation, actually I don't have any project. My proffesion on frontend development but I want to learn Rust or Go for hobby and combine with frontend.
Who knows, maybe I will switch my role in future :)
I'd say you can't go wrong either way, then, but Go is going to be easier to start with. It's always a matter of taste, but I personally have a lot more fun writing Rust than Go. Ideally, time permitting, you'd try both! Pick a simple application, try building it in both languages, and see which you prefer. Both are excellent choices.
Yeah exaclty what I’m thnking about choosing sample project and do it with both. Needed to ensure both languages are capable of web development first. Thank you :)
Shameless self-plug, but I wrote a post about getting started with simple framework-less webdev for Rust:
Skip the Framework: Build A Simple Rust API with Hyper
Ben Lovy ・ May 28 ・ 9 min read
This is how you can do it without a framework, but you can also try Rocket, Actix-Web, or Warp for a more full-featured starting point. For Go, I'd recommend not starting with a framework at all. Just use the standard library, and only add in a third-party solution if your app grows to the point where you need it.
Added to my reading list 😍
Appreciate for your help.
Hi Selen,
I would say not Rust nor Go...
Python / C# / Java are pretty solid options in the web development industry.
And for Turkey, C# is the way to go.
Thank you Yaser ☺️
I’m not considering job apply or want to be fullstack. My interest and want to learn for fun but hey, if I achieved well maybe I will go further and extend my profession.
Heck yeah for FUN 😁
Try Flask (with Python), I'm sure you will love it.
Lol I will look it 🙋♀️
check out FastAPI its written in python and is said to be as fast as go or nodejs when it comes to concurrency.
After switching from Python to Go several years ago - I can't look back :) In Go you just don't have problems like pip install requirements.txt or thinking how to run multi-core or deploy some RabbitMQ just for messaging on a single node. Docker images are slim, great ecosystem, easier testing and due to static types - code quality is better.
Go is a very refreshing language after Python :) Not saying Python is bad, but there are better tools for the job. Python is great for data wrangling, machine learning.
Karolis, let's have a more constructive argument
What problems did you face exactly?
There are many ways to achieve async, RabbitMQ is one of them (but it's pretty solid one), please read more here on async approaches:
dev.to/yaser/how-c-asynchronous-pr...
You mean golang:1.13.0-alpine3.10 which is 359MB
Comparing to python:alpine3.7 which is 81.3MB
That's 3x times difference in the size, big plus for Python.
No one can say that Python has one of the largest community + OSS libraries and frameworks.
You can do static typing in Python too.
Code quality is something conceived as easier to read and maintain (which Python is better at).
I would say exactly the same for Go, it's meant for high performance web apps (google-like products).
I still like Python but with my current projects that I work on, it wouldn't be a good fit.
I can see how it fits pretty much into what you're doing.
Many many business don't care about resources (cuz the price is very negligible).
Try ruby (ruby-lang.org) 😊, its gets you up and running in a few lines of code with sinatrarb.com. It is a very good place to start fullstack development. Its fully oop, and has json support out of the box. (I assume you are havin a kind of spa as frontend)
Also rubymonk.com is a incredible good source for learning ruby. Learning ruby is all about having fun, and a good way to learn server side computations ✌️😊
Hi🙋♀️ Thank you for reply:)
Ruby is very good at web development but for now I don’t think ruby or another except rust and go 🖖
I was in the same scenario some time ago. Rust was much younger - a blip on the radar, actually - and I dug into Go. I can't advise one way or the other, but I can chime in from the "person who chose Go" side.
If I was going to sum it up: Go really doesn't leave much to be desired. It ha some rough edges (looking at you package management), but at the end of the day... I'm a little sad if I was using something else.
Whenever rust vs go comes up, invariably someone says go's strength is in its high velocity. I can attest to that. I have a number of commit messages that read
make the compiler happy
, but not too bad. And, eventually it clicks - that was my fault lol.DX is solid. IDEs like strict typing of course, but the compiler speed is a monster. In dev, it feels more like an interpreter than a compiler. It's a little confounding that delve JUST NOW got the ability to run a method call during step-debug, hut cest la vie.
If you're coming from front-end, I assume you're comfortable with Node.
You will miss package.json like crazy (go mod is standard now, but it's still not quite... There)
You will love how smooth async is (huge plus if you work with rest)
You will be angry at unmarshaling an (uncertain) api response
You will be completely freaked out when the call stack takes you down into the RAM chip.
That's what I have. Now I spy on this thread. ... because I still search "go vs rust" at least once a week 🤷♀️
Hello :)
Thank you for comment! I really loved your list about love/hate. It's good to know the problems I'm going to encounter in advance :)
After learning C#, PHP, Java, JavaScript, C, Pascal, TypeScript, it's time to learning Rust because of positive comments by professionals.
I am also Firefox lover and Mozilla, and I think Mozilla made a sophisticated decision to build Firefox by Rust.
Yay! I feel close to Rust🙃
Since you haven't started either, you're much closer to web development going with go.
I say that with complete honesty as someone who uses and writes about rust semi-regularly. If you have some other use cases that warrant rust, then I would pick it. Barring that, I would pick the simplest option.
Front end developer who currently works at Tourism Industry. Skilled in Sass, Javascript and Html.
Welcome to the Privacy Hub Welcome to the Privacy Hub This is a centralized portal to learn about privacy at Citi and for California residents to submit requests in connection with the California Consumer Privacy Act. This is a centralized portal to learn about privacy at Citi and for California residents to submit requests in connection with the California Consumer Privacy Act. For Returning Visitors For Returning Visitors Check the status of your California Consumer Privacy Act request. Enter Privacy Hub Inbox
Hey there, also consider AssemblyScript (TypeScript to WebAssembly compiler). It is super easy to get started and use, and flexible. It works well with VS Code's TypeScript support. assemblyscript.org
AssemblyScript works with only Rust I assume? I don't know if compatible with Go
Thank you for reply :)
I think same, still I don't want to rush and listen programmers experience and advices before start.
Last time I checked the Rust ecosystem was lagging a bit: poor rest framework choice, poor sql/nosql backends. I think I'd go with golang.
Hey, when was the last time you checked? We've come a long way and things are pretty good these days. :-)
Nice to here! It was some months ago: I was searching for an ORM (sort of) and failed. Is there anything like 'react awesome' or similar curated lists for rust?
Sure, one of the biggest ones would be awesome-rust
which should give a pretty good overview. :-)
Thank you for sharing!
Device programming sounds so much fun =) My heart feelings will go to Rust I guess, I don't know yet 🙄