Earlier quoted context omitted.
Why can't you practice Rust in a non-business environment?
Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?
Three months of Rust
61–70 of 120 posts
Re: Three months of Rust
#62Earlier quoted context omitted.
I saw them talking about that, but it's completely obvious. Nobody today is running C/C++ unless they need either A) complete speed or B) bare metal. Go can't do either, so there was going to be very little transfer from C/C++ to Go.
C++ is still mostly what I use, but I need neither speed nor bare metal. Maybe add C) people doing UI and applications? There aren't many other good options: Java: UI looks terrible; it's annoying living in Noun-land when CPUs are, if anything, more about verbs than nouns; and running properly on Windows is not trivial. C#: Up until recently, not cross-platform unless you're ok with Mono. (But, might be worth looking…
Java GUIs can be made to look quite nice, just many developers never spend the time to go beyond the default settings.
If anything, the old Filthy Rich Clients blog from Chet Haase , Romain Guy was full of examples how to achieve great UIs in Java.
However most 9to5ers don't read such sources of information.
Re: Three months of Rust
#63Earlier quoted context omitted.
> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Be more specific.
linux kernel takes 20 minutes to build on my workstation, a plan9 kernel takes something tiny like 60 seconds on a raspberry pi. This is due to a few reasons. 1. Plan9 C does not allow headers to include more headers, this speeds up compilation, as there is far less useless preprocessor churn. 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. 3. The system has less code overall, something like 1 mi…
2) heavy optimisation is not "bloat".
3) "seems like bloat" is a too vague argument. Fine enough point about them supposedly not removing useless features.
Re: Three months of Rust
#64Earlier quoted context omitted.
> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Be more specific.
linux kernel takes 20 minutes to build on my workstation, a plan9 kernel takes something tiny like 60 seconds on a raspberry pi. This is due to a few reasons. 1. Plan9 C does not allow headers to include more headers, this speeds up compilation, as there is far less useless preprocessor churn. 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. 3. The system has less code overall, something like 1 mi…
Re: Three months of Rust
#65Earlier quoted context omitted.
It's also a "let's rebuild everything every time" problem. Hopefully, that will be fixed with support for building incrementally. (Also note that compiling a C++ file with 2000 lines can take a very long time too)
You must not forget that thanks to the preprocessor, what looks like 2000 lines may in fact be around 200k lines E.g. I have a very innocent 2000-line MainWindow.cpp that weighs 244419 lines when measured with gcc -E -o - | wc -l
Re: Three months of Rust
#66Earlier quoted context omitted.
Why can't you practice Rust in a non-business environment?
Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?
Re: Three months of Rust
#67Re: Three months of Rust
#68Interesting that Clojurescript was not the language of choice here, both given the roots of that project and the reputation of lisps for being languages to write other languages.
I wonder if the team would be willing to comment on why they are moving away from Clojurescript?
Re: Three months of Rust
#69Earlier quoted context omitted.
If optimization is the problem, then compilation at Go speed should be possible with -O0.
Just having the ability to perform such optimizations requires an architecture that is sure to have some overhead no matter which optimizations, if any, are actually executed.
Re: Three months of Rust
#70Earlier quoted context omitted.
Just having the ability to perform such optimizations requires an architecture that is sure to have some overhead no matter which optimizations, if any, are actually executed.
Rust could still have a toolchain like DMD devoted to fast compilation with minimal optimization. It just doesn't, yet (and likely won't for quite some time, since the present advantages of having a single toolchain are fairly significant and Rust doesn't have a formal specification yet).