3 ms·
I've changed my main language for doing work only a handful of times and it usually takes a few years of doing side-projects in a new language before I switch.
by bborud 10y ago
I've changed my main language for doing work only a handful of times and it usually takes a few years of doing side-projects in a new language before I switch.
For instance it took about 7-8 years before I switched to Java (and then only after establishing a programming style that doesn't rely on frameworks at all). The language wasn't hard to learn, but it took a while for the JVM and the standard library to get to where it needed to be.
C++ never made the cut. Quite possibly because C++ is not really one language. There were at least as many styles of C++ as there had been projects I worked on (except perhaps at Google, which is the only place I've worked where I've consistently seen good quality C++ code).
I'm in the process of evaluating Go as my main language and I have to say that this is the fastest I have gotten comfortable with a new language. I've been noodling around for a few months, doing side-projects, but my experiences so far have been very positive. Unlike most languages I haven't come across any uncomfortable stuff that would be hard to overcome. Just the usual confusion about what the idiomatic ways to do things are.
What is striking is that it is equally comfortable for doing relatively low-level (my first Go program talked to a chipset over SPI on RPi, doing something that is slightly timing sensitive) stuff and stuff that needs you to build abstractions.
I haven't used Rust yet. Mostly because I don't have the time. And I chose Go since some of my friends use it for software that you and I touch every day, thus providing me with access to people who have used it "for real".
Go just might be my next "main language". (Actually, right now it feels like I'll switch to it and never go back, but the tiny rational bit of my brain says "oh yeah, here's a list of other times you had a good feeling about something that turned to crap" :-))
- sanjayts 10y agoSorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients. But I dread the feeling of writing repetitive error handling code and copy-pasta to get a simple generic functionality to work across data types. Maybe I should just consider it a better C and move on...
- bborud 10y agoI haven't wrapped my head around how I want to do error handling in Go yet, so it is a bit early to say. I think I really need to write more code that deals with abstraction layers before I can have a useful opinion on the matter. Not that I'm too worried about not having figured out that bit yet since error handling took me a while in all other languages as well. (I think my first approach was to use panic() where I used exceptions in Java. But that doesn't really tell you anything very useful unless you also know how I use exceptions in Java :-)) I don't mind a bit of boilerplate as long as it produces understandable code. Writing boilerplate can be automated. Reading and understanding code can't. I do understand where you are coming from though. Perhaps we're getting a bit spoilt as programmers in feeling that error handling should be ... more elegant for a language designed within the last decade? :-) I think the same goes for generics, though I have a hunch that I'm not going to miss it. And I'm not sure why, but that's how it feels now. Whenever I do design classes that are genericized in Java I do so sparingly. This is mostly to ensure that the code is easy to reason about. I'm not fond of "clever" uses of generics because while it may feel satisfactory to have things click together in a beautifully complex manner, it can make code hard to read.