4 ms·
It may be true that Go is easier to use than Rust but over time I have learned to essentially love Rust and hate Go. Rust isn't perfect by any means, but when I
by webkike 9y ago
It may be true that Go is easier to use than Rust but over time I have learned to essentially love Rust and hate Go. Rust isn't perfect by any means, but when I program in Go a lot of times I wish I could avoid costly abstractions that don't have any real reason for being required, and thus I usually avoid Go for any task I wouldn't just use Python for (sans the REPL).
Go doesn't let me describe data the way I want it to let me. Concurrency is not even incredibly profitable using language idioms. I like the syntax, but frankly Go is in an entirely different league than Rust is. And that is to say, when I want to write a program Go sometimes is just not an option. Rust is always available, even if you have to do a little bit of learning.
- aaron-lebo 9y agoWhat about Nim? I've found that a lot more productive than Rust even without libs.
- mlevental 9y agohow's the compile time with nim? go's compile time makes it almost as good as having a repl. i tried crystal a while ago and it has atrocious compile times.
- dom96 9y agoThe compile times are on par with Go. The Nim compiler (written in Nim and containing ~100k LOC) compiles in under 10 seconds on my MacBook Pro, and this is from a cold cache. It's even faster when making changes as the C source files generated by Nim are cached.
- merb 9y agothe question how big are the compile times on a project in the size of kubernetes, i wouldn't call that "quick compile time". even the go part of it. I mean yes the use case for many people who use go have a fast compile time, but once it goes huge, the speedup isn't as big as on other languages.
- mlevental 9y agotangential question: are there still compiler bugs?
- dom96 9y agoOf course, all software has bugs :)
- wyager 9y agoThis is not true, and shouldn't be used as a lazy excuse to write bad software. There is absolutely software that is entirely free of bugs; it just takes formal methods to get there for software of any reasonable complexity.
- webkike 9y agoYou can never however guarantee that a program will run free of errors. Hardware is faulty and not always in ways that are human caused: en.m.wikipedia.org/wiki/ECC_memory
- dom96 9y agoSure there is. But in practice most compilers I know of contain multiple bugs. The main difference between the compilers is how many users these bugs affect.
- deleted 9y ago[deleted]
- webkike 9y agoOn a personal note I'm not a huge fan of the syntax. The type system looks nice but frankly not as simple and expressive as Rust's as well.
- dom96 9y agoThat's a shame. Which parts of the syntax do you dislike? Can you also elaborate on the type system?
- webkike 9y agoSure Dom (always nice to see you come up in Nim discussions :) if you want I can send you an email getting into specifics but: A lot of the syntax seems like a "special case." For example, being able to specify what value an enum variant prints with a tuple of a value an a string during declaration feels like the wrong way of doing things. In Rust, the way this would be handled is by implementing a Display or ToString trait. For the type system, it boils down to Concepts: in Nim, they're still in development, but in Rust, the language is built around them. And I love this.
- dom96 9y agoThank you for replying :) No need to get into specifics. I think I understand your point and I must admit I am inclined to share your feelings about it too. Hopefully soon Nim's concepts will become stable enough to be used in such places too.
- logicallee 9y agoI am not the other poster but I would be extremely interested a similar email you offered, but on Go (if you've used it). My email is in my profile. I'm curious if you have any thoughts. Thanks!