91–100 of 118 posts
Now when I go back to python or perl (or javascript) I'm super conscious of the choices I make regarding type checking and parameter checking.
Now when I go back to python or perl (or javascript) I'm super conscious of the choices I make regarding type checking and parameter checking.
Wait until he realizes that Rust has channels, too. It's not as pure as Go's implementation, but it's a superset.
Earlier quoted context omitted.
The question of Go or Rust for something like web services is not as clear cut in my opinion. I have JavaScript/PHP background, and have recently learnt Rust for just this use case. Rust is slightly more complex (but really not that much, nothing close to as bad as C++), but also offers more correctness guarantees. Both are good choices, hence these discussions.
Long time C++ developer here, have written a few toy programs in Rust, and am in the process of re-writing some stuff at work in Rust (from python). My opinion is that Rust is at least as complicated as C++. They have different complexities, but one isn't "easier" than the other. I enjoy Rust a lot. More than C++, at this point, but that may be the "newness" factor creating bias. I think Rust is likely a better langu…
Earlier quoted context omitted.
The question of Go or Rust for something like web services is not as clear cut in my opinion. I have JavaScript/PHP background, and have recently learnt Rust for just this use case. Rust is slightly more complex (but really not that much, nothing close to as bad as C++), but also offers more correctness guarantees. Both are good choices, hence these discussions.
> but really not that much, nothing close to as bad as C++ C++ dev here. Rust's borrow checking system is crazy and even after a week of trying I couldn't understand it in a way that I could reliably use the language. In C++ everything is fairly straight forward and well documented, in Rust it feels like I'm inserting random symbols in hopes that something will compile. The syntax is verbose and ugly, maybe not as ba…
This is a rosy-eyed view of C++ if I ever saw one. C++ has a lot of accidental complexity from layers and layers of features and backwards compatibility concerns: maybe some of the features are "straight forward" in isolation, but its interactions with the rest of the language rarely are.
C++ is deceptive, in that the compiler barely keeps track of anything for the programmer, so there are many cases when code should have "random symbols" (or something equivalent) added, but isn't, just being broken instead. The Rust compiler front-loads this: trying to turn runtime brokenness into compile-time errors, which does make it annoying to get code that runs, but it makes it less annoying to get code that actually works correctly.
Earlier quoted context omitted.
For Rust, probably Redox ( https://www.redox-os.org/ ). Then there's http://os.phil-opp.com/ and https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
I know them. My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages. As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored. Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgo…
No, I wasn't. It was an honest question.
The only OSes I've used or had any experience with are Dos/Windows, MacOS, iOS, various Unix/Linuxes and the reaally old Commodores/Macs that just ran Basic. I was hoping maybe something I'd heard of wasn't based on C/C++.
Earlier quoted context omitted.
Software development has eternal amnesia. Deep understanding of the pros and cons of different ways of structuring things are being continuously re-learnt with each passing fad, and each rewrite of a legacy system by a bright new crop of young things who learned most of what they know with a decade or so of direct experience. Different concerns have different emphases in each fad, but the systems built have structura…
But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because ev…
Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are?
Beyond what other people have said, we are also a relatively young industry. There aren't that many people with 30, 40 years experience in the field. When I got my CS degree, 13 years ago now, there was no such thing as a "software engineering" degree, and CS was mostly focused on CS rather than the sort of thing you're talking about.
I also wonder how much collective knowledge we throw away with pushing developers into management. Or the outsourcing in the late 90's and early 00's. Or ageism. We are purposefully driving people with knowledge out of the industry.
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" :-))
Earlier quoted context omitted.
With a sub-millisecond GC pauses there are many overlapping use cases. For example, while you might need Rust to target a PIC or a ESP-32 class processor, Go will run perfectly fine on a ARM Cortex-M3 which also has hardware vendors selling Java compilers, e.g. MicroEJ OS ( http://www.microej.com/ ).
GC pause time is not the only criterion, and focusing on it to the exclusion of all else is problematic. I used to have to explain this in a HN comment every time it came up, but now Mike Hearn has written up [1] better than I ever could, so I can just link there :) [1]: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...
Sure it has quite a spartan type system and I would rather use something else for my own work.
On the other hand, as an ex-Oberon user I am aware of many use cases that Go can easily fulfil and like to make people aware of it, more Go less C is good.
Earlier quoted context omitted.
But if you could learn some things from the history and use that to your advantage, why wouldn't you? Everyone would be doing so. And yet somehow it doesn't work like that, outdated things are in fact outdated and you can only take away very little from them. Things that were designed with trade offs for very expensive slow synchronous machines during the times when programmers were not bound to languages, because ev…
> Direct experience of the last decade is a lot more relevant with a lot more lessons to learn that were never even on the radar in the past. Do you make that statement with the experience to back it up? Or do you make it because "if it were useful someone would have done it"? What if everyone is thinking the same thing as you are? Beyond what other people have said, we are also a relatively young industry. There are…
That is country specific.
I took my degree around 20 ago and is it called "Degree in Software Engineering", certified by our Engineering Society.
http://www.fct.unl.pt/ensino/curso/mestrado-integrado-em-eng...
Created in 1977.